[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-unstable-smoke test] 141841: regressions - FAIL



flight 141841 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm       7 xen-boot                 fail REGR. vs. 141821
 test-armhf-armhf-xl           7 xen-boot                 fail REGR. vs. 141821

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  433387661ec789962dffd8ec929f59fdee78194c
baseline version:
 xen                  ff22a91b4c45f9310d0ec0d7ee070d84a373dd87

Last test of basis   141821  2019-09-25 14:00:59 Z    0 days
Testing same since   141827  2019-09-25 18:00:48 Z    0 days    3 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Christian Lindig <christian.lindig@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Paul Durrant <paul.durrant@xxxxxxxxxx>
  Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
  Wei Liu <wl@xxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-arm64-arm64-xl-xsm                                      fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 433387661ec789962dffd8ec929f59fdee78194c
Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
Date:   Tue Sep 24 15:46:48 2019 +0000

    xen/arm: optee: update description in Kconfig
    
    OP-TEE mediator now is "Tech Preview" state, and we want to update
    it's description in Kconfig accordingly.
    
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit e9ad55d9add9c1ddf9cf49418003fb1481129791
Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
Date:   Tue Sep 24 15:46:47 2019 +0000

    SUPPORT.md: Describe OP-TEE mediator
    
    With the latest patches to the mediator, it can be considered
    as Technological Preview feature.
    
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit c2c141f0f4248963cedcb972534423cf9092ae52
Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
Date:   Tue Sep 24 15:46:45 2019 +0000

    xen/arm: optee: handle shared buffer translation error
    
    There is a case possible, when OP-TEE asks guest to allocate shared
    buffer, but Xen for some reason can't translate buffer's addresses. In
    this situation we should do two things:
    
    1. Tell guest to free allocated buffer, so there will be no memory
    leak for guest.
    
    2. Tell OP-TEE that buffer allocation failed.
    
    To ask guest to free allocated buffer we should perform the same
    thing, as OP-TEE does - issue RPC request. This is done by filling
    request buffer (luckily we can reuse the same buffer, that OP-TEE used
    to issue original request) and then return to guest with special
    return code.
    
    Then we need to handle next call from guest in a special way: as RPC
    was issued by Xen, not by OP-TEE, it should be handled by Xen.
    Basically, this is the mechanism to preempt OP-TEE mediator.
    
    The same mechanism can be used in the future to preempt mediator
    during translation large (>512 pages) shared buffers.
    
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit babde47a3feda6dd4ba318e1e57bd2ee9f2c1116
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Wed Sep 25 16:14:55 2019 +0200

    introduce a 'passthrough' configuration option to xl.cfg...
    
    ...and hence the ability to disable IOMMU mappings, and control EPT
    sharing.
    
    This patch introduces a new 'libxl_passthrough' enumeration into
    libxl_domain_create_info. The value will be set by xl either when it parses
    a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
    hardware specified for the domain.
    
    If the value of the passthrough configuration option is 'disabled' then
    the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain
    flags, thus allowing the toolstack to control whether the domain gets
    IOMMU mappings or not (where previously they were globally set).
    
    If the value of the passthrough configuration option is 'sync_pt' then
    a new 'iommu_opts' field in xen_domctl_createdomain will be set with the
    value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default
    set in iommu_hap_pt_share, thus allowing the toolstack to control whether
    EPT sharing is used for the domain.
    
    If the value of passthrough is 'enabled' then xl will choose an appropriate
    default according to the type of domain and hardware support.
    
    NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will now only
          be set if passthrough is 'sync_pt' (or xl has chosen this mode as
          a default).
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>

