|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 30802: trouble: blocked/broken/fail/pass
flight 30802 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/30802/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 3 host-install(3) broken REGR. vs. 30655 build-i386-pvops 3 host-install(3) broken REGR. vs. 30655 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 30655 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-pv 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a build-amd64-rumpuserxen 6 xen-build fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass build-i386-rumpuserxen 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a version targeted for testing: xen 425e9039b6532a8c5884e7fe4b6676f6cd493770 baseline version: xen 2510d34206f0b10a8684da5611e24f4f53a23f1e ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Roberto Luongo <rluongo@xxxxxxxx> Roy Franz <roy.franz@xxxxxxxxxx> Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 broken build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt blocked build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops broken build-amd64-rumpuserxen fail build-i386-rumpuserxen blocked test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-i386-rumpuserxen-i386 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-i386-xend-qemut-winxpsp3 blocked test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 blocked 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 broken-step build-i386 host-install(3) broken-step build-i386-pvops host-install(3) broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 host-install(3) Not pushing. ------------------------------------------------------------ commit 425e9039b6532a8c5884e7fe4b6676f6cd493770 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 17 16:06:47 2014 +0200 x86/paging: make log-dirty operations preemptible Both the freeing and the inspection of the bitmap get done in (nested) loops which - besides having a rather high iteration count in general, albeit that would be covered by XSA-77 - have the number of non-trivial iterations they need to perform (indirectly) controllable by both the guest they are for and any domain controlling the guest (including the one running qemu for it). Note that the tying of the continuations to the invoking domain (which previously [wrongly] used the invoking vCPU instead) implies that the tools requesting such operations have to make sure they don't issue multiple similar operations in parallel. Note further that this breaks supervisor-mode kernel assumptions in hypercall_create_continuation() (where regs->eip gets rewound to the current hypercall stub beginning), but otoh hypercall_cancel_continuation() doesn't work in that mode either. Perhaps time to rip out all the remains of that feature? This is part of CVE-2014-5146 / XSA-97. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65 master date: 2014-10-06 11:22:04 +0200 commit 9eb86d9513429e1a5bc30f6df77a1648bb67d73a Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Oct 17 16:06:03 2014 +0200 AMD/guest_iommu: properly disable guest iommu support AMD Guest IOMMU support was added to allow correct use of PASID and PRI hardware support with an ATS-aware guest driver. However, support cannot possibly function as guest_iommu_set_base() has no callers. This means that its MMIO region's P2M pages are not set to p2m_mmio_dm, preventing any invocation of the MMIO read/write handlers. c/s fd186384 "x86/HVM: extend LAPIC shortcuts around P2M lookups" introduces a path (via hvm_mmio_internal()) where iommu_mmio_handler claims its MMIO range, and causes __hvm_copy() to fail with HVMCOPY_bad_gfn_to_mfn. iommu->mmio_base defaults to 0, with a range of 8 pages, and is unilaterally enabled in any HVM guests when the host IOMMU(s) supports any extended features. Unfortunately, HVMLoader's AP boot trampoline executes an `lmsw` instruction at linear address 0x100c which unconditionally requires emulation. The instruction fetch in turn fails as __hvm_copy() fails with HVMCOPY_bad_gfn_to_mfn. The result is that multi-vcpu HVM guests do not work on newer AMD hardware, if IOMMU support is enabled in the BIOS. Change the default mmio_base address to ~0ULL. This prevents guest_iommu_mmio_range() from actually claiming any physical range whatsoever, which allows the emulation of `lmsw` to succeed. Reported-by: Roberto Luongo <rluongo@xxxxxxxx> Suggested-by: Jan Beulich <JBeulich@xxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Tested-by: Roberto Luongo <rluongo@xxxxxxxx> Acked-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx> master commit: 02e4c89b2cc3c1f19ef42ed4fcb1931d8d704bb5 master date: 2014-10-06 11:20:12 +0200 commit 3845ef72a9a9fe7befa89339e36d201dd874a56e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 17 16:05:25 2014 +0200 don't allow Dom0 access to IOMMUs' MMIO pages Just like for LAPIC, IO-APIC, MSI, and HT we shouldn't be granting Dom0 access to these. This implicitly results in these pages also getting marked reserved in the machine memory map Dom0 uses to determine the ranges where PCI devices can have their MMIO ranges placed. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: fdf30377fbc4fa6798bfda7d69e5d448c2b8e834 master date: 2014-10-06 11:15:01 +0200 commit 687b232bb38e6de552ab95a944a52997ba3b8d4b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 17 16:04:40 2014 +0200 x86: restore reserving of IO-APIC pages in XENMEM_machine_memory_map output Commit d1222afda4 ("x86: allow Dom0 read-only access to IO-APICs") had an unintended side effect: By no longer adding IO-APIC pages to Dom0's iomem_caps these also no longer get reported as reserved in the machine memory map presented to it (which got added there intentionally by commit b8a456caed ["x86: improve reporting through XENMEM_machine_memory_map"] because many BIOSes fail to add these). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Tim Deegan <tim@xxxxxxx> master commit: 9d8edc5a8b4a0937193f80da72abdb44c5aeaec6 master date: 2014-10-06 11:13:19 +0200 commit f73bada970ae0c687abe2a4ec1aa0bb960c1dfe8 Author: Roy Franz <roy.franz@xxxxxxxxxx> Date: Fri Oct 17 16:03:50 2014 +0200 x86/EFI: fix freeing of uninitialized pointer The only valid response from the LocateHandle() call is EFI_BUFFER_TOO_SMALL, so exit if we get anything else. We pass a 0 size/NULL pointer buffer, so the only other returns we will get is an error. Return right away as there is nothing to do. Also return if there is an error allocating the buffer, as the previous code path also allowed for an undefined pointer to be freed. Signed-off-by: Roy Franz <roy.franz@xxxxxxxxxx> Re-structure the change. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: c61690fb76f9a51a8c932d76929b67bd0940febe master date: 2014-09-24 11:09:11 +0200 commit c7d1bb848e1817273081bfc4ecb21d3e1e4e32b0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri Oct 17 16:03:01 2014 +0200 VMX: don't unintentionally leave x2APIC MSR intercepts disabled These should be re-enabled in particular when the virtualized APIC transitions to HW-disabled state. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 72af6f455ac6afcd46d9a556f90349f2397507e8 master date: 2014-09-16 13:58:20 +0200 commit 8bb89fae19059797e36935839f7f08fac6adf95a Author: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> Date: Fri Oct 17 16:02:06 2014 +0200 x86, idle: add barriers to CLFLUSH workaround ... since the documentation is explicit that CLFLUSH is only ordered with respect to MFENCE. Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 48d32458bcd453e31b458bca868a079a6d0a38af master date: 2014-09-09 18:09:08 +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 |