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

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

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)        blocked n/a
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          15 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  0626219dcc6a4376c1a4b04209d6c15d06e23875
baseline version:
 xen                  4e1df69cc9f51b2e017af1da3ed5b45917642115

Last test of basis   167761  2022-01-20 14:00:29 Z    0 days
Testing same since   167764  2022-01-20 20:01:37 Z    0 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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 0626219dcc6a4376c1a4b04209d6c15d06e23875
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Jan 17 18:40:50 2022 +0000

    x86/hvm: Drop hvm_{get,set}_guest_bndcfgs() and use {get,set}_regs() instead
    
    hvm_{get,set}_guest_bndcfgs() are thin wrappers around accessing 
MSR_BNDCFGS.
    
    MPX was implemented on Skylake uarch CPUs and dropped in subsequent CPUs, 
and
    is disabled by default in Xen VMs.
    
    It would be nice to move all the logic into 
vmx_msr_{read,write}_intercept(),
    but the common HVM migration code uses guest_{rd,wr}msr().  Therefore, use
    {get,set}_regs() to reduce the quantity of "common" HVM code.
    
    In lieu of having hvm_set_guest_bndcfgs() split out, use some #ifdef
    CONFIG_HVM in guest_wrmsr().  In vmx_{get,set}_regs(), split the switch
    statements into two depending on whether the require remote VMCS acquisition
    or not.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 81f0eaadf84d273a6ff8df3660b874a02d0e7677
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 12 15:47:27 2022 +0000

    x86/spec-ctrl: Fix NMI race condition with VT-x MSR_SPEC_CTRL handling
    
    The logic was based on a mistaken understanding of how NMI blocking on 
vmexit
    works.  NMIs are only blocked for EXIT_REASON_NMI, and not for general 
exits.
    Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler 
path,
    and the guest's value will be clobbered before it is saved.
    
    Switch to using MSR load/save lists.  This causes the guest value to be 
saved
    atomically with respect to NMIs/MCEs/etc.
    
    First, update vmx_cpuid_policy_changed() to configure the load/save lists at
    the same time as configuring the intercepts.  This function is always used 
in
    remote context, so extend the vmx_vmcs_{enter,exit}() block to cover the 
whole
    function, rather than having multiple remote acquisitions of the same VMCS.
    
    Both of vmx_{add,del}_guest_msr() can fail.  The -ESRCH delete case is fine,
    but all others are fatal to the running of the VM, so handle them using
    domain_crash() - this path is only used during domain construction anyway.
    
    Second, update vmx_{get,set}_reg() to use the MSR load/save lists rather 
than
    vcpu_msrs, and update the vcpu_msrs comment to describe the new state
    location.
    
    Finally, adjust the entry/exit asm.
    
    Because the guest value is saved and loaded atomically, we do not need to
    manually load the guest value, nor do we need to enable SCF_use_shadow.  
This
    lets us remove the use of DO_SPEC_CTRL_EXIT_TO_GUEST.  Additionally,
    SPEC_CTRL_ENTRY_FROM_PV gets removed too, because on an early entry failure,
    we're no longer in the guest MSR_SPEC_CTRL context needing to switch back to
    Xen's context.
    
    The only action remaining is to load Xen's MSR_SPEC_CTRL value on vmexit.  
We
    could in principle use the host msr list, but is expected to complicated
    future work.  Delete DO_SPEC_CTRL_ENTRY_FROM_HVM entirely, and use a shorter
    code sequence to simply reload Xen's setting from the top-of-stack block.
    
    Adjust the comment at the top of spec_ctrl_asm.h in light of this bugfix.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 95b13fa43e0753b7514bef13abe28253e8614f62
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 12 16:36:29 2022 +0000

    x86/spec-ctrl: Drop SPEC_CTRL_{ENTRY_FROM,EXIT_TO}_HVM
    
    These were written before Spectre/Meltdown went public, and there was large
    uncertainty in how the protections would evolve.  As it turns out, they're
    very specific to Intel hardware, and not very suitable for AMD.
    
    Drop the macros, opencoding the relevant subset of functionality, and 
leaving
    grep-fodder to locate the logic.  No change at all for VT-x.
    
    For AMD, the only relevant piece of functionality is DO_OVERWRITE_RSB,
    although we will soon be adding (different) logic to handle MSR_SPEC_CTRL.
    
    This has a marginal improvement of removing an unconditional pile of 
long-nops
    from the vmentry/exit path.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

commit 6536688439dbca1d08fd6db5be29c39e3917fb2f
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 12 13:52:47 2022 +0000

    x86/msr: Split MSR_SPEC_CTRL handling
    
    In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, move
    MSR_SPEC_CTRL handling into the new {pv,hvm}_{get,set}_reg() infrastructure.
    
    Duplicate the msrs->spec_ctrl.raw accesses in the PV and VT-x paths for now.
    The SVM path is currently unreachable because of the CPUID policy.
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 88d3ff7ab15da277a85b39735797293fb541c718
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Jan 17 12:28:39 2022 +0000

    x86/guest: Introduce {get,set}_reg() infrastructure
    
    Various registers have per-guest-type or per-vendor locations or access
    requirements.  To support their use from common code, provide accessors 
which
    allow for per-guest-type behaviour.
    
    For now, just infrastructure handling default cases and expectations.
    Subsequent patches will start handling registers using this infrastructure.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)