|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.7-testing test] 115189: regressions - FAIL
flight 115189 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/115189/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 114790 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 114790 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 114790 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 114698 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 114698 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 114790 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail like 114790 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 114790 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 114790 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 114790 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 114790 test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-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-i386-libvirt-qcow2 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 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-amd64-amd64-libvirt-vhd 12 migrate-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-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-libvirt 13 migrate-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-libvirt-xsm 13 migrate-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-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-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-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 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 version targeted for testing: xen 830224431b67fd2afad9bdc532dc1bede20032d5 baseline version: xen df0949d197cc753871f5df1a0358b43edd2fd365 Last test of basis 114790 2017-10-20 07:58:26 Z 5 days Testing same since 115189 2017-10-24 15:12:30 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 fail 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 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 pass test-amd64-amd64-xl-qemut-ws16-amd64 pass test-amd64-i386-xl-qemut-ws16-amd64 pass test-amd64-amd64-xl-qemuu-ws16-amd64 fail 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-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 pass 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 830224431b67fd2afad9bdc532dc1bede20032d5 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:50:14 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 6e36296c6c38fa735cb91650c443fb096ac0a79d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:49:44 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 5805ab112bd9d509efcc6aa24c52085c5eb7ef71 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:48:50 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 bc37a36ab1bcd879740523515615f61ba2bde6c0 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:43:43 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 cf451a8253e0c685d4713543a8033193568df763 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:43:08 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 24955c3143f2b07178d648951147fcd974bd0e37 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:42:39 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 46d90a78f6439da8ae175691762033885866209e Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:42:13 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 cd9ee1f72d46056006da3d695c81be5584922ad4 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:41:40 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 2e24a9ed72720e0f3ec9bc92b92240915f46e7b7 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:40:56 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 d0500f203285fe3d12b83a837b21930e4bac69da Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 24 16:40:23 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 f03b9e86e7e18cbbc0b9ecb01ae74730362c6603 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Oct 24 16:39:33 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 |