|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.3-testing test] 34153: regressions - FAIL
flight 34153 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 33687 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 33687 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass build-amd64-rumpuserxen 6 xen-build fail never pass test-armhf-armhf-xl-midway 5 xen-boot fail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass build-i386-rumpuserxen 6 xen-build 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-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-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-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-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass version targeted for testing: xen ef73de2a84a3042c3481c9a521e8e0c756b793f2 baseline version: xen f70c066bb55ed967a8e98bf30a50cf0a7a6155f9 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Dan Carpenter <dan.carpenter@xxxxxxxxxx> Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Tim Deegan <tim@xxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail 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-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 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-rumpuserxen-amd64 blocked 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-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 blocked 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-armhf-armhf-xl-midway fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-armhf-armhf-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-armhf-armhf-xl-sedf fail 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 ef73de2a84a3042c3481c9a521e8e0c756b793f2 Author: Dan Carpenter <dan.carpenter@xxxxxxxxxx> Date: Tue Feb 3 15:30:13 2015 +0100 bunzip2: off by one in get_next_block() "origPtr" is used as an offset into the bd->dbuf[] array. That array is allocated in start_bunzip() and has "bd->dbufSize" number of elements so the test here should be >= instead of >. Later we check "origPtr" again before using it as an offset so I don't know if this bug can be triggered in real life. Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> Trivial adjustments to make the respective Linux commit b5c8afe5be51078a979d86ae5ae78c4ac948063d apply to Xen. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> master commit: 39798e95a954eec660a3f5f21489c30ef78daf6d master date: 2015-01-28 16:50:08 +0100 commit 47266d66b35572b7d2f7b7a5f53d6eab05604cd2 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Feb 3 15:29:41 2015 +0100 docs/commandline: correct information for 'x2apic_phys' parameter Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 89c381c30b46ec714f2d5bef4b0cb6d759abc7e4 master date: 2015-01-28 16:31:07 +0100 commit 22d7558fbd22d68221234f0d03c2a042e554ed28 Author: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Date: Tue Feb 3 15:28:58 2015 +0100 x86: vcpu_destroy_pagetables() must not return -EINTR .. otherwise it has the side effect that: domain_relinquish_resources will stop and will return to user-space with -EINTR which it is not equipped to deal with that error code; or vcpu_reset - which will ignore it and convert the error to -ENOMEM.. The preemption mechanism we have for domain destruction is to return -EAGAIN (and then user-space calls the hypercall again) and as such we need to catch the case of: domain_relinquish_resources ->vcpu_destroy_pagetables -> put_page_and_type_preemptible -> __put_page_type returns -EINTR and convert it to the proper type. For: XEN_DOMCTL_setvcpucontext -> vcpu_reset -> vcpu_destroy_pagetables we need to return -ERESTART otherwise we end up returning -ENOMEM. There are also other callers of vcpu_destroy_pagetables: arch_vcpu_reset (vcpu_reset) are: - hvm_s3_suspend (asserts on any return code), - vlapic_init_sipi_one (asserts on any return code), Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: de4f284b3d7b47d3b9807f354552ecf3e0fff56b master date: 2015-01-26 12:51:09 +0100 commit 1c81b665b5bb7b57abeeea0e004fdc2c80c97608 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:28:29 2015 +0100 x86: correctly check for sub-leaf zero of leaf 7 in pv_cpuid() Only the low 32 bits are relevant. For consistency also change a cast on regs->eax to regs->_eax. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: ae1edef1ae33f3bcff2580116ae2b7c9ffef42f2 master date: 2015-01-22 12:48:40 +0100 commit 28f44faed97a3c935cfaf3737828deb5f9c1dad1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:27:56 2015 +0100 x86: don't expose XSAVES capability to PV guests As done by the recent Linux commit b65d6e17fe ("kvm: x86: mask out XSAVES") for KVM, we should also mask out XSAVES from what PV guests get to see as long as we don't emulate accesses to MSR_IA32_XSS. Actually, go beyond that: Just like for leaf 7, switch from blacklisting to whitelisting, i.e. only allow XSAVEOPT and XSAVEC for the time being. And do these overrides consistently for both Dom0 and DomU-s. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 8d050ed1097ce5f4bf6a1d6806fb1e3471976adb master date: 2015-01-22 12:47:56 +0100 commit 461a8d3916a77695b4137c6b27e7c434e03035ff Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Feb 3 15:27:18 2015 +0100 xsm/evtchn: never pretend to have successfully created a Xen event channel Xen event channels are not internal resources. They still have one end in a domain, and are created at the request of privileged domains. This logic which "successfully" creates a Xen event channel opens up undesirable failure cases with ill-specified XSM policies. If a domain is permitted to create ioreq servers or memevent listeners, but not to create event channels, the ioreq/memevent creation will succeed but attempting to bind the returned event channel will fail without any indication of a permission error. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> master commit: 09aa4759faa29c1fe735266de4c79f17329bd67b master date: 2015-01-20 10:42:26 +0100 commit dd971e41820dc33e1da1c429dfc3c7ee32b4795e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:26:48 2015 +0100 common/memory: fix an XSM error path XENMEM_{in,de}crease_reservation as well as XENMEM_populate_physmap return the extent at which failure was detected, not error indicators. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> master commit: 76d4ff26d9647088353acaf4a56388a354a5d6e9 master date: 2015-01-19 11:59:05 +0100 commit 5bea1d935e48097c1725bc4162e72fb4f313adf8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:26:16 2015 +0100 x86emul: tighten CLFLUSH emulation While for us it's not as bad as it was for Linux, their commit 13e457e0ee ("KVM: x86: Emulator does not decode clflush well", by Nadav Amit <namit@xxxxxxxxxxxxxxxxx>) nevertheless points out two shortcomings in our code: opcode 0F AE /7 is clflush only when it uses a memory mode (otherwise it's SFENCE) and when there's no REP prefix (an operand size prefix is fine, as that's CLFLUSHOPT). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 9d03db6b81d1880bf3aa4fc83a60346bf02be251 master date: 2015-01-12 15:41:12 +0100 commit 4de472720da0fc56e2a073e2ac94132455c7a1cb Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:24:45 2015 +0100 VT-d: don't crash when PTE bits 52 and up are non-zero This can (and will) be legitimately the case when sharing page tables with EPT (more of a problem before p2m_access_rwx became zero, but still possible even now when other than that is the default for a guest), leading to an unconditional crash (in print_vtd_entries()) when a DMA remapping fault occurs. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 46e0baf59105200d43612cf0c59de216958b008d master date: 2015-01-07 11:13:58 +0100 commit 34effcd03d682e3a264ead2fe7a2a67cb4fe6a35 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Tue Feb 3 15:23:38 2015 +0100 x86/VPMU: Clear last_vcpu when destroying VPMU We need to make sure that last_vcpu is not pointing to VCPU whose VPMU is being destroyed. Otherwise we may try to dereference it in the future, when VCPU is gone. We have to do this via IPI since otherwise there is a (somewheat theoretical) chance that between test and subsequent clearing of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do both vpmu_load() and then vpmu_save() for another VCPU. The former will clear last_vcpu and the latter will set it to something else. Performing this operation via IPI will guarantee that nothing can happen on the remote processor between testing and clearing of last_vcpu. We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to avoid unnecessary percpu tests and arch-specific destroy ops. Thus checks in AMD and Intel routines are no longer needed. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: ed8017155607db1bbe1f6ca41eac696b7ef8082b master date: 2015-01-07 11:12:27 +0100 commit 0f5a611cb586d5109bf7a3ecee9a71202c93126d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Feb 3 15:22:32 2015 +0100 domctl: fix IRQ permission granting/revocation Commit 545607eb3c ("x86: fix various issues with handling guest IRQs") wasn't really consistent in one respect: The granting of access to an IRQ shouldn't assume the pIRQ->IRQ translation to be the same in both domains. In fact it is wrong to assume that a translation is already/ still in place at the time access is being granted/revoked. What is wanted is to translate the incoming pIRQ to an IRQ for the invoking domain (as the pIRQ is the only notion the invoking domain has of the IRQ), and grant the subject domain access to the resulting IRQ. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> master commit: 6fb3a07bc0ad656b5f76eb9fc961bcd1d3cace58 master date: 2015-01-05 10:20:24 -0500 (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 |