|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 26246: trouble: broken/fail/pass
flight 26246 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/26246/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 26214 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 26214 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 4 xen-install fail never pass test-amd64-amd64-libvirt 4 xen-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 185220ab2c1c232a06414ef4bc36398a7633d1b8 baseline version: xen bdc44e364bb185bb813bee15467981a688349037 ------------------------------------------------------------ People who touched revisions under test: Don Dugger <donald.d.dugger@xxxxxxxxx> Feng Wu <feng.wu@xxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Tim Deegan <tim@xxxxxxx> Xiantao Zhang <xiantao.zhang@xxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-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-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail 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-i386-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-i386-freebsd10-i386 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-amd64-libvirt fail test-armhf-armhf-libvirt broken test-amd64-i386-libvirt fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-qemuu-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-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on osstest.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 185220ab2c1c232a06414ef4bc36398a7633d1b8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:27:55 2014 +0200 x86: fix guest CPUID handling The way XEN_DOMCTL_set_cpuid got handled so far allowed for surprises to the caller. With this set of operations - set leaf A (using array index 0) - set leaf B (using array index 1) - clear leaf A (clearing array index 0) - set leaf B (using array index 0) - clear leaf B (clearing array index 0) the entry for leaf B at array index 1 would still be in place, while the caller would expect it to be cleared. While looking at the use sites of d->arch.cpuid[] I also noticed that the allocation of the array needlessly uses the zeroing form - the relevant fields of the array elements get set in a loop immediately following the allocation. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: 4c0ff6bd54b5a67f8f820f9ed0a89a79f1a26a1c master date: 2014-05-02 12:09:03 +0200 commit b572cd5e8565929b7dee38b29cb05c79c349efac Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Mon May 12 17:27:06 2014 +0200 hvm_set_ioreq_page() releases wrong page in error path The function calls prepare_ring_for_helper() to acquire a mapping for the given gmfn, then checks (under lock) to see if the ioreq page is already set up but, if it is, the function then releases the in-use ioreq page mapping on the error path rather than the one it just acquired. This patch fixes this bug. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 16e2a7596e9fc86881c73cef57602b2c88155528 master date: 2014-05-02 11:46:32 +0200 commit 8da3f25d0564886709e58ad1d44971f0b833fe5b Author: Feng Wu <feng.wu@xxxxxxxxx> Date: Mon May 12 17:26:06 2014 +0200 x86/HVM: correct the SMEP logic for HVM_CR0_GUEST_RESERVED_BITS When checking the SMEP feature for HVM guests, we should check the VCPU instead of the host CPU. Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 31ee951a3bee6e7cc21f94f900fe989e3701a79a master date: 2014-04-28 12:47:24 +0200 commit 22fe8bdf6638cb7186dff0cc08131c5d9fa225fc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:24:40 2014 +0200 passthrough: allow to suppress SERR and PERR signaling altogether This is just to have a workaround at hand in case other chipsets (not covered by the previous two patches) also have similar issues. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Don Dugger <donald.d.dugger@xxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> master commit: 1a2a390a560e8319a6be98c7ab6cfaebd230f67e master date: 2014-04-25 12:13:31 +0200 commit b206157e9c65ecf2bb2402d2b08c214307ff988a Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:23:46 2014 +0200 VT-d: suppress UR signaling for desktop chipsets Unsupported Requests can be signaled for malformed writes to the MSI address region, e.g. due to buggy or malicious DMA set up to that region. These should normally result in IOMMU faults, but don't on the desktop chipsets dealt with here. This is CVE-2013-3495 / XSA-59. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Don Dugger <donald.d.dugger@xxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> master commit: d6cb14b34ffc2a830022d059f1aa22bf19dcf55f master date: 2014-04-25 12:12:38 +0200 commit a1f07c1e8fb1e5876a2bc079259ce67e3293fb72 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:21:37 2014 +0200 VT-d: suppress UR signaling for server chipsets Unsupported Requests can be signaled for malformed writes to the MSI address region, e.g. due to buggy or malicious DMA set up to that region. These should normally result in IOMMU faults, but don't on the server chipsets dealt with here. IDs 0xe00, 0xe01, and 0xe04 ... 0xe0b (Ivytown) aren't needed here - Intel confirmed the issue to be fixed in hardware there. This is CVE-2013-3495 / XSA-59. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Don Dugger <donald.d.dugger@xxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx> master commit: d061d200eb92bcb1d86f9b55c6de73e35ce63fdf master date: 2014-04-25 12:11:55 +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 |