|
[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] http://www.chiark.greenend.org.uk/~xensrcts/logs/17600/ 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> ------------------------------------------------------------ jobs: 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 http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 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 handler. 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 affinities. 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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |