|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.5-testing test] 83003: regressions - FAIL
flight 83003 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 78736 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 78640 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 78736 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail like 78640 test-amd64-amd64-xl-rtds 6 xen-boot fail like 78736 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 78736 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78736 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 78736 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check 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-amd64-amd64-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-vhd 10 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 10 guest-start fail never pass test-armhf-armhf-libvirt-raw 10 guest-start 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-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 fe71162ab965d4a3344bb867f88e967806c80af5 baseline version: xen 7afddd3b945b11a7f5162d1355283b6b9ae7aba3 Last test of basis 78736 2016-01-21 20:56:44 Z 28 days Testing same since 83003 2016-02-18 14:45:02 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alan.Robinson <alan.robinson@xxxxxxxxxxxxxx> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Anthony PERARD <anthony.perard@xxxxxxxxxx> Dirk Behme <dirk.behme@xxxxxxxxxxxx> George Dunlap <george.dunlap@xxxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> 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 fail 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 pass 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 fail test-amd64-i386-xl-qemuu-winxpsp3 pass ------------------------------------------------------------ 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 fe71162ab965d4a3344bb867f88e967806c80af5 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Feb 18 15:26:16 2016 +0100 x86: fix unintended fallthrough case from XSA-154 ... and annotate the other deliberate one: Coverity objects otherwise. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> One of the two instances was actually a bug. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 8dd6d1c099865ee5f5916616a0ca79cd943c46f9 master date: 2016-02-18 15:10:07 +0100 commit d4e0fcbed633b40ff4c313f72239c6b91bc1ba31 Author: Dirk Behme <dirk.behme@xxxxxxxxxxxx> Date: Thu Feb 18 15:25:43 2016 +0100 xen/arm64: Make sure we get all debug output Starting in the wrong ELx mode I get the following debug output: ... - Current EL 00000004 - - Xen must be entered in NS EL2 mode - - Boot failed - The output of "Please update the bootloader" is missing here, because string concatenation in gas, unlike in C, keeps the \0 between each individual string. Make sure this is output, too. With this, we get ... - Current EL 00000004 - - Xen must be entered in NS EL2 mode - - Please update the bootloader - - Boot failed - as intended. Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> [ ijc -- added same change to arm32 case ] master commit: c31d34082555566eb27d0d1eb42962f72fa886d3 master date: 2016-02-18 10:13:42 +0000 commit 820311c63d1dd713b7a50d31e92c5424fd791015 Author: Anthony PERARD <anthony.perard@xxxxxxxxxx> Date: Wed Feb 17 16:49:49 2016 +0100 hvmloader: fix scratch_alloc to avoid overlaps scratch_alloc() set scratch_start to the last byte of the current allocation. The value of scratch_start is then reused as is (if it is already aligned) in the next allocation. This result in a potential reuse of the last byte of the previous allocation. Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 4ab3ac074cb1f101f42e02103fa263a1f4f422b5 master date: 2016-02-10 14:46:45 +0100 commit 1d69621a48ed2cc429b04cada2cc59244c4a50c6 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Feb 17 16:49:18 2016 +0100 x86/nHVM: avoid NULL deref during INVLPG intercept handling When intercepting (or emulating) L1 guest INVLPG, the nested P2M pointer may be (is?) NULL, and hence there's no point in calling p2m_flush(). In fact doing so would cause a dereference of that NULL pointer at least in the ASSERT() right at the beginning of the function. While so far nothing supports hap_invlpg() being reachable from the INVLPG intercept paths (only INVLPG insn emulation would lead there), and hence the code in question (added by dd6de3ab99 ["Implement Nested-on-Nested"]) appears to be dead, this seems to be the change which can be agreed on as an immediate fix. Ideally, however, the problematic code would go away altogether. See thread at lists.xenproject.org/archives/html/xen-devel/2016-01/msg03762.html. Reported-by: å??令 <liuling-it@xxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx> master commit: 86c59615f4e7f38df24182f20d9dbdec3299c514 master date: 2016-02-09 13:22:13 +0100 commit 836dc18a378464e3e89a6b6e01c4a24a21f0316b Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Feb 17 16:48:37 2016 +0100 credit: recalculate per-cpupool credits when updating timeslice When modifying the timeslice of the credit scheduler in a cpupool the cpupool global credit value (n_cpus * credits_per_tslice) isn't recalculated. This will lead to wrong scheduling decisions later. Do the recalculation when updating the timeslice. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Tested-by: Alan.Robinson <alan.robinson@xxxxxxxxxxxxxx> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> master commit: ffc342fbb060cd753fc3a5f6fb6f550dd29a2637 master date: 2016-02-02 14:03:40 +0100 commit 3fa5fb56a96253f4fe1efdce235bb783001138ea Author: Juergen Gross <jgross@xxxxxxxx> Date: Wed Feb 17 16:48:16 2016 +0100 credit: update timeslice under lock When updating the timeslice of the credit scheduler protect the scheduler's private data by it's lock. Today a possible race could result only in some weird scheduling decisions during one timeslice, but further adjustments will need the lock anyway. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx> master commit: f2c96ac4dedf4976e46de34c69c2cd8b289c4ef2 master date: 2016-02-02 14:03:06 +0100 commit 0baa07315c70880613e6c33e915c6941d09b4612 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Feb 17 16:47:52 2016 +0100 x86/vmx: don't clobber exception_bitmap when entering/leaving emulated real mode Most updates to the exception bitmaps set or clear an individual bits. However, entering or exiting emulated real mode unilaterally clobbers it, leaving the exit code to recalculate what it should have been. This is error prone, and indeed currently fails to recalculate the TRAP_no_device intercept appropriately. Instead of overwriting exception_bitmap when entering emulated real mode, move the override into vmx_update_exception_bitmap() and leave exception_bitmap unmodified. This means that recalculation is unnecessary, and that the use of vmx_fpu_leave() and vmx_update_debug_state() while in emulated real mode doesn't result in TRAP_no_device and TRAP_int3 being un-intercepted. This is only a functional change on hardware lacking unrestricted guest support. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 78c93adf0a7f6a7abe249a63e7398ca1221a6d25 master date: 2016-02-02 14:00:52 +0100 commit a7f6bcbcdeaba036349cc476268426fae094dda0 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Feb 17 16:47:21 2016 +0100 x86/mce: fix misleading indentation in init_nonfatal_mce_checker() Debian bug 812166[0] reported this build failure due to Wmisleading-indentation with gcc-6: non-fatal.c: In function 'init_nonfatal_mce_checker': non-fatal.c:103:2: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] switch (c->x86_vendor) { ^~~~~~ non-fatal.c:97:5: note: ...this 'if' clause, but it is not if ( __get_cpu_var(poll_bankmask) == NULL ) ^~ I was unable to reproduce (xen builds cleanly for me with "6.0.0 20160117 (experimental) [trunk revision 232481]") but looking at the code the issue above is clearly real. Correctly reindent the if statement. This file uses Linux coding style (infact the use of Xen style for this line is the root cause of the wanring) so use tabs and while there remove the whitespace inside the if as Linux does. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166 Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 2e46e3f2539d026594ec1618e7df2c2bc8785b42 master date: 2016-01-22 16:19:51 +0100 commit 677eb6e2dc5295ea49d6d75971c96695567ae601 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Feb 17 16:46:52 2016 +0100 x86: fix (and simplify) MTRR overlap checking Obtaining one individual range per variable range register (via get_mtrr_range()) was bogus from the beginning, as these registers may cover multiple disjoint ranges. Do away with that, in favor of simply comparing masked addresses. Also, for is_var_mtrr_overlapped()'s result to be correct when called from mtrr_wrmsr(), generic_set_mtrr() must update saved state first. As minor cleanup changes, constify is_var_mtrr_overlapped()'s parameter and make mtrr_wrmsr() static. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 3272230848f36eb5bbb660216898a90048a81d9f master date: 2016-01-21 16:11:04 +0100 commit e7fa1af3b3eab2d22cf260e5f7f7b233ddd071cc Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Feb 17 16:46:25 2016 +0100 x86/mmuext: tighten TLB flush address checks Addresses passed by PV guests should be subjected to __addr_ok(), avoiding undue TLB flushes. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 828e114f7cdd9910483783ab0563b178325e579a master date: 2016-01-21 16:09:22 +0100 commit 30b0e11898e2c2c67c64bd1ec48f88de8125d678 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Feb 17 16:43:56 2016 +0100 x86/VMX: sanitize rIP before re-entering guest ... to prevent guest user mode arranging for a guest crash (due to failed VM entry). (On the AMD system I checked, hardware is doing exactly the canonicalization being added here.) Note that fixing this in an architecturally correct way would be quite a bit more involved: Making the x86 instruction emulator check all branch targets for validity, plus dealing with invalid rIP resulting from update_guest_eip() or incoming directly during a VM exit. The only way to get the latter right would be by not having hardware do the injection. Note further that there are a two early returns from vmx_vmexit_handler(): One (through vmx_failed_vmentry()) leads to domain_crash() anyway, and the other covers real mode only and can neither occur with a non-canonical rIP nor result in an altered rIP, so we don't need to force those paths through the checking logic. This is CVE-2016-2271 / XSA-170. Reported-by: å??令 <liuling-it@xxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: ffbbfda37782a2408953af1a3e00ada80bb141bc master date: 2016-02-17 16:18:08 +0100 commit 96b4955c51d37ee261b873d8ccb68a21e8f6a904 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Feb 17 16:43:21 2016 +0100 x86: enforce consistent cachability of MMIO mappings We've been told by Intel that inconsistent cachability between multiple mappings of the same page can affect system stability only when the affected page is an MMIO one. Since the stale data issue is of no relevance to the hypervisor (since all guest memory accesses go through proper accessors and validation), handling of RAM pages remains unchanged here. Any MMIO mapped by domains however needs to be done consistently (all cachable mappings or all uncachable ones), in order to avoid Machine Check exceptions. Since converting existing cachable mappings to uncachable (at the time an uncachable mapping gets established) would in the PV case require tracking all mappings, allow MMIO to only get mapped uncachable (UC, UC-, or WC). This also implies that in the PV case we mustn't use the L1 PTE update fast path when cachability flags get altered. Since in the HVM case at least for now we want to continue honoring pinned cachability attributes for pages not mapped by the hypervisor, special case handling of r/o MMIO pages (forcing UC) gets added there. Arguably the counterpart change to p2m-pt.c may not be necessary, since UC- (which already gets enforced there) is probably strict enough. Note that the shadow code changes include fixing the write protection of r/o MMIO ranges: shadow_l1e_remove_flags() and its siblings, other than l1e_remove_flags() and alike, return the new PTE (and hence ignoring their return values makes them no-ops). This is CVE-2016-2270 / XSA-154. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: c61a6f74f80eb36ed83a82f713db3143159b9009 master date: 2016-02-17 16:16:53 +0100 (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 |