commit 8d8db5a4ad267bca663bc1e41dccb53e072d73d2
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Wed Sep 25 16:14:21 2019 +0200

    tools/ocaml: abi check: Cope with consecutive relevant enums
    
    If the end of one enum is the `type' line for the next enum, we would
    not notice it.
    
    Fix this by reordering the code, and getting rid of the else: now if
    the "we are within an enum" branch decides that it's the end of the
    enum, it unsets $ei and we then immediately process the line as a "not
    within an enum" line - ie as the start of the next one.
    
    Reported-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx>

commit 80ff3d338dc93260b41ffeeebb0f852c2edef9ce
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Wed Sep 25 16:12:49 2019 +0200

    iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
    
    Thes macros really ought to live in the common xen/iommu.h header rather
    then being distributed amongst architecture specific iommu headers and
    xen/sched.h. This patch moves them there.
    
    NOTE: Disabling 'sharept' in the command line iommu options should really
          be hard error on ARM (as opposed to just being ignored), so define
          'iommu_hap_pt_share' to be true for ARM (via ARM-selected
          CONFIG_IOMMU_FORCE_PT_SHARE).
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>

commit f89f555827a6634582ff78ef26e7167b2bddbbfa
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Wed Sep 25 16:12:02 2019 +0200

    remove late (on-demand) construction of IOMMU page tables
    
    Now that there is a per-domain IOMMU-enable flag, which should be set if
    any device is going to be passed through, stop deferring page table
    construction until the assignment is done. Also don't tear down the tables
    again when the last device is de-assigned; defer that task until domain
    destruction.
    
    This allows the has_iommu_pt() helper and iommu_status enumeration to be
    removed. Calls to has_iommu_pt() are simply replaced by calls to
    is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can
    also be replaced by calls to iommu_use_hap_pt().
    The arch_iommu_populate_page_table() and iommu_construct() functions become
    redundant, as does the 'strict mode' dom0 page_list mapping code in
    iommu_hwdom_init(), and iommu_teardown() can be made static is its only
    remaining caller, iommu_domain_destroy(), is within the same source
    module.
    
    All in all, about 220 lines of code are removed from the hypervisor (at
    the expense of some additions in the toolstack).
    
    NOTE: This patch will cause a small amount of extra resource to be used
          to accommodate IOMMU page tables that may never be used, since the
          per-domain IOMMU-enable flag is currently set to the value of the
          global iommu_enable flag. A subsequent patch will add an option to
          the toolstack to allow it to be turned off if there is no intention
          to assign passthrough hardware to the domain.
          To account for the extra resource, 'iommu_memkb' has been added to
          domain_build_info. This patch sets it to a value calculated based
          on the domain's maximum memory when the P2M sharing is either not
          supported or globally disabled, or zero otherwise. However, when
          the toolstack option mentioned above is added, it will also be zero
          if the per-domain IOMMU-enable flag is turned off.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>
    Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit 322609f9c9809ddc106362c24683c939524510d8
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:03:48 2019 +0200

    AMD/IOMMU: tidy struct ivrs_mappings
    
    Move the device flags field up into an unused hole, thus shrinking
    overall structure size by 8 bytes. Use bool and uint<N>_t as
    appropriate. Drop pointless (redundant) initializations.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 34a9ef62d3d29ddafbec6b3409074dd67eba7109
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:02:59 2019 +0200

    AMD/IOMMU: restrict interrupt remapping table sizes
    
    There's no point setting up tables with more space than a PCI device can
    use. For both MSI and MSI-X we can determine how many interrupts could
    be set up at most. Tables allocated during ACPI table parsing, however,
    will (for now at least) continue to be set up to have maximum size.
    
    Note that until we would want to use sub-page allocations here there's
    no point checking whether both MSI and MSI-X are supported by a device -
    an order-0 allocation will fit the dual case in any event, no matter
    that the MSI-X vector count may be smaller than the MSI one.
    
    On my Rome system this reduces space needed from just over 1k pages to
    about 125.
    
    Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit bb038f311687554483fb997cfee213760029aeaf
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:02:21 2019 +0200

    AMD/IOMMU: replace INTREMAP_ENTRIES
    
    Prepare for the number of entries to not be the maximum possible, by
    separating checks against maximum size from ones against actual size.
    For caller side simplicity have alloc_intremap_entry() return the
    maximum possible value upon allocation failure, rather than the first
    just out-of-bounds one.
    
    Have the involved functions already take all the subsequently needed
    arguments here already, to reduce code churn in the patch actually
    making the allocation size dynamic.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

commit 93a78101260b22510c5f823577ff826fbfc46136
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:01:31 2019 +0200

    x86/PCI: read maximum MSI vector count early
    
    Rather than doing this every time we set up interrupts for a device
    anew (and then in several places) fill this invariant field right after
    allocating struct pci_dev.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 4e5e40fbd5852b2b638e5d9cf775d52f93b3fecb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:00:46 2019 +0200

    AMD/IOMMU: make phantom functions share interrupt remapping tables
    
    Rather than duplicating entries in amd_iommu_msi_msg_update_ire(), share
    the tables. This mainly requires some care while freeing them, to avoid
    freeing memory blocks twice.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

commit d7cfeb7c13ed60be949714cd4befa7edb3211c9b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Sep 25 16:00:05 2019 +0200

    AMD/IOMMU: don't blindly allocate interrupt remapping tables
    
    ACPI tables are free to list far more device coordinates than there are
    actual devices. By delaying the table allocations for most cases, and
    doing them only when an actual device is known to be present at a given
    position, overall memory used for the tables goes down from over 500k
    pages to just over 1k (on my system having such ACPI table contents).
    
    Tables continue to get allocated right away for special entries
    (IO-APIC, HPET) as well as for alias IDs. While in the former case
    that's simply because there may not be any device at a given position,
    in the latter case this is to avoid having to introduce ref-counting of
    table usage.
    
    The change involves invoking
    iterate_ivrs_mappings(amd_iommu_setup_device_table) a second time,
    because the function now wants to be able to find PCI devices, which
    isn't possible yet when IOMMU setup happens very early during x2APIC
    mode setup. In this context amd_iommu_init_interrupt() gets renamed as
    well.
    
    The logic adjusting a DTE's interrupt remapping attributes also gets
    changed, such that the lack of an IRT would result in target aborted
    rather than non-remapped interrupts (should any occur).
    
    Note that for now phantom functions get separate IRTs allocated, as was
    the case before.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.