[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 167780: regressions - FAIL
flight 167780 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/167780/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 167761 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass version targeted for testing: xen 0626219dcc6a4376c1a4b04209d6c15d06e23875 baseline version: xen 4e1df69cc9f51b2e017af1da3ed5b45917642115 Last test of basis 167761 2022-01-20 14:00:29 Z 0 days Testing same since 167764 2022-01-20 20:01:37 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-libvirt blocked ------------------------------------------------------------ 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 0626219dcc6a4376c1a4b04209d6c15d06e23875 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Jan 17 18:40:50 2022 +0000 x86/hvm: Drop hvm_{get,set}_guest_bndcfgs() and use {get,set}_regs() instead hvm_{get,set}_guest_bndcfgs() are thin wrappers around accessing MSR_BNDCFGS. MPX was implemented on Skylake uarch CPUs and dropped in subsequent CPUs, and is disabled by default in Xen VMs. It would be nice to move all the logic into vmx_msr_{read,write}_intercept(), but the common HVM migration code uses guest_{rd,wr}msr(). Therefore, use {get,set}_regs() to reduce the quantity of "common" HVM code. In lieu of having hvm_set_guest_bndcfgs() split out, use some #ifdef CONFIG_HVM in guest_wrmsr(). In vmx_{get,set}_regs(), split the switch statements into two depending on whether the require remote VMCS acquisition or not. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 81f0eaadf84d273a6ff8df3660b874a02d0e7677 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jan 12 15:47:27 2022 +0000 x86/spec-ctrl: Fix NMI race condition with VT-x MSR_SPEC_CTRL handling The logic was based on a mistaken understanding of how NMI blocking on vmexit works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits. Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler path, and the guest's value will be clobbered before it is saved. Switch to using MSR load/save lists. This causes the guest value to be saved atomically with respect to NMIs/MCEs/etc. First, update vmx_cpuid_policy_changed() to configure the load/save lists at the same time as configuring the intercepts. This function is always used in remote context, so extend the vmx_vmcs_{enter,exit}() block to cover the whole function, rather than having multiple remote acquisitions of the same VMCS. Both of vmx_{add,del}_guest_msr() can fail. The -ESRCH delete case is fine, but all others are fatal to the running of the VM, so handle them using domain_crash() - this path is only used during domain construction anyway. Second, update vmx_{get,set}_reg() to use the MSR load/save lists rather than vcpu_msrs, and update the vcpu_msrs comment to describe the new state location. Finally, adjust the entry/exit asm. Because the guest value is saved and loaded atomically, we do not need to manually load the guest value, nor do we need to enable SCF_use_shadow. This lets us remove the use of DO_SPEC_CTRL_EXIT_TO_GUEST. Additionally, SPEC_CTRL_ENTRY_FROM_PV gets removed too, because on an early entry failure, we're no longer in the guest MSR_SPEC_CTRL context needing to switch back to Xen's context. The only action remaining is to load Xen's MSR_SPEC_CTRL value on vmexit. We could in principle use the host msr list, but is expected to complicated future work. Delete DO_SPEC_CTRL_ENTRY_FROM_HVM entirely, and use a shorter code sequence to simply reload Xen's setting from the top-of-stack block. Adjust the comment at the top of spec_ctrl_asm.h in light of this bugfix. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 95b13fa43e0753b7514bef13abe28253e8614f62 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jan 12 16:36:29 2022 +0000 x86/spec-ctrl: Drop SPEC_CTRL_{ENTRY_FROM,EXIT_TO}_HVM These were written before Spectre/Meltdown went public, and there was large uncertainty in how the protections would evolve. As it turns out, they're very specific to Intel hardware, and not very suitable for AMD. Drop the macros, opencoding the relevant subset of functionality, and leaving grep-fodder to locate the logic. No change at all for VT-x. For AMD, the only relevant piece of functionality is DO_OVERWRITE_RSB, although we will soon be adding (different) logic to handle MSR_SPEC_CTRL. This has a marginal improvement of removing an unconditional pile of long-nops from the vmentry/exit path. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> commit 6536688439dbca1d08fd6db5be29c39e3917fb2f Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Jan 12 13:52:47 2022 +0000 x86/msr: Split MSR_SPEC_CTRL handling In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, move MSR_SPEC_CTRL handling into the new {pv,hvm}_{get,set}_reg() infrastructure. Duplicate the msrs->spec_ctrl.raw accesses in the PV and VT-x paths for now. The SVM path is currently unreachable because of the CPUID policy. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 88d3ff7ab15da277a85b39735797293fb541c718 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Jan 17 12:28:39 2022 +0000 x86/guest: Introduce {get,set}_reg() infrastructure Various registers have per-guest-type or per-vendor locations or access requirements. To support their use from common code, provide accessors which allow for per-guest-type behaviour. For now, just infrastructure handling default cases and expectations. Subsequent patches will start handling registers using this infrastructure. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> (qemu changes not included)
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |