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

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

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

Regressions :-(

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

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

Last test of basis   125432  2018-07-19 14:00:40 Z    0 days
Testing same since   125439  2018-07-19 19:00:36 Z    0 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Roger Pau Monné <roger.pau@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-i386                     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 d6371ccb93012db4ad6615fe666205b86308cb4e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jul 18 12:22:55 2018 +0100

    x86/xstate: Make errors in xstate calculations more obvious by crashing the 
domain
    
    If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID
    policy derivation or auditing logic.  If hardware rejects new_bv, then
    something is broken with Xen's xstate logic.
    
    In both cases, crash the domain with an obvious error message, to help
    highlight the issues.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 361b835fa00d9f45167c50a60e054ccf22c065d7
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jul 18 11:56:44 2018 +0100

    x86/xstate: Use a guests CPUID policy, rather than allowing all features
    
    It turns out that Xen has never enforced that a domain remain within the
    xstate features advertised in CPUID.
    
    The check of new_bv against xfeature_mask ensures that a domain stays within
    the set of features that Xen has enabled in hardware (and therefore isn't a
    security problem), but this does means that attempts to level a guest for
    migration safety might not be effective if the guest ignores CPUID.
    
    Check the CPUID policy in validate_xstate() (for incoming migration) and in
    handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU 
check
    for PV guests in handle_xsetbv() (and also demonstrates that I should have
    spotted this problem while reviewing c/s fbf9971241f).
    
    For migration, this is correct despite the current (mis)ordering of data
    because d->arch.cpuid is the applicable max policy.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 2e2bd5a29e481d0e7f163a19d663d959e09550fd
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri Jun 29 13:05:52 2018 +0000

    libx86: Introduce lib/x86/msr.h and share msr_policy with userspace
    
    To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
    needs to be available in the same way as struct cpuid_policy.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit fea2fab9635613d5be83482da5d79160ef928941
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Thu Jun 21 15:35:48 2018 +0100

    libx86: introduce a libx86 shared library
    
    Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
    individual copies from the hypervisor and libxc respectively.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 4dd7e74f31facf997ffa64d1c38a1da7a707e326
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Thu Jun 21 16:35:46 2018 +0200

    libx86: Share struct cpuid_policy with userspace
    
    Both Xen and the toolstack have need of the same logic when it comes to
    manipulation and checking of the CPUID and MSR values offered to guests.  To
    that end, libx86 is being introduced to allow Xen and the toolstack to 
share a
    single implementation, rather than duplicating the logic.
    
    No functional change.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit eddf9559c9779e9a11e1c4db46b5ec26b3cb8709
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Thu Jun 21 16:35:46 2018 +0200

    libx86: generate cpuid-autogen.h in the libx86 include dir
    
    This avoids all users needing to opencode local generation of the file.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 0e96f3d52ec200b8f7764164e22d76eef6151f59
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jun 28 11:00:44 2018 +0000

    libx86: Introduce lib/x86/cpuid.h
    
    Begin to untangle the header dependency tangle by moving definition of
    struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.
    
    Additionally, plumb the header through to libxc.  This is technically a
    redundant include at this point, but it helps build-test the later changes,
    and will be used eventually.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)

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