|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-4.16-testing test] 167839: regressions - FAIL
flight 167839 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/167839/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 167620 build-amd64-xsm 6 xen-build fail REGR. vs. 167620 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail pass in 167814 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail pass in 167814 Tests which did not succeed, but are not blocking: test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 16 saverestore-support-check fail like 167620 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 167620 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 167620 test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass 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-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 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 test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass version targeted for testing: xen d3cb5470292eeff776e0c95a7f1e1c9e427d6425 baseline version: xen 243026a2c5ad64c05281dc8ed2f1f57c0ee5988c Last test of basis 167620 2022-01-06 13:39:16 Z 20 days Testing same since 167814 2022-01-25 13:06:50 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Jason Andryuk <jandryuk@xxxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt blocked build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-amd64-coresched-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-dom0pvh-xl-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-qemuu-freebsd11-amd64 blocked test-amd64-amd64-qemuu-freebsd12-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-dom0pvh-xl-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-xl-qcow2 blocked test-arm64-arm64-libvirt-raw fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd blocked test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-i386-xl-vhd 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 d3cb5470292eeff776e0c95a7f1e1c9e427d6425 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jan 25 13:39:44 2022 +0100 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> master commit: 81f0eaadf84d273a6ff8df3660b874a02d0e7677 master date: 2022-01-20 16:32:11 +0000 commit 21d70feed10571543061abeaedd21ce8adc60114 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jan 25 13:39:31 2022 +0100 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> master commit: 95b13fa43e0753b7514bef13abe28253e8614f62 master date: 2022-01-20 16:32:11 +0000 commit cc6fe1bb13197ddc79af480c3c74ce6d6ed3ef2c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jan 25 13:39:16 2022 +0100 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> master commit: 6536688439dbca1d08fd6db5be29c39e3917fb2f master date: 2022-01-20 16:32:11 +0000 commit 20b00921f8a62b1b19d893dd468473161706e02d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jan 25 13:38:42 2022 +0100 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> master commit: 88d3ff7ab15da277a85b39735797293fb541c718 master date: 2022-01-20 16:32:11 +0000 commit 8509519268ea6a467a97ca7891a0dca2bfe88cf7 Author: Jason Andryuk <jandryuk@xxxxxxxxx> Date: Tue Jan 25 13:38:14 2022 +0100 libxl/PCI: Fix PV hotplug & stubdom coldplug commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are reflected in the config" broken PCI hotplug (xl pci-attach) for PV domains when it moved libxl__create_pci_backend() later in the function. This also broke HVM + stubdom PCI passthrough coldplug. For that, the PCI devices are hotplugged to a running PV stubdom, and then the QEMU QMP device_add commands are made to QEMU inside the stubdom. A running PV domain calls libxl__wait_for_backend(). With the current placement of libxl__create_pci_backend(), the path does not exist and the call immediately fails: libxl: error: libxl_device.c:1388:libxl__wait_for_backend: Backend /local/domain/0/backend/pci/43/0 does not exist libxl: error: libxl_pci.c:1764:device_pci_add_done: Domain 42:libxl__device_pci_add failed for PCI device 0:2:0.0 (rc -3) libxl: error: libxl_create.c:1857:domcreate_attach_devices: Domain 42:unable to add pci devices The wait is only relevant when: 1) The domain is PV 2) The domain is running 3) The backend is already present This is because: 1) xen-pcifront is only used for PV. It does not load for HVM domains where QEMU is used. 2) If the domain is not running (starting), then the frontend state will be Initialising. xen-pciback waits for the frontend to transition to at Initialised before attempting to connect. So a wait for a non-running domain is not applicable as the backend will not transition to Connected. 3) For presence, num_devs is already used to determine if the backend needs to be created. Re-use num_devs to determine if the backend wait is necessary. The wait is necessary to avoid racing with another PCI attachment reconfiguring the front/back or changing to some other state like closing. If we are creating the backend, then we don't have to worry about the state since it is being created. Fixes: 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are reflected in the config") Signed-off-by: Jason Andryuk <jandryuk@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> master commit: 73ee2795aaef2cb086ac078bffe1c6b33c0ea91b master date: 2022-01-13 14:33:16 +0100 commit fd343ec092f3fac828f82d076ffaaca8ed3b61c9 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jan 25 13:37:59 2022 +0100 x86/time: improve TSC / CPU freq calibration accuracy While the problem report was for extreme errors, even smaller ones would better be avoided: The calculated period to run calibration loops over can (and usually will) be shorter than the actual time elapsed between first and last platform timer and TSC reads. Adjust values returned from the init functions accordingly. On a Skylake system I've tested this on accuracy (using HPET) went from detecting in some cases more than 220kHz too high a value to about ±2kHz. On other systems (or on this system, but with PMTMR) the original error range was much smaller, with less (in some cases only very little) improvement. Reported-by: James Dingwall <james-xen@xxxxxxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> master commit: a5c9a80af34eefcd6e31d0ed2b083f452cd9076d master date: 2022-01-13 14:31:52 +0100 commit 4774d06097e524913fbd4ffcea3307275c5215d1 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Jan 25 13:37:45 2022 +0100 x86/time: use relative counts in calibration loops Looping until reaching/exceeding a certain value is error prone: If the target value is close enough to the wrapping point, the loop may not terminate at all. Switch to using delta values, which then allows to fold the two loops each into just one. Fixes: 93340297802b ("x86/time: calibrate TSC against platform timer") Reported-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> master commit: 467191641d2a2fd2e43b3ae7b80399f89d339980 master date: 2022-01-13 14:30:18 +0100 commit 18d0f501596bd55412282aac3db1f0a349a68f50 Author: Julien Grall <jgrall@xxxxxxxxxx> Date: Tue Jan 25 13:35:23 2022 +0100 passthrough/x86: stop pirq iteration immediately in case of error pt_pirq_iterate() will iterate in batch over all the PIRQs. The outer loop will bail out if 'rc' is non-zero but the inner loop will continue. This means 'rc' will get clobbered and we may miss any errors (such as -ERESTART in the case of the callback pci_clean_dpci_irq()). This is CVE-2022-23035 / XSA-395. Fixes: c24536b636f2 ("replace d->nr_pirqs sized arrays with radix tree") Fixes: f6dd295381f4 ("dpci: replace tasklet with softirq") Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> master commit: 9480a1a519cf016623f657dc544cb372a82b5708 master date: 2022-01-25 13:27:02 +0100 commit 965fbc8e801c91938dd7efa831fb9078a78deeb7 Author: Julien Grall <jgrall@xxxxxxxxxx> Date: Tue Jan 25 13:35:08 2022 +0100 xen/grant-table: Only decrement the refcounter when grant is fully unmapped The grant unmapping hypercall (GNTTABOP_unmap_grant_ref) is not a simple revert of the changes done by the grant mapping hypercall (GNTTABOP_map_grant_ref). Instead, it is possible to partially (or even not) clear some flags. This will leave the grant is mapped until a future call where all the flags would be cleared. XSA-380 introduced a refcounting that is meant to only be dropped when the grant is fully unmapped. Unfortunately, unmap_common() will decrement the refcount for every successful call. A consequence is a domain would be able to underflow the refcount and trigger a BUG(). Looking at the code, it is not clear to me why a domain would want to partially clear some flags in the grant-table. But as this is part of the ABI, it is better to not change the behavior for now. Fix it by checking if the maptrack handle has been released before decrementing the refcounting. This is CVE-2022-23034 / XSA-394. Fixes: 9781b51efde2 ("gnttab: replace mapkind()") Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 975a8fb45ca186b3476e5656c6ad5dad1122dbfd master date: 2022-01-25 13:25:49 +0100 commit acdb6744460c6264785c031a37d99b8557c56195 Author: Julien Grall <jgrall@xxxxxxxxxx> Date: Tue Jan 25 13:34:55 2022 +0100 xen/arm: p2m: Always clear the P2M entry when the mapping is removed Commit 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations") allowed an entry to be invalid from the CPU PoV (lpae_is_valid()) but valid for Xen (p2m_is_valid()). This is useful to track which page is accessed and only perform an action on them (e.g. clean & invalidate the cache after a set/way instruction). Unfortunately, __p2m_set_entry() is only zeroing the P2M entry when lpae_is_valid() returns true. This means the entry will not be zeroed if the entry was valid from Xen PoV but invalid from the CPU PoV for tracking purpose. As a consequence, this will allow a domain to continue to access the page after it was removed. Resolve the issue by always zeroing the entry if it the LPAE bit is set or the entry is about to be removed. This is CVE-2022-23033 / XSA-393. Reported-by: Dmytro Firsov <Dmytro_Firsov@xxxxxxxx> Fixes: 2148a125b73b ("xen/arm: Track page accessed between batch of Set/Way operations") Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> master commit: a428b913a002eb2b7425b48029c20a52eeee1b5a master date: 2022-01-25 13:25:01 +0100 (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |