[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-4.1-testing test] 17600: regressions - FAIL

flight 17600 xen-4.1-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 17482

Tests which did not succeed, but are not blocking:
 build-armhf                   4 xen-build                    fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemut-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  2cf4461ac868ca82fd63b370afe9efe9a1291900
baseline version:
 xen                  b10b4af626d95cd432576cad0e2f500769c1e002

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Ben Guthro <benjamin.guthro@xxxxxxxxxx>
  Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>
  Xiantao Zhang <xiantao.zhang@xxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-i386-i386-xl-qemut-winxpsp3                             fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    

sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at

Test harness code can be found at

Not pushing.

commit 2cf4461ac868ca82fd63b370afe9efe9a1291900
Author: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
Date:   Tue Apr 9 16:27:14 2013 +0200

    VMX: Always disable SMEP when guest is in non-paging mode
    commit e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65
      VMX: disable SMEP feature when guest is in non-paging mode
    disabled the SMEP bit if a guest VCPU was using HAP and was not
    in paging mode. However I could observe VCPUs getting stuck in
    the trampoline after the following patch in the Linux kernel
    changed the way CR4 gets set up:
      x86, realmode: read cr4 and EFER from kernel for 64-bit trampoline
    The change will set CR4 from already set flags which includes the
    SMEP bit. On bare metal this does not matter as the CPU is in non-
    paging mode at that time. But Xen seems to use the emulated non-
    paging mode regardless of HAP (I verified that on the guests I was
    seeing the issue, HAP was not used).
    Therefor it seems right to unset the SMEP bit for a VCPU that is
    not in paging-mode, regardless of its HAP usage.
    Signed-off-by: Stefan Bader <stefan.bader@xxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    Acked-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
    master commit: 0d2e673a763bc7c2ddf97fed074eb691d325ecc5
    master date: 2013-04-04 10:37:19 +0200

commit a625c40e553907d581aa9fbbab762b64841e2741
Author: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
Date:   Tue Apr 9 16:26:29 2013 +0200

    VMX: disable SMEP feature when guest is in non-paging mode
    SMEP is disabled if CPU is in non-paging mode in hardware.
    However Xen always uses paging mode to emulate guest non-paging
    mode with HAP. To emulate this behavior, SMEP needs to be manually
    disabled when guest switches to non-paging mode.
    We met an issue that, SMP Linux guest with recent kernel (enable
    SMEP support, for example, 3.5.3) would crash with triple fault if
    setting unrestricted_guest=0 in grub. This is because Xen uses an
    identity mapping page table to emulate the non-paging mode, where
    the page table is set with USER flag. If SMEP is still enabled in
    this case, guest will meet unhandlable page fault and then crash.
    Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
    master commit: e7dda8ec9fc9020e4f53345cdbb18a2e82e54a65
    master date: 2013-01-30 09:17:30 -0800

commit da7e3cdf0a1c2440886383e0e7f826c88796b8ca
Author: Keir Fraser <keir@xxxxxxx>
Date:   Tue Apr 9 16:25:20 2013 +0200

    vmx: Simplify cr0 update handling by deferring cr4 changes to the cr4 
    Signed-off-by: Keir Fraser <keir@xxxxxxx>
    master commit: 1453984eab1297559e016d4e907a27e55997191c
    master date: 2013-01-30 09:15:39 -0800

commit e6bd18f4cf30c3e26b44e52a929d18066e0c8ceb
Author: Tim Deegan <tim@xxxxxxx>
Date:   Tue Apr 9 16:19:53 2013 +0200

    x86/mm/shadow: spurious warning when unmapping xenheap pages.
    Xenheap pages will always have an extra typecount, taken in
    share_xen_page_with_guest(), which doesn't come from a shadow PTE.
    Adjust the warning in sh_remove_all_mappings() to account for it.
    Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Tim Deegan <tim@xxxxxxx>
    Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: cfc515dabe91e3d6c690c68c6a669d6d77fb7ac4
    master date: 2013-04-04 10:14:30 +0100

commit 95483087da57c29d778cbc1941a807f60357daf7
Author: Ben Guthro <benjamin.guthro@xxxxxxxxxx>
Date:   Tue Apr 9 16:13:11 2013 +0200

    x86/S3: Restore broken vcpu affinity on resume
    When in SYS_STATE_suspend, and going through the cpu_disable_scheduler
    path, save a copy of the current cpu affinity, and mark a flag to
    restore it later.
    Later, in the resume process, when enabling nonboot cpus restore these
    Signed-off-by: Ben Guthro <benjamin.guthro@xxxxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: 41e71c2607e036f1ac00df898b8f4acb2d4df7ee
    master date: 2013-04-02 09:52:32 +0200

commit d7d4d16afe2460a4e988ba237ec44c7fc36b7b1f
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Apr 9 16:10:29 2013 +0200

    x86: irq_move_cleanup_interrupt() must ignore legacy vectors
    Since the main loop in the function includes legacy vectors, and since
    vector_irq[] gets set up for legacy vectors regardless of whether those
    get handled through the IO-APIC, it must not do anything on this vector
    range. In fact, we should never get past the move_cleanup_count check
    for IRQs not handled through the IO-APIC. Adding a respective assertion
    woulkd make those iterations more expensive (due to the lock acquire).
    For such an assertion to not have false positives we however ought to
    suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct
    anyway), which is being done here despite the assertion not actually
    getting added.
    Furthermore, there's no point iterating over the vectors past
    LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    master commit: af699220ad6d111ba76fc3040342184e423cc9a1
    master date: 2013-04-02 08:30:03 +0200
(qemu changes not included)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.