|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 25949: regressions - trouble: broken/fail/pass
flight 25949 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/25949/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 25945 test-amd64-i386-xl-qemut-win7-amd64 13 guest-localmigrate/x10 fail REGR. vs. 25945 test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 25945 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestore.2 fail like 25905 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-armhf-armhf-xl 10 migrate-support-check fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-qemut-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-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-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 816f6224823320c8452fd3af5d873a2b82f5e1c3 baseline version: xen 01feb234d0cb3bff248694d99397fb63a9757490 ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 pass build-armhf pass build-i386 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 pass 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 broken 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-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin 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-amd64-xl-qemut-winxpsp3 fail test-amd64-i386-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xl-qemuu-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-amd64-i386-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 816f6224823320c8452fd3af5d873a2b82f5e1c3 Author: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Date: Tue Apr 22 12:10:13 2014 +0200 allow hardware domain != dom0 This adds a hypervisor command line option "hardware_dom=" which takes a domain ID. When the domain with this ID is created, it will be used as the hardware domain. This is intended to be used when domain 0 is a dedicated stub domain for domain building, allowing the hardware domain to be de-privileged and act only as a driver domain. Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 4d21a95558b9c9007d8b70e63d1449a4a10f535c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Apr 22 12:09:36 2014 +0200 x86/hap: fix lack of newline in error message to avoid corrupting the following line. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <JBeulich@xxxxxxxx> commit 88e64cb785c1de4f686c1aa1993a0003b7db9e1a Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Tue Apr 22 12:08:56 2014 +0200 x86/HVM: use fixed TSC value when saving or restoring domain When a domain is saved each VCPU's TSC value needs to be preserved. To get it we use hvm_get_guest_tsc(). This routine (either itself or via get_s_time() which it may call) calculates VCPU's TSC based on current host's TSC value (by doing a rdtscll()). Since this is performed for each VCPU separately we end up with un-synchronized TSCs. Similarly, during a restore each VCPU is assigned its TSC based on host's current tick, causing virtual TSCs to diverge further. With this, we can easily get into situation where a guest may see time going backwards. Instead of reading new TSC value for each VCPU when saving/restoring it we should use the same value across all VCPUs. Reported-by: Philippe Coquard <philippe.coquard@xxxxxxxx> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit b95fd03b5f0b66384bd7c190d5861ae68eb98c85 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Tue Apr 22 12:08:06 2014 +0200 x86/svm: enable TSC scaling TSC ratio enabling logic is inverted: we want to use it when we are running in native tsc mode, i.e. when d->arch.vtsc is zero. Also, since now svm_set_tsc_offset()'s calculations depend on vtsc's value, we need to call hvm_funcs.set_tsc_offset() after vtsc changes in tsc_set_info(). In addition, with TSC ratio enabled, svm_set_tsc_offset() will need to do rdtsc. With that we may end up having TSCs on guest's processors out of sync. d->arch.hvm_domain.sync_tsc which is set by the boot processor can now be used by APs as reference TSC value instead of host's current TSC. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 82713ec8d2b65d17f13e46a131e38bfe5baf8bd6 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Tue Apr 22 12:07:37 2014 +0200 x86: use native RDTSC(P) execution when guest and host frequencies are the same We should be able to continue using native RDTSC(P) execution on HVM/PVH guests after migration if host and guest frequencies are equal (this includes the case when the frequencies are made equal by TSC scaling feature). This also allows us to revert main part of commit 4aab59a3 (svm: Do not intercept RDTSC(P) when TSC scaling is supported by hardware) which was wrong: while RDTSC intercepts were disabled domain's vtsc could still be set, leading to inconsistent view of guest's TSC. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit e681c0408564a2c0d1c6d56d3f683f8db079458c Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Apr 22 12:05:44 2014 +0200 ACPI/ERST: fix signed/unsigned type conflicts Error checks exist in the respective code path that expect negative values to indicate errors, yet negative values can't be communicated through size_t. Thus ssize_t needs to be introduced (also on ARM for consistency, even if the code in question isn't currently being used on there). The bug is theoretical only in so far as all the involved code is effectively dead. Reflect this by excluding that code from non-debug builds. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Christoph Egger <chegger@xxxxxxxxx> commit 061eebe0e99ad45c9c3b1a778b06140de4a91f25 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Apr 22 12:04:20 2014 +0200 x86/MSI: drop workaround for insecure Dom0 kernels Considering that - the workaround is expensive (iterating through the entire P2M space of a domain), - the planned elimination of the expensiveness (by propagating the type change step by step to the individual P2M leaves) wouldn't address the IOMMU side of things (as for it to obey to the changed permissions the adjustments must be pushed down immediately through the entire tree) - the proper solution (PHYSDEVOP_msix_prepare) should by now be implemented by all security conscious Dom0 kernels remove the workaround, killing eventual guests that would be known to become a security risk instead. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> (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 |