|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.4-testing test] 26235: trouble: broken/fail/pass
flight 26235 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/26235/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 26207 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 26207 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start 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-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-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-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-i386-xend-qemut-winxpsp3 17 leak-check/check 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 6a0a09cfe4377cdf8cac852904c2344bce9b44a3 baseline version: xen d4b9500540bcb46a650db0b5c3ab4a5decada67f ------------------------------------------------------------ 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-xend pass build-i386-xend pass 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 broken 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 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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-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 fail 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 6a0a09cfe4377cdf8cac852904c2344bce9b44a3 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:19:01 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 7c8444d0ba3454a09b6031cd0fc4f4400d48c2c2 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Mon May 12 17:18:08 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 f952f9c7f0e4bca2aba83a28ac5a973b9fd6fe69 Author: Feng Wu <feng.wu@xxxxxxxxx> Date: Mon May 12 17:15:50 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 ddcc6488ce84fb4e66361efdd8a438d589870769 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:14:46 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 d2f4bcbb105b4a91ffbc1df9d6726dd5876d7840 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:13:32 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 f38827b8347f2ba220fc8c7f3f0b9eb60277eb8d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Mon May 12 17:11:12 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 |