[Xen-devel] [xen-unstable-smoke test] 94528: regressions - trouble: blocked/broken/fail

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   3 host-install(3)         broken REGR. vs. 94514
 build-amd64                   5 xen-build                 fail REGR. vs. 94514

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-i386  1 build-check(1)         blocked n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a

version targeted for testing:
 xen                  a5adcee740df2679cf6828535279d8f8cbe2eff1
baseline version:
 xen                  46699c7393bd991234b5642763c5c24b6b39a6c4

Last test of basis    94514  2016-05-17 13:01:58 Z    0 days
Failing since         94521  2016-05-17 15:03:04 Z    0 days    2 attempts
Testing same since    94528  2016-05-17 17:01:23 Z    0 days    1 attempts

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

jobs:
 build-amd64                                                  fail    
 build-armhf                                                  broken  
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          blocked 
 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

broken-step build-armhf host-install(3)

Not pushing.

------------------------------------------------------------
commit a5adcee740df2679cf6828535279d8f8cbe2eff1
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Fri May 13 19:38:41 2016 +0100

    x86/cpuid: Avoid unconditionally clobbering ITSC for guests
    
    In general, Invariant TSC is not a feature which can be advertised to 
guests,
    because it cannot be guaranteed across migrate.  domain_cpuid() goes so far 
as
    to deliberately clobber the feature flag under a number of circumstances.
    
    Because ITSC is absent from the static {pv,hvm}_featureset masks, c/s 
b648feff
    "xen/x86: Improvements to in-hypervisor cpuid sanity checks" caused ITSC to 
be
    unconditionally masked out.
    
    As an interim solution, include the hosts idea of ITSC along with the static
    {pv,hvm}_featureset when restricting the guests view of features.  This 
causes
    the hardware domain, and VMs explicitly configured with ITSC and no-migrate 
to
    be offered ITSC (subject to hardware availability).
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <JBeulich@xxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 9e28baf22ec98a64f68757eff39df72173d5f1bb
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 17 16:42:15 2016 +0200

    x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time
    
    There is one instruction boundary where any kind of interruption would
    break the assumptions cr4_pv32_restore's debug mode checking makes on
    the correlation between the CR4 register value and its in-memory cache.
    Correct this (see the code comment) even in non-debug mode, or else
    a subsequent cr4_pv32_restore would also be misguided into thinking the
    features are enabled when they really aren't.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit e5e73163ec40b409151f2170d8e406a72b515ff2
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue May 17 16:41:35 2016 +0200

    x86: refine debugging of SMEP/SMAP fix
    
    Instead of just latching cr4_pv32_mask into %rdx, correct the found
    wrong value in %cr4 (to avoid triggering another BUG). The value left
    in %rdx should be sufficient for deducing cr4_pv32_mask from the
    register dump.
    
    Also there is one more place for XEN_CR4_PV32_BITS to be used.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel