|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.8-testing test] 115185: regressions - FAIL
flight 115185 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/115185/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114689 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 114661 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 114689 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 114689 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114689 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 114689 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114689 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 114689 test-amd64-amd64-xl-rtds 10 debian-install fail like 114689 build-amd64-prev 7 xen-build/dist-test fail never pass build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 03af24c35ed38967ab8151fdb53da3f6f6cc0872 baseline version: xen 0c647de4db305a0b02f73684f9637acbf7b7f92a Last test of basis 114689 2017-10-18 11:16:06 Z 6 days Testing same since 115185 2017-10-24 14:45:00 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass 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-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-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-rumprun-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 pass test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 pass test-amd64-i386-xl-qemuu-ws16-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-rumprun-i386 pass test-amd64-amd64-xl-qemut-win10-i386 fail test-amd64-i386-xl-qemut-win10-i386 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch 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-amd64-i386-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd 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 03af24c35ed38967ab8151fdb53da3f6f6cc0872 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:29:06 2017 +0200 x86emul: handle address wrapping This just the emulator part of commit 7869e2bafe ("x86emul/fuzz: add rudimentary limit checking"): Several adjustments to the emulator's address calculations are needed: While the DstBitBase one is really mandatory, the specification allows for either original or new behavior for two-part accesses. Observed behavior on real hardware, however, is for such accesses to silently wrap at the 2^^32 boundary in other than 64-bit mode, just like they do at the 2^^64 boundary in 64-bit mode, which our code is now being brought in line with. While adding truncate_ea() invocations there, also convert open coded instances of it. Reported-by: George Dunlap <george.dunlap@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 4a3c5e119aa53b3edbfd2d1c1f45383fc1063940 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:28:41 2017 +0200 VMX: PLATFORM_INFO MSR is r/o Therefore all write attempts should produce #GP, just like on real hardware. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 2956a3fdd9193cee857cc0d6ba2381712cf15b65 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:28:11 2017 +0200 x86: avoid #GP for PV guest MSR accesses Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs, leading to ugly recovered #GP fault messages with debug builds on older systems. We can do better, so introduce synthetic feature flags for both this and PLATFORM_INFO to avoid the rdmsr_safe() altogether. Note that the r/o nature of PLATFORM_INFO is now also being enforced. The rdmsr_safe() uses for MISC_ENABLE are left in place as benign - it exists for all 64-bit capable Intel CPUs (see e.g. early_init_intel()). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 3cd9d8440b6cc61ccae4da10855563a395632306 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:27:34 2017 +0200 x86/vvmx: Fix WRMSR interception of VMX MSRs FEATURE_CONTROL is already read with LOCK bit set (so is unmodifiable), and all VMX MSRs are read-only. Also, fix the MSR_IA32_VMX_TRUE_ENTRY_CTLS bound to be MSR_IA32_VMX_VMFUNC, rather than having the intervening MSRs falling into the default case. Raise #GP faults if the guest tries to modify any of them. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 46c3acb308bf0cd044b114e637aacaf18b957618 master date: 2017-06-30 11:27:50 +0100 commit ffb294731d3b748c36b6ee3b781d5aeb378ce7d1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:27:04 2017 +0200 x86: fix do_update_va_mapping_otherdomain() wrt translated domains While I can't seem to find any users of this hypercall (being a likely explanation of why the problem wasn't noticed so far), just like for do_mmu_update() paged-out and shared page handling is needed here. Move all this logic into mod_l1_entry(), which then also results in no longer - doing any of this handling for non-present PTEs, - acquiring two temporary page references when one is already more than enough. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 46aaf41ee099a048d7a554c03ae01bcdaa07f776 master date: 2017-10-13 12:43:41 +0200 commit f457a229bc16cb33c20c80fcc91af36e04b1e01f Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:26:33 2017 +0200 x86: request page table page-in for the correct domain The domain passed to p2m_mem_paging_populate() should match the one passed to the corresponding get_page_from_gfn(). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 66b7f58e585e39fb19bbf38df02fff5a80eba1ff master date: 2017-10-13 12:42:43 +0200 commit 011a612fa2aab667a097dc4bcbb4ccf81bbe6b1d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:26:03 2017 +0200 xen/domctl: Fix Xen heap leak via XEN_DOMCTL_getvcpucontext The backing structure for XEN_DOMCTL_getvcpucontext is only zeroed in the x86 HVM case. At the very least, this means that ARM returns junk through its flags field (as it is only ever conditionally or'd into), and x86 PV leaks data through gdt_frames[14...15]. (An exhaustive search for other leaks hasn't been performed). Unconditionally zero the memory upon allocation, and forgo the double clear for x86 HVM. These hypercalls are not on hotpaths. Note that this does not qualify for an XSA. Per XSA-77, XEN_DOMCTL_getvcpucontext is unsafe for disaggregation, meaning that only the control domain can use this hypercall. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 3b2eeb7412e529f38d1e8b872ba0bc6ab09a7008 master date: 2017-10-09 12:43:21 +0100 commit 5b37b5cf0a716c390b16cf1a845699291e3f66ba Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:25:30 2017 +0200 x86/PV: fix/generalize guest nul selector handling Segment bases (and limits) aren't being cleared by the loading of a nul selector into a segment register on AMD CPUs. Therefore, if an outgoing vCPU has a non-zero base in FS or GS and the subsequent incoming vCPU has a non-zero but nul selector in the respective register(s), the selector value(s) would be loaded without clearing the segment base(s) in the hidden register portion. Since the ABI states "zero" in its description of the fs and gs fields, it is worth noting that the chosen approach to fix this alters the written down ABI. I consider this preferrable over enforcing the previously written down behavior, as nul selectors are far more likely to be what was meant from the beginning. The adjustments also eliminate an inconsistency between FS and GS handling: Old code had an extra pointless (gs_base_user was always zero when DIRTY_GS was set) conditional for GS. The old bitkeeper changeset has no explanation for this asymmetry. Inspired by Linux commit e137a4d8f4dd2e277e355495b6b2cb241a8693c3. Additionally for DS and ES a flat selector is being loaded prior to the loading of a nul one on AMD CPUs, just as a precautionary measure (we're not currently aware of ways for a guest to deduce the base of a segment register which has a nul selector loaded). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 4e383df8650d72e47e2ca4ebfc4f6986f791d2f2 master date: 2017-10-04 14:17:08 +0200 commit 379213ca254a316430d7a96148e24683ecc12fd4 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:24:48 2017 +0200 x86/msr: Correct the definition of MSR_IA32_APICBASE_BASE 0xfffff << 12 is undefined behaviour, due to shifting into the sign bit of an integer. Spotted by the Undefined Behaviour Sanitiser Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> master commit: dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e master date: 2017-10-03 17:45:24 +0100 commit f3b2080a55b773f1d59231969643075576da63d9 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:24:18 2017 +0200 x86/svm: Fix a livelock when trying to run shadowed unpaged guests On AMD processors which support SMEP (Some Fam16h processors) and SMAP (Zen, Fam17h), a guest which is running with shadow paging and clears CR0.PG while keeping CR4.{SMEP,SMAP} set will livelock, as hardware raises #PF which the shadow pagetable concludes shouldn't happen. This occurs because hardware is running with host paging settings, which causes the guests choice of SMEP/SMAP to actually take effect, even though they shouldn't from the guests point of view. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> master commit: 3164f2f9db1e63ea64c3f9520d40cb09920d2b35 master date: 2017-10-02 13:57:34 +0100 commit fcbbd0faeeb9a7dd204287fee7871df397c957ee Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:22:49 2017 +0200 gnttab: fix pin count / page reference race Dropping page references before decrementing pin counts is a bad idea if assumptions are being made that a non-zero pin count implies a valid page. Fix the order of operations in gnttab_copy_release_buf(), but at the same time also remove the assertion that was found to trigger: map_grant_ref() also has the potential of causing a race here, and changing the order of operations there would likely be quite a bit more involved. This is CVE-2017-15597 / XSA-236. Reported-by: Pawel Wieczorkiewicz <wipawel@xxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: e008f7619dcd6d549727c9635b3f9f3c7ee483ed master date: 2017-10-24 16:01:33 +0200 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |