[Xen-devel] [xen-unstable-smoke test] 136291: regressions - FAIL

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   6 xen-build                fail REGR. vs. 136179

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 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                  3c04c258ab40405a74e194d9889a4cbc7abe94b4
baseline version:
 xen                  99bb45e684283b3bc621dbc99b1b93c856b4dd1c

Last test of basis   136179  2019-05-13 16:02:31 Z    1 days
Failing since        136227  2019-05-14 15:01:02 Z    0 days    6 attempts
Testing same since   136241  2019-05-14 19:10:38 Z    0 days    5 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>

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


------------------------------------------------------------
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 3c04c258ab40405a74e194d9889a4cbc7abe94b4
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Dec 12 19:22:15 2018 +0000

    x86/spec-ctrl: Introduce options to control VERW flushing
    
    The Microarchitectural Data Sampling vulnerability is split into categories
    with subtly different properties:
    
     MLPDS - Microarchitectural Load Port Data Sampling
     MSBDS - Microarchitectural Store Buffer Data Sampling
     MFBDS - Microarchitectural Fill Buffer Data Sampling
     MDSUM - Microarchitectural Data Sampling Uncacheable Memory
    
    MDSUM is a special case of the other three, and isn't distinguished further.
    
    These issues pertain to three microarchitectural buffers.  The Load Ports, 
the
    Store Buffers and the Fill Buffers.  Each of these structures are flushed by
    the new enhanced VERW functionality, but the conditions under which flushing
    is necessary vary.
    
    For this concise overview of the issues and default logic, the abbreviations
    SP (Store Port), FB (Fill Buffer), LP (Load Port) and HT (Hyperthreading) 
are
    used for brevity:
    
     * Vulnerable hardware is divided into two categories - parts which suffer
       from SP only, and parts with any other combination of vulnerabilities.
    
     * SP only has an HT interaction when the thread goes idle, due to the 
static
       partitioning of resources.  LP and FB have HT interactions at all points,
       due to the competitive sharing of resources.  All issues potentially leak
       data across the return-to-guest transition.
    
     * The microcode which implements VERW flushing also extends MSR_FLUSH_CMD, 
so
       we don't need to do both on the HVM return-to-guest path.  However, some
       parts are not vulnerable to L1TF (therefore have no MSR_FLUSH_CMD), but 
are
       vulnerable to MDS, so do require VERW on the HVM path.
    
    Note that we deliberately support mds=1 even without MD_CLEAR in case the
    microcode has been updated but the feature bit not exposed.
    
    This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 548a932ac786d6bf3584e4b54f2ab993e1117710
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Dec 12 19:22:15 2018 +0000

    x86/spec-ctrl: Infrastructure to use VERW to flush pipeline buffers
    
    Three synthetic features are introduced, as we need individual control of
    each, depending on circumstances.  A later change will enable them at
    appropriate points.
    
    The verw_sel field doesn't strictly need to live in struct cpu_info.  It 
lives
    there because there is a convenient hole it can fill, and it reduces the
    complexity of the SPEC_CTRL_EXIT_TO_{PV,HVM} assembly by avoiding the need 
for
    any temporary stack maintenance.
    
    This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit d4f6116c080dc013cd1204c4d8ceb95e5f278689
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Sep 12 14:36:00 2018 +0100

    x86/spec-ctrl: CPUID/MSR definitions for Microarchitectural Data Sampling
    
    The MD_CLEAR feature can be automatically offered to guests.  No
    infrastructure is needed in Xen to support the guest making use of it.
    
    This is part of XSA-297, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, 
CVE-2019-11091.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 9b62eba6c429c327e1507816bef403ccc87357ae
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Sep 12 14:36:00 2018 +0100

    x86/spec-ctrl: Misc non-functional cleanup
    
     * Identify BTI in the spec_ctrl_{enter,exit}_idle() comments, as other
       mitigations will shortly appear.
     * Use alternative_input() and cover the lack of memory cobber with a 
further
       barrier.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 14e122fcc45d8a86e27be9663cbd7bcea1602b25
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 14 16:22:17 2019 +0200

    IOMMU: avoid NULL deref in iommu_lookup_page()
    
    Luckily the function currently has no callers - it would have called
    through NULL for both Arm and x86/AMD.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

commit 05fe88fef20bafb2b62190b08f28211a1c4a1b12
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 14 16:21:33 2019 +0200

    x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()
    
    The two callers in common/memory.c currently call set_gpfn_from_mfn()
    themselves, so moving the call into guest_physmap_add_page() helps
    tidy their code.
    
    The two callers in common/grant_table.c fail to make that call alongside
    the one to guest_physmap_add_page(), so will actually get fixed by the
    change.
    
    Other (x86) callers are HVM only and are hence unaffected by a change
    to the function's !paging_mode_translate() part.
    
    Sadly this isn't enough yet to drop Arm's dummy macro, as there's one
    more use in page_alloc.c.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit cf7de5d9543bba1076fe8ede57b0d314394c943a
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 14 16:20:06 2019 +0200

    x86/mm: make guest_physmap_add_entry() HVM-only
    
    Lift its !paging_mode_translate() part into guest_physmap_add_page()
    (which is what common code calls), eliminating the dummy use of a
    (HVM-only really) P2M type in the PV case.
    
    Suggested-by: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit b81813dfb36fde9bd47c2e1b806e368cb9d6cbdb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 14 16:18:58 2019 +0200

    x86/mm: short-circuit HVM-only mode flags when !HVM
    
    #define-ing them to zero allows better code generation in this case,
    and paves the way for more DCE, allowing to leave certain functions just
    declared, but not defined.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel