|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.5-testing test] 94838: regressions - FAIL
flight 94838 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94838/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 94707 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 94707 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 94707 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail like 94682 test-amd64-amd64-xl-rtds 6 xen-boot fail like 94707 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 94707 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94707 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94707 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass version targeted for testing: xen 524a93d1fa33d18f09004592bde22a4e8409b7f8 baseline version: xen ffda547469694ff22b6c8d0bc23436c9b4ce84ec Last test of basis 94707 2016-05-22 12:40:52 Z 5 days Testing same since 94838 2016-05-27 13:08:50 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Dario Faggioli <dario.faggioli@xxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@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-prev pass build-i386-prev pass build-amd64-pvops pass build-armhf-pvops pass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvh-amd fail 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 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-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-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-intel fail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 524a93d1fa33d18f09004592bde22a4e8409b7f8 Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Date: Fri May 27 14:50:19 2016 +0200 sched: avoid races on time values read from NOW() or (even in cases where there is no race, e.g., outside of Credit2) avoid using a time sample which may be rather old, and hence stale. In fact, we should only sample NOW() from _inside_ the critical region within which the value we read is used. If we don't, in case we have to spin for a while before entering the region, when actually using it: 1) we will use something that, at the veryy least, is not really "now", because of the spinning, 2) if someone else sampled NOW() during a critical region protected by the lock we are spinning on, and if we compare the two samples when we get inside our region, our one will be 'earlier', even if we actually arrived later, which is a race. In Credit2, we see an instance of 2), in runq_tickle(), when it is called by csched2_context_saved() as it samples NOW() before acquiring the runq lock. This makes things look like the time went backwards, and it confuses the algorithm (there's even a d2printk() about it, which would trigger all the time, if enabled). In RTDS, something similar happens in repl_timer_handler(), and there's another instance in schedule() (in generic code), so fix these cases too. While there, improve csched2_vcpu_wake() and and rt_vcpu_wake() a little as well (removing a pointless initialization, and moving the sampling a bit closer to its use). These two hunks entail no further functional changes. Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> Reviewed-by: Meng Xu <mengxu@xxxxxxxxxxxxx> RTDS: fix another instance of the 'read NOW()' race which was overlooked in 779511f4bf5ae ("sched: avoid races on time values read from NOW()"). Reported-by: Jan Beulich <jbeulich@xxxxxxxx> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> Reviewed-by: Meng Xu <mengxu@xxxxxxxxxxxxx> master commit: 779511f4bf5ae34820a85e4eb20d50c60f69e977 master date: 2016-05-23 14:39:51 +0200 master commit: 4074e4ebe9115ac4986f963a13feada3e0560460 master date: 2016-05-25 14:33:57 +0200 commit 8549385968925241be70fcb549b939146c3ec6fd Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:49:52 2016 +0200 x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation This in particular prevents updating guest IP when handling the retry needed to forward the memory access to qemu. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 2bb230972c5ddb1ca823f47750b5d46a9d302d0e master date: 2016-05-19 12:06:33 +0200 commit b1c94bdafe4443098edc688563ed617a75bc7c74 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri May 27 14:49:28 2016 +0200 xen/nested_p2m: Don't walk EPT tables with a regular PT walker hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a general L1 p2m walk. It is fine for AMD as NPT share the same format as normal pagetables. For Intel EPT however, it is wrong. The translation ends up correct (as the formats are sufficiently similar), but the control bits in lower 12 bits differ in meaning. A plain PT walker sets A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and top bit of EMT (caching type). This in turn causes problem when the EPT tables are subsequently used. Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in paging_gva_to_gfn(), which is the correct function for the task. This involves making nestedhap_walk_L1_p2m() non-static, and adding vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable from contexts other than v == current. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: bab2bd8e222de9e596699ac080ea985af828c4c4 master date: 2016-05-18 18:22:06 +0100 commit 644aa81d1e7ceabc30af950cc268dc00ef74e2af Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:48:58 2016 +0200 x86/PoD: skip eager reclaim when possible Reclaiming pages is pointless when the cache can already satisfy all outstanding PoD entries, and doing reclaims in that case can be very harmful to performance when that memory gets used by the guest, but only to store zeroes there. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 556c69f4efb09dd06e6bce4cbb0455287f19d02e master date: 2016-05-12 18:02:21 +0200 commit e5fa482e0d4b3bf1747a52d6e3aebf059aa4823c Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:48:00 2016 +0200 IOMMU/x86: per-domain control structure is not HVM-specific ... and hence should not live in the HVM part of the PV/HVM union. In fact it's not even architecture specific (there already is a per-arch extension type to it), so it gets moved out right to common struct domain. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> master commit: af07377007d595b5d6422291bb1c932c16d1036f master date: 2016-05-04 09:44:32 +0200 commit 8d1e55944b8391fbf4aafe7880f5c66de60b3adc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:47:08 2016 +0200 x86: use optimal NOPs to fill the SMEP/SMAP placeholders Alternatives patching code picks the most suitable NOPs for the running system, so simply use it to replace the pre-populated ones. Use an arbitrary, always available feature to key off from, but hide this behind the new X86_FEATURE_ALWAYS. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> x86/compat: correct SMEP/SMAP NOPs patching Correct the number of single byte NOPs we want to be replaced in case neither SMEP nor SMAP are available. Also simplify the expression adding these NOPs - at that location . equals .Lcr4_orig, and removing that part of the expression fixes a bogus ".space or fill with negative value, ignored" warning by very old gas (which actually is what made me look at those constructs again). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 01a0bd0a7d72be638a359db3f8cf551123467d29 master date: 2016-05-13 18:15:55 +0100 master commit: f5610009529628314c9d1d52b00715fe855fcf06 master date: 2016-05-26 17:26:24 +0100 commit f3325975e2cdfd85aa6b49280897f4683f6aa896 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:46:31 2016 +0200 x86: suppress SMEP and SMAP while running 32-bit PV guest code Since such guests' kernel code runs in ring 1, their memory accesses, at the paging layer, are supervisor mode ones, and hence subject to SMAP/SMEP checks. Such guests cannot be expected to be aware of those two features though (and so far we also don't expose the respective feature flags), and hence may suffer page faults they cannot deal with. While the placement of the re-enabling slightly weakens the intended protection, it was selected such that 64-bit paths would remain unaffected where possible. At the expense of a further performance hit the re-enabling could be put right next to the CLACs. Note that this introduces a number of extra TLB flushes - CR4.SMEP transitioning from 0 to 1 always causes a flush, and it transitioning from 1 to 0 may also do. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> x86/compat: Cleanup and further debugging of SMAP/SMEP fixup * Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid opencoding the invidial bits which are fixed up behind a 32bit PV guests back. * Show cr4_pv32_mask in the BUG register dump Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> x86: refine debugging of SMEP/SMAP fix Instead of just latching cr4_pv32_mask into %rdx, correct the found wrong value in %cr4 (to avoid triggering another BUG). Also there is one more place for XEN_CR4_PV32_BITS to be used. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> x86: make SMEP/SMAP suppression tolerate NMI/MCE at the "wrong" time There is one instruction boundary where any kind of interruption would break the assumptions cr4_pv32_restore's debug mode checking makes on the correlation between the CR4 register value and its in-memory cache. Correct this (see the code comment) even in non-debug mode, or else a subsequent cr4_pv32_restore would also be misguided into thinking the features are enabled when they really aren't. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: ea3e8edfdbabfb17f0d39ed128716ec464f348b8 master date: 2016-05-13 18:15:45 +0100 master commit: ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83 master date: 2016-05-16 13:11:05 +0100 master commit: e5e73163ec40b409151f2170d8e406a72b515ff2 master date: 2016-05-17 16:41:35 +0200 master commit: 9e28baf22ec98a64f68757eff39df72173d5f1bb master date: 2016-05-17 16:42:15 +0200 commit c790220d0799ad64864ae4311050079952a4c3c4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:45:36 2016 +0200 x86: move cached CR4 value to struct cpu_info This not only eases using the cached value in assembly code, but also improves the generated code resulting from such reads in C. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 5d93f1d8ca7b62e85c8b98ed9c45b6cef89d17b8 master date: 2016-03-18 09:49:47 +0100 commit 49fe83af5a18ab49d8964a3a889ba39c75c4e378 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:44:46 2016 +0200 x86/alternatives: correct near branch check Make sure the near JMP/CALL check doesn't consume uninitialized data, not even in a benign way. And relax the length check at once. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: cd29140ef0e65a33d62e7f5ee843077e51913f01 master date: 2016-03-09 16:51:16 +0100 commit a67e0f1b6f0cab6cf778d6642a98ab3a1f14daf2 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Fri May 27 14:44:09 2016 +0200 x86/P2M: consolidate handling of types not requiring a valid MFN As noted regarding the mixture of checks in p2m_pt_set_entry(), introduce a new P2M type group allowing to be used everywhere we just care about accepting operations with either a valid MFN or a type permitting to be used without (valid) MFN. Note that p2m_mmio_dm is not included in P2M_NO_MFN_TYPES, as for the intended purpose that one ought to be treated similar to p2m_invalid (perhaps the two should ultimately get folded anyway). Note further that PoD superpages now get INVALID_MFN used when creating page table entries (was _mfn(0) before). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: c35eefded2992fc9b979f99190422527650872fd master date: 2015-11-20 12:38:33 +0100 (qemu changes not included) _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |