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

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm      12 guest-start              fail REGR. vs. 148323
 test-amd64-amd64-libvirt    18 guest-start/debian.repeat fail REGR. vs. 148323
 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-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                  e19d3a942e4b6f6c5b19287a4a6f5020bdab2936
baseline version:
 xen                  99f1c935190986068a36fb5e78a00e6b71b08f25

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

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>
  Paul Durrant <paul@xxxxxxx>
  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                                      fail    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     fail    


------------------------------------------------------------
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 e19d3a942e4b6f6c5b19287a4a6f5020bdab2936
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Mar 10 17:06:57 2020 +0100

    memaccess: reduce include dependencies
    
    The common header doesn't itself need to include public/vm_event.h nor
    public/memory.h. Drop their inclusion. This requires using the non-
    typedef names in two prototypes and an inline function; by not changing
    the callers and function definitions 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: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>

commit 15b6242230ba1cf92c774ad2b14f4f25411aa644
Author: Paul Durrant <paul@xxxxxxx>
Date:   Tue Mar 10 17:06:09 2020 +0100

    x86 / p2m: replace page_list check in p2m_alloc_table...
    
    ... with a check of domain_tot_pages().
    
    The check of page_list prevents the prior allocation of PGC_extra pages,
    whereas what the code is trying to verify is that the toolstack has not
    already RAM for the domain.
    
    Signed-off-by: Paul Durrant <paul@xxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

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