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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl         16 guest-start/debian.repeat fail REGR. vs. 148323

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0198960edbf0e681cef59fd81c994643e7b148e0
baseline version:
 xen                  99f1c935190986068a36fb5e78a00e6b71b08f25

Last test of basis   148323  2020-03-09 15:01:29 Z    1 days
Testing same since   148381  2020-03-10 15:05:53 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
  Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  Tim Deegan <tim@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                                      pass    
 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 0198960edbf0e681cef59fd81c994643e7b148e0
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:38:25 2020 +0100

    vmevent: reduce include dependencies
    
    There's no need for virtually everything to include public/vm_event.h.
    Move its inclusion out of sched.h. This requires using the non-typedef
    name in p2m_mem_paging_resume()'s prototype; by not changing the
    function definition at the same time it'll remain certain that the build
    would fail if the typedef itself was changed.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
    Reviewed-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>
    Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>

commit 0604e1549ac522443f01d49774f73cfa67561358
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:37:30 2020 +0100

    IOMMU: iommu_snoop is x86-only
    
    In fact it's VT-d specific, but we don't have a way yet to build code
    for just one vendor. Provide a #define for the opposite case.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>

commit 0de9500d1c2c3f37b3cd86b180dc1d2aafa2ad1b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:36:45 2020 +0100

    IOMMU: iommu_qinval is x86-only
    
    In fact it's VT-d specific, but we don't have a way yet to build code
    for just one vendor.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>

commit cd550c3963ea521205e80df935c17d4cdee02844
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:35:57 2020 +0100

    IOMMU: iommu_igfx is x86-only
    
    In fact it's VT-d specific, but we don't have a way yet to build code
    for just one vendor.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>

commit 4ccbb9c337de30f4b5fd9caf87c673200cb19de9
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:33:56 2020 +0100

    IOMMU: iommu_intpost is x86/HVM-only
    
    Provide a #define for all other cases.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>

commit 5f62fdcb4c7c63205abfe5a5cbf77025cb9fd431
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:32:16 2020 +0100

    IOMMU: iommu_intremap is x86-only
    
    Provide a #define for other cases; it didn't seem worthwhile to me to
    introduce an IOMMU_INTREMAP Kconfig option at this point.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>

commit c9495bd7dff587ce770b2318037d6a1d0511bd72
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Tue Mar 10 15:30:27 2020 +0100

    x86/hap: improve hypervisor assisted guest TLB flush
    
    The current implementation of the hypervisor assisted flush for HAP is
    extremely inefficient.
    
    First of all there's no need to call paging_update_cr3, as the only
    relevant part of that function when doing a flush is the ASID vCPU
    flush, so just call that function directly.
    
    Since hvm_asid_flush_vcpu is protected against concurrent callers by
    using atomic operations there's no need anymore to pause the affected
    vCPUs.
    
    Finally the global TLB flush performed by flush_tlb_mask is also not
    necessary, since we only want to flush the guest TLB state it's enough
    to trigger a vmexit on the pCPUs currently holding any vCPU state, as
    such vmexit will already perform an ASID/VPID update, and thus clear
    the guest TLB.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wl@xxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 920d5f31883c9c4c4e8092a693572fe01b6f7270
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Tue Mar 10 15:29:24 2020 +0100

    x86/paging: add TLB flush hook
    
    Add shadow and hap implementation specific helpers to perform guest
    TLB flushes. Note that the code for both is exactly the same at the
    moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
    further patches that will add implementation specific optimizations to
    them.
    
    No functional change intended.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wl@xxxxxxx>
    Acked-by: Tim Deegan <tim@xxxxxxx>
    Reviewed-by: Paul Durrant <pdurrant@xxxxxxxx> [viridian]
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 261ef8ccbd28526d69c3a6c5944709f81624741a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:27:56 2020 +0100

    x86: refine APIC ID restriction
    
    Now that we distinguish "restricted" and "full" interrupt remapping
    mode, the 8-bit-APIC-ID restriction also needs to be enforced for
    "restricted".
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

commit 1ba66a870eba43d52d3e5e7af1a055bf5b16b30d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 15:25:58 2020 +0100

    AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode
    
    The wider cluster mode APIC IDs aren't generally representable. Convert
    the iommu_intremap variable into a tristate, allowing the AMD IOMMU
    driver to signal this special restriction to the apic_x2apic_probe().
    (Note: assignments to the variable get adjusted, while existing
    consumers - all assuming a boolean property - are left alone.)
    
    While we are not aware of any hardware/firmware with this as a
    restriction, it is a situation which could be created on fully x2apic-
    capable systems via firmware settings.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
(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®.