[xen-unstable test] 180965: tolerable FAIL - PUSHED
flight 180965 xen-unstable real [real] flight 180971 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180965/ http://logs.test-lab.xenproject.org/osstest/logs/180971/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 8 xen-bootfail pass in 180971-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 180971 never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 180971 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 180930 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 180930 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 180930 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 180930 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 180930 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180930 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180930 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 180930 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180930 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass version targeted for testing: xen f54dd5b53ee516fa1d4c106e0744ce0083acfcdc baseline version: xen 380c6c170393c48852d4f2b1ea97125a399cfc61 Last test of basis 180930 2023-05-24 17:38:36 Z
[GIT PULL] xen: branch for v6.4-rc4
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.4-rc4-tag xen: branch for v6.4-rc4 It contains 3 fixes: - a double free fix in the Xen pvcalls backend driver - a fix for a regression causing the MSI related sysfs entries to not being created in Xen PV guests - a fix in the Xen blkfront driver for handling insane input data better Thanks. Juergen arch/x86/pci/xen.c | 8 +--- drivers/block/xen-blkfront.c | 3 ++- drivers/xen/pvcalls-back.c | 9 - include/linux/msi.h | 9 - kernel/irq/msi.c | 4 ++-- 5 files changed, 21 insertions(+), 12 deletions(-) Dan Carpenter (1): xen/pvcalls-back: fix double frees with pvcalls_new_active_socket() Maximilian Heyne (1): x86/pci/xen: populate MSI sysfs entries Ross Lagerwall (1): xen/blkfront: Only check REQ_FUA for writes
[qemu-mainline test] 180972: regressions - FAIL
flight 180972 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
[linux-linus test] 180969: regressions - FAIL
flight 180969 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/180969/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278 build-arm64-pvops 6 kernel-build fail REGR. vs. 180278 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-examine 8 reboot fail like 180278 test-armhf-armhf-xl-arndale 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-qcow2 8 xen-bootfail like 180278 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180278 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-vhd 8 xen-boot fail like 180278 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180278 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-multivcpu 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-raw 8 xen-boot fail like 180278 test-armhf-armhf-libvirt 8 xen-boot fail like 180278 test-armhf-armhf-xl-credit2 8 xen-boot fail like 180278 test-armhf-armhf-xl-rtds 8 xen-boot fail like 180278 test-armhf-armhf-xl 8 xen-boot fail like 180278 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180278 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linuxa92c9ab69f6696b26ef0c1ca3e8b922d1fc82e86 baseline version: linux6c538e1adbfc696ac4747fb10d63e704344f763d Last test of basis 180278 2023-04-16 19:41:46 Z 40 days Failing since180281 2023-04-17 06:24:36 Z 39 days 74 attempts Testing same since 180969 2023-05-26 23:41:48 Z0 days1 attempts 2538 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopsfail build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl blocked test-armhf-armhf-xl fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test
[qemu-mainline test] 180968: regressions - FAIL
flight 180968 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
[linux-linus test] 180959: regressions - FAIL
flight 180959 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/180959/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278 build-arm64-xsm 6 xen-buildfail REGR. vs. 180278 test-amd64-amd64-libvirt-qcow2 19 guest-start/debian.repeat fail REGR. vs. 180278 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-examine 8 reboot fail like 180278 test-armhf-armhf-xl-arndale 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-qcow2 8 xen-bootfail like 180278 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180278 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-vhd 8 xen-boot fail like 180278 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180278 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-multivcpu 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-raw 8 xen-boot fail like 180278 test-armhf-armhf-libvirt 8 xen-boot fail like 180278 test-armhf-armhf-xl-credit2 8 xen-boot fail like 180278 test-armhf-armhf-xl-rtds 8 xen-boot fail like 180278 test-armhf-armhf-xl 8 xen-boot fail like 180278 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180278 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linux0d85b27b0cc6b5cf54567c5ad913a247a71583ce baseline version: linux6c538e1adbfc696ac4747fb10d63e704344f763d Last test of basis 180278 2023-04-16 19:41:46 Z 40 days Failing since180281 2023-04-17 06:24:36 Z 39 days 73 attempts Testing same since 180959 2023-05-26 10:09:30 Z0 days1 attempts 2518 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl
[qemu-mainline test] 180966: regressions - FAIL
flight 180966 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180966/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
[qemu-mainline test] 180962: regressions - FAIL
flight 180962 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180962/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
Re: [PATCH 3/3] x86: Expose Automatic IBRS to guests
On 26/05/2023 4:00 pm, Alejandro Vallejo wrote: > Expose AutoIBRS to HVM guests, because they can just use it. Make sure > writes to EFER:AIBRSE are gated on the feature being exposed. Also hide > EFER:AIBRSE from PV guests as they have no say in the matter. > > Signed-off-by: Alejandro Vallejo It's worth saying "EFER is fully switched by VMRUN, so there's nothing further for Xen to do in order for HVM guests to use AutoIBRS". We can in principle support AutoIBRS on PV guests, but it's fine not to for now. This patch probably wants reordering to #2, because it is entirely independent of what Xen is doing with AutoIBRS for spec safety. It will need a minor rebase over the bit name shortening, but otherwise Reviewed-by: Andrew Cooper
[libvirt test] 180955: tolerable all pass - PUSHED
flight 180955 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/180955/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 180939 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 180939 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180939 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass version targeted for testing: libvirt a8c983d0fa1ba915f7a75deeceb20da1c88fd1db baseline version: libvirt 96c8d39af007000daf3d5dfa845365f66379aaac Last test of basis 180939 2023-05-25 04:20:22 Z1 days Testing same since 180955 2023-05-26 04:18:51 Z0 days1 attempts People who touched revisions under test: Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-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 a
Re: [PATCH 1/3] x86: Add bit definitions for Automatic IBRS
On Fri, May 26, 2023 at 05:46:51PM +0100, Andrew Cooper wrote: > AIBRS and EIBRS are very much not the same, and I argued hard to not > have Linux confuse the too, but alas. > > Don't mention EIBRS at all. > > Simply "Auto IBRS is a new feature in AMD Zen4 CPUs and late, intended > to reduce the overhead involved with operating IBRS", or something along > these lines. Sure. I did go out of my way to avoid ambiguityin the code, but it's true the commit message is unfortunate. > > > diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c > > index 5d0c64a45f..e487885a5c 100644 > > --- a/tools/misc/xen-cpuid.c > > +++ b/tools/misc/xen-cpuid.c > > @@ -200,6 +200,8 @@ static const char *const str_e21a[32] = > > [ 2] = "lfence+", > > [ 6] = "nscb", > > > > +[ 8] = "auto-ibrs", > > + > > This wants to be: > > [ 6] = "nscb", > + [ 8] = "auto-ibrs", > > as they are adjacent with names in two columns. Gaps are only for > discontinuities in numbering. > > [...] > > Were possible, we want to use the same names. AUTO_IBRS is fine here, > and shorter to use throughout Xen. Sure to both. Alejandro
Re: [PATCH 2/3] x86: Add support for AMD's Automatic IBRS
On Fri, May 26, 2023 at 12:28:39PM -0400, Jason Andryuk wrote:
> > if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
> > +{
> > cpuid(0x8008, &tmp, &e8b, &tmp, &tmp);
> > +cpuid(0x8021, &e21a, &tmp, &tmp, &tmp);
> > +}
>
> Do you need to check boot_cpu_data.extended_cpuid_level >= 0x8021?
>
> Regards,
> Jason
True that, yes. Will do on v2.
Alejandro
Re: [PATCH v1 6/9] KVM: x86: Add Heki hypervisor support
On 08/05/2023 23:18, Wei Liu wrote:
On Fri, May 05, 2023 at 05:20:43PM +0200, Mickaël Salaün wrote:
From: Madhavan T. Venkataraman
Each supported hypervisor in x86 implements a struct x86_hyper_init to
define the init functions for the hypervisor. Define a new init_heki()
entry point in struct x86_hyper_init. Hypervisors that support Heki
must define this init_heki() function. Call init_heki() of the chosen
hypervisor in init_hypervisor_platform().
Create a heki_hypervisor structure that each hypervisor can fill
with its data and functions. This will allow the Heki feature to work
in a hypervisor agnostic way.
Declare and initialize a "heki_hypervisor" structure for KVM so KVM can
support Heki. Define the init_heki() function for KVM. In init_heki(),
set the hypervisor field in the generic "heki" structure to the KVM
"heki_hypervisor". After this point, generic Heki code can access the
KVM Heki data and functions.
[...]
+static void kvm_init_heki(void)
+{
+ long err;
+
+ if (!kvm_para_available())
+ /* Cannot make KVM hypercalls. */
+ return;
+
+ err = kvm_hypercall3(KVM_HC_LOCK_MEM_PAGE_RANGES, -1, -1, -1);
Why not do a proper version check or capability check here? If the ABI
or supported features ever change then we have something to rely on?
The attributes will indeed get extended, but I wanted to have a simple
proposal for now.
Do you mean to get the version of this hypercall e.g., with a dedicated
flag, like with the
landlock_create_ruleset/LANDLOCK_CREATE_RULESET_VERSION syscall?
Thanks,
Wei.
Re: [PATCH 1/3] x86: Add bit definitions for Automatic IBRS
On 26/05/2023 4:00 pm, Alejandro Vallejo wrote: > This is AMD's version of Intel's Enhanced IBRS. Exposed in CPUID > and toggled in EFER. AIBRS and EIBRS are very much not the same, and I argued hard to not have Linux confuse the too, but alas. Don't mention EIBRS at all. Simply "Auto IBRS is a new feature in AMD Zen4 CPUs and late, intended to reduce the overhead involved with operating IBRS", or something along these lines. > diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c > index 5d0c64a45f..e487885a5c 100644 > --- a/tools/misc/xen-cpuid.c > +++ b/tools/misc/xen-cpuid.c > @@ -200,6 +200,8 @@ static const char *const str_e21a[32] = > [ 2] = "lfence+", > [ 6] = "nscb", > > +[ 8] = "auto-ibrs", > + This wants to be: [ 6] = "nscb", + [ 8] = "auto-ibrs", as they are adjacent with names in two columns. Gaps are only for discontinuities in numbering. > diff --git a/xen/include/public/arch-x86/cpufeatureset.h > b/xen/include/public/arch-x86/cpufeatureset.h > index 777041425e..e3952f62bc 100644 > --- a/xen/include/public/arch-x86/cpufeatureset.h > +++ b/xen/include/public/arch-x86/cpufeatureset.h > @@ -287,6 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA > Instructions */ > /* AMD-defined CPU features, CPUID level 0x8021.eax, word 11 */ > XEN_CPUFEATURE(LFENCE_DISPATCH,11*32+ 2) /*A LFENCE always serializing > */ > XEN_CPUFEATURE(NSCB, 11*32+ 6) /*A Null Selector Clears Base > (and limit too) */ > +XEN_CPUFEATURE(AUTOMATIC_IBRS, 11*32+ 8) /* HW can handle IBRS on its > own */ Were possible, we want to use the same names. AUTO_IBRS is fine here, and shorter to use throughout Xen. Furthermore, it must match the cpu_has_* name, and that's already in the better form. ~Andrew
Re: [PATCH 2/3] x86: Add support for AMD's Automatic IBRS
On Fri, May 26, 2023 at 11:01 AM Alejandro Vallejo
wrote:
>
> In cases where AutoIBRS is supported by the host:
>
> * Prefer AutoIBRS to retpolines as BTI mitigation in heuristics
> calculations.
> * Always enable AutoIBRS if IBRS is chosen as a BTI mitigation.
> * Avoid stuffing the RAS/RSB on VMEXIT if AutoIBRS is enabled.
> * Delay setting AutoIBRS until after dom0 is set up, just like setting
> SPEC_CTRL.
>
> Signed-off-by: Alejandro Vallejo
> ---
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -390,7 +390,7 @@ custom_param("pv-l1tf", parse_pv_l1tf);
> @@ -399,7 +399,10 @@ static void __init print_details(enum ind_thunk thunk)
> if ( max >= 2 )
> cpuid_count(7, 2, &tmp, &tmp, &tmp, &_7d2);
> if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
> +{
> cpuid(0x8008, &tmp, &e8b, &tmp, &tmp);
> +cpuid(0x8021, &e21a, &tmp, &tmp, &tmp);
> +}
Do you need to check boot_cpu_data.extended_cpuid_level >= 0x8021?
Regards,
Jason
Re: [ANNOUNCE] KVM Microconference at LPC 2023
See James Morris's proposal here: https://lore.kernel.org/all/17f62cb1-a5de-2020-2041-359b8e96b...@linux.microsoft.com/ On 26/05/2023 04:36, James Morris wrote: > [Side topic] > > Would folks be interested in a Linux Plumbers Conference MC on this > topic generally, across different hypervisors, VMMs, and architectures? > > If so, please let me know who the key folk would be and we can try writing > up an MC proposal. The fine-grain memory management proposal from James Gowans looks interesting, especially the "side-car" virtual machines: https://lore.kernel.org/all/88db2d9cb42e471692ff1feb0b9ca855906a9d95.ca...@amazon.com/ On 09/05/2023 11:55, Paolo Bonzini wrote: Hi all! We are planning on submitting a CFP to host a KVM Microconference at Linux Plumbers Conference 2023. To help justify the proposal, we would like to gather a list of folks that would likely attend, and crowdsource a list of topics to include in the proposal. For both this year and future years, the intent is that a KVM Microconference will complement KVM Forum, *NOT* supplant it. As you probably noticed, KVM Forum is going through a somewhat radical change in how it's organized; the conference is now free and (with some help from Red Hat) organized directly by the KVM and QEMU communities. Despite the unexpected changes and some teething pains, community response to KVM Forum continues to be overwhelmingly positive! KVM Forum will remain the venue of choice for KVM/userspace collaboration, for educational content covering both KVM and userspace, and to discuss new features in QEMU and other userspace projects. At least on the x86 side, however, the success of KVM Forum led us virtualization folks to operate in relative isolation. KVM depends on and impacts multiple subsystems (MM, scheduler, perf) in profound ways, and recently we’ve seen more and more ideas/features that require non-trivial changes outside KVM and buy-in from stakeholders that (typically) do not attend KVM Forum. Linux Plumbers Conference is a natural place to establish such collaboration within the kernel. Therefore, the aim of the KVM Microconference will be: * to provide a setting in which to discuss KVM and kernel internals * to increase collaboration and reduce friction with other subsystems * to discuss system virtualization issues that require coordination with other subsystems (such as VFIO, or guest support in arch/) Below is a rough draft of the planned CFP submission. Thanks! Paolo Bonzini (KVM Maintainer) Sean Christopherson (KVM x86 Co-Maintainer) Marc Zyngier (KVM ARM Co-Maintainer) === KVM Microconference === KVM (Kernel-based Virtual Machine) enables the use of hardware features to improve the efficiency, performance, and security of virtual machines created and managed by userspace. KVM was originally developed to host and accelerate "full" virtual machines running a traditional kernel and operating system, but has long since expanded to cover a wide array of use cases, e.g. hosting real time workloads, sandboxing untrusted workloads, deprivileging third party code, reducing the trusted computed base of security sensitive workloads, etc. As KVM's use cases have grown, so too have the requirements placed on KVM and the interactions between it and other kernel subsystems. The KVM Microconference will focus on how to evolve KVM and adjacent subsystems in order to satisfy new and upcoming requirements: serving guest memory that cannot be accessed by host userspace[1], providing accurate, feature-rich PMU/perf virtualization in cloud VMs[2], etc. Potential Topics: - Serving inaccessible/unmappable memory for KVM guests (protected VMs) - Optimizing mmu_notifiers, e.g. reducing TLB flushes and spurious zapping - Supporting multiple KVM modules (for non-disruptive upgrades) - Improving and hardening KVM+perf interactions - Implementing arch-agnostic abstractions in KVM (e.g. MMU) - Defining KVM requirements for hardware vendors - Utilizing "fault" injection to increase test coverage of edge cases - KVM vs VFIO (e.g. memory types, a rather hot topic on the ARM side) Key Attendees: - Paolo Bonzini (KVM Maintainer) - Sean Christopherson (KVM x86 Co-Maintainer) - Your name could be here! [1] https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.p...@linux.intel.com [2] https://lore.kernel.org/all/CALMp9eRBOmwz=mspp0m5q093k3rmueasf3vel39mgv5br9w...@mail.gmail.com
[xen-unstable-smoke test] 180963: tolerable all pass - PUSHED
flight 180963 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/180963/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass version targeted for testing: xen f54dd5b53ee516fa1d4c106e0744ce0083acfcdc baseline version: xen 40cd186bfd15655b7d9d3ee149292c718c208917 Last test of basis 180956 2023-05-26 08:01:52 Z0 days Testing same since 180963 2023-05-26 13:01:58 Z0 days1 attempts People who touched revisions under test: Ayan Kumar Halder Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 40cd186bfd..f54dd5b53e f54dd5b53ee516fa1d4c106e0744ce0083acfcdc -> smoke
[xen-unstable test] 180953: regressions - FAIL
flight 180953 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/180953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 180930 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-freebsd11-amd64 19 guest-localmigrate/x10 fail in 180946 pass in 180953 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 180946 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail in 180946 like 180930 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 180930 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 180930 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 180930 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 180930 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 180930 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180930 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180930 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180930 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 180930 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass version targeted for testing: xen 354be8936d97d4f2cb8cc00
Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity
On 25/05/2023 17:52, Edgecombe, Rick P wrote: On Thu, 2023-05-25 at 15:59 +0200, Mickaël Salaün wrote: [ snip ] The kernel often creates writable aliases in order to write to protected data (kernel text, etc). Some of this is done right as text is being first written out (alternatives for example), and some happens way later (jump labels, etc). So for verification, I wonder what stage you would be verifying? If you want to verify the end state, you would have to maintain knowledge in the verifier of all the touch-ups the kernel does. I think it would get very tricky. For now, in the static kernel case, all rodata and text GPA is restricted, so aliasing such memory in a writable way before or after the KVM enforcement would still restrict write access to this memory, which could be an issue but not a security one. Do you have such examples in mind? On x86, look at all the callers of the text_poke() family. In arch/x86/include/asm/text-patching.h. OK, thanks! It also seems it will be a decent ask for the guest kernel to keep track of GPA permissions as well as normal virtual memory pemirssions, if this thing is not widely used. This would indeed be required to properly handle the dynamic cases. So I wondering if you could go in two directions with this: 1. Make this a feature only for super locked down kernels (no modules, etc). Forbid any configurations that might modify text. But eBPF is used for seccomp, so you might be turning off some security protections to get this. Good idea. For "super locked down kernels" :) , we should disable all kernel executable changes with the related kernel build configuration (e.g. eBPF JIT, kernel module, kprobes…) to make sure there is no such legitimate access. This looks like an acceptable initial feature. How many users do you think will want this protection but not protections that would have to be disabled? The main one that came to mind for me is cBPF seccomp stuff. But also, the alternative to JITing cBPF is the eBPF interpreter which AFAIU is considered a juicy enough target for speculative attacks that they created an option to compile it out. And leaving an interpreter in the kernel means any data could be "executed" in the normal non- speculative scenario, kind of working around the hypervisor executable protections. Dropping e/cBPF entirely would be an option, but then I wonder how many users you have left. Hopefully that is all correct, it's hard to keep track with the pace of BPF development. seccomp-bpf doesn't rely on JIT, so it is not an issue. For eBPF, JIT is optional, but other text changes may be required according to the eBPF program type (e.g. using kprobes). I wonder if it might be a good idea to POC the guest side before settling on the KVM interface. Then you can also look at the whole thing and judge how much usage it would get for the different options of restrictions. The next step is to handle dynamic permissions, but it will be easier to first implement that in KVM itself (which already has the required authentication code). The current interface may be flexible enough though, only new attribute flags should be required (and potentially an async mode). Anyway, this will enable to look at the whole thing. 2. Loosen the rules to allow the protections to not be so one-way enable. Get less security, but used more widely. This is our goal. I think both static and dynamic cases are legitimate and have value according to the level of security sought. This should be a build-time configuration. Yea, the proper way to do this is probably to move all text handling stuff into a separate domain of some sort, like you mentioned elsewhere. It would be quite a job. Not necessarily to move this code, but to make sure that the changes are legitimate (e.g. text signatures, legitimate addresses). This doesn't need to be perfect but it should improve the current state by increasing the cost of attacks.
Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity
On 25/05/2023 15:59, Mickaël Salaün wrote: On 25/05/2023 00:20, Edgecombe, Rick P wrote: On Fri, 2023-05-05 at 17:20 +0200, Mickaël Salaün wrote: # How does it work? This implementation mainly leverages KVM capabilities to control the Second Layer Address Translation (or the Two Dimensional Paging e.g., Intel's EPT or AMD's RVI/NPT) and Mode Based Execution Control (Intel's MBEC) introduced with the Kaby Lake (7th generation) architecture. This allows to set permissions on memory pages in a complementary way to the guest kernel's managed memory permissions. Once these permissions are set, they are locked and there is no way back. A first KVM_HC_LOCK_MEM_PAGE_RANGES hypercall enables the guest kernel to lock a set of its memory page ranges with either the HEKI_ATTR_MEM_NOWRITE or the HEKI_ATTR_MEM_EXEC attribute. The first one denies write access to a specific set of pages (allow-list approach), and the second only allows kernel execution for a set of pages (deny-list approach). The current implementation sets the whole kernel's .rodata (i.e., any const or __ro_after_init variables, which includes critical security data such as LSM parameters) and .text sections as non-writable, and the .text section is the only one where kernel execution is allowed. This is possible thanks to the new MBEC support also brough by this series (otherwise the vDSO would have to be executable). Thanks to this hardware support (VT-x, EPT and MBEC), the performance impact of such guest protection is negligible. The second KVM_HC_LOCK_CR_UPDATE hypercall enables guests to pin some of its CPU control register flags (e.g., X86_CR0_WP, X86_CR4_SMEP, X86_CR4_SMAP), which is another complementary hardening mechanism. Heki can be enabled with the heki=1 boot command argument. Can the guest kernel ask the host VMM's emulated devices to DMA into the protected data? It should go through the host userspace mappings I think, which don't care about EPT permissions. Or did I miss where you are protecting that another way? There are a lot of easy ways to ask the host to write to guest memory that don't involve the EPT. You probably need to protect the host userspace mappings, and also the places in KVM that kmap a GPA provided by the guest. Good point, I'll check this confused deputy attack. Extended KVM protections should indeed handle all ways to map guests' memory. I'm wondering if current VMMs would gracefully handle such new restrictions though. I guess the host could map arbitrary data to the guest, so that need to be handled, but how could the VMM (not the host kernel) bypass/update EPT initially used for the guest (and potentially later mapped to the host)?
[PATCH 0/3] Add Automatic IBRS support
Adds support for AMD's Automatic IBRS. It's a set-and-forget feature that prevents lower privileged executions from affecting speculations of higher privileged executions, so retpolines are not required. Furthermore, it clears the RSB upon VMEXIT, so we can avoid doing it if the feature is present. Patch 1 adds the relevant bit definitions for CPUID and EFER. Patch 2 Hooks up AutoIBRS to spec_ctrl. so it's used when IBRS is picked. It also tweaks the heuristics so AutoIBRS is preferred over retpolines as BTI mitigation. This is enough to protect Xen. Patch 3 exposes the feature to HVM guests. Alejandro Vallejo (3): x86: Add bit definitions for Automatic IBRS x86: Add support for AMD's Automatic IBRS x86: Expose Automatic IBRS to guests tools/libs/light/libxl_cpuid.c | 1 + tools/misc/xen-cpuid.c | 2 + xen/arch/x86/hvm/hvm.c | 3 ++ xen/arch/x86/include/asm/cpufeature.h | 1 + xen/arch/x86/include/asm/msr-index.h| 4 +- xen/arch/x86/pv/emul-priv-op.c | 4 +- xen/arch/x86/setup.c| 3 ++ xen/arch/x86/smpboot.c | 3 ++ xen/arch/x86/spec_ctrl.c| 52 +++-- xen/include/public/arch-x86/cpufeatureset.h | 1 + 10 files changed, 56 insertions(+), 18 deletions(-) -- 2.34.1
[PATCH 3/3] x86: Expose Automatic IBRS to guests
Expose AutoIBRS to HVM guests, because they can just use it. Make sure
writes to EFER:AIBRSE are gated on the feature being exposed. Also hide
EFER:AIBRSE from PV guests as they have no say in the matter.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/hvm/hvm.c | 3 +++
xen/arch/x86/include/asm/msr-index.h| 3 ++-
xen/arch/x86/pv/emul-priv-op.c | 4 ++--
xen/include/public/arch-x86/cpufeatureset.h | 2 +-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d7d31b5393..07f39d5e61 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -936,6 +936,9 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t
value,
if ( (value & EFER_FFXSE) && !p->extd.ffxsr )
return "FFXSE without feature";
+if ( (value & EFER_AIBRSE) && !p->extd.automatic_ibrs )
+return "AutoIBRS without feature";
+
return NULL;
}
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 73d0af2615..49cb334c61 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -178,7 +178,8 @@
#define EFER_AIBRSE(_AC(1, ULL) << 21) /* Automatic
IBRS Enable */
#define EFER_KNOWN_MASK \
-(EFER_SCE | EFER_LME | EFER_LMA | EFER_NXE | EFER_SVME | EFER_FFXSE)
+(EFER_SCE | EFER_LME | EFER_LMA | EFER_NXE | EFER_SVME | EFER_FFXSE | \
+ EFER_AIBRSE)
#define MSR_STAR0xc081 /* legacy mode SYSCALL
target */
#define MSR_LSTAR 0xc082 /* long mode SYSCALL
target */
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 8a4ef9c35e..142bc4818c 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -853,8 +853,8 @@ static uint64_t guest_efer(const struct domain *d)
{
uint64_t val;
-/* Hide unknown bits, and unconditionally hide SVME from guests. */
-val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
+/* Hide unknown bits, and unconditionally hide SVME and AIBRSE from
guests. */
+val = read_efer() & EFER_KNOWN_MASK & ~(EFER_SVME | EFER_AIBRSE);
/*
* Hide the 64-bit features from 32-bit guests. SCE has
* vendor-dependent behaviour.
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index e3952f62bc..42401e9452 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -287,7 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA
Instructions */
/* AMD-defined CPU features, CPUID level 0x8021.eax, word 11 */
XEN_CPUFEATURE(LFENCE_DISPATCH,11*32+ 2) /*A LFENCE always serializing */
XEN_CPUFEATURE(NSCB, 11*32+ 6) /*A Null Selector Clears Base
(and limit too) */
-XEN_CPUFEATURE(AUTOMATIC_IBRS, 11*32+ 8) /* HW can handle IBRS on its
own */
+XEN_CPUFEATURE(AUTOMATIC_IBRS, 11*32+ 8) /*S HW can handle IBRS on its
own */
XEN_CPUFEATURE(CPUID_USER_DIS, 11*32+17) /* CPUID disable for CPL > 0
software */
/* Intel-defined CPU features, CPUID level 0x0007:1.ebx, word 12 */
--
2.34.1
[PATCH 1/3] x86: Add bit definitions for Automatic IBRS
This is AMD's version of Intel's Enhanced IBRS. Exposed in CPUID
and toggled in EFER.
Signed-off-by: Alejandro Vallejo
---
tools/libs/light/libxl_cpuid.c | 1 +
tools/misc/xen-cpuid.c | 2 ++
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/include/asm/msr-index.h| 1 +
xen/include/public/arch-x86/cpufeatureset.h | 1 +
5 files changed, 6 insertions(+)
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index cca0f19d93..f5ce9f9795 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -317,6 +317,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
*cpuid, const char* str)
{"lfence+", 0x8021, NA, CPUID_REG_EAX, 2, 1},
{"nscb", 0x8021, NA, CPUID_REG_EAX, 6, 1},
+{"auto-ibrs",0x8021, NA, CPUID_REG_EAX, 8, 1},
{"cpuid-user-dis", 0x8021, NA, CPUID_REG_EAX, 17, 1},
{"maxhvleaf",0x4000, NA, CPUID_REG_EAX, 0, 8},
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 5d0c64a45f..e487885a5c 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -200,6 +200,8 @@ static const char *const str_e21a[32] =
[ 2] = "lfence+",
[ 6] = "nscb",
+[ 8] = "auto-ibrs",
+
/* 16 */[17] = "cpuid-user-dis",
};
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm/cpufeature.h
index 50235f098d..d5947a6826 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -161,6 +161,7 @@ static inline bool boot_cpu_has(unsigned int feat)
#define cpu_has_amd_ssbdboot_cpu_has(X86_FEATURE_AMD_SSBD)
#define cpu_has_virt_ssbd boot_cpu_has(X86_FEATURE_VIRT_SSBD)
#define cpu_has_ssb_no boot_cpu_has(X86_FEATURE_SSB_NO)
+#define cpu_has_auto_ibrs boot_cpu_has(X86_FEATURE_AUTOMATIC_IBRS)
/* CPUID level 0x0007:0.edx */
#define cpu_has_avx512_4vnniw boot_cpu_has(X86_FEATURE_AVX512_4VNNIW)
diff --git a/xen/arch/x86/include/asm/msr-index.h
b/xen/arch/x86/include/asm/msr-index.h
index 082fb2e0d9..73d0af2615 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -175,6 +175,7 @@
#define EFER_NXE (_AC(1, ULL) << 11) /* No Execute
Enable */
#define EFER_SVME (_AC(1, ULL) << 12) /* Secure
Virtual Machine Enable */
#define EFER_FFXSE (_AC(1, ULL) << 14) /* Fast
FXSAVE/FXRSTOR */
+#define EFER_AIBRSE(_AC(1, ULL) << 21) /* Automatic
IBRS Enable */
#define EFER_KNOWN_MASK \
(EFER_SCE | EFER_LME | EFER_LMA | EFER_NXE | EFER_SVME | EFER_FFXSE)
diff --git a/xen/include/public/arch-x86/cpufeatureset.h
b/xen/include/public/arch-x86/cpufeatureset.h
index 777041425e..e3952f62bc 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -287,6 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA, 10*32+23) /*A AVX-IFMA
Instructions */
/* AMD-defined CPU features, CPUID level 0x8021.eax, word 11 */
XEN_CPUFEATURE(LFENCE_DISPATCH,11*32+ 2) /*A LFENCE always serializing */
XEN_CPUFEATURE(NSCB, 11*32+ 6) /*A Null Selector Clears Base
(and limit too) */
+XEN_CPUFEATURE(AUTOMATIC_IBRS, 11*32+ 8) /* HW can handle IBRS on its
own */
XEN_CPUFEATURE(CPUID_USER_DIS, 11*32+17) /* CPUID disable for CPL > 0
software */
/* Intel-defined CPU features, CPUID level 0x0007:1.ebx, word 12 */
--
2.34.1
[PATCH 2/3] x86: Add support for AMD's Automatic IBRS
In cases where AutoIBRS is supported by the host:
* Prefer AutoIBRS to retpolines as BTI mitigation in heuristics
calculations.
* Always enable AutoIBRS if IBRS is chosen as a BTI mitigation.
* Avoid stuffing the RAS/RSB on VMEXIT if AutoIBRS is enabled.
* Delay setting AutoIBRS until after dom0 is set up, just like setting
SPEC_CTRL.
Signed-off-by: Alejandro Vallejo
---
xen/arch/x86/setup.c | 3 +++
xen/arch/x86/smpboot.c | 3 +++
xen/arch/x86/spec_ctrl.c | 52
3 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 74e3915a4d..09cfef2676 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -2036,6 +2036,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
barrier();
wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
info->last_spec_ctrl = default_xen_spec_ctrl;
+
+if ( cpu_has_auto_ibrs && (default_xen_spec_ctrl & SPEC_CTRL_IBRS) )
+write_efer(read_efer() | EFER_AIBRSE);
}
/* Copy the cpu info block, and move onto the BSP stack. */
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index cf9bb220f9..1d52c1dd0a 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -376,6 +376,9 @@ void start_secondary(void *unused)
{
wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
info->last_spec_ctrl = default_xen_spec_ctrl;
+
+if ( cpu_has_auto_ibrs && (default_xen_spec_ctrl & SPEC_CTRL_IBRS) )
+write_efer(read_efer() | EFER_AIBRSE);
}
update_mcu_opt_ctrl();
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 50d467f74c..c887fc3df9 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -390,7 +390,7 @@ custom_param("pv-l1tf", parse_pv_l1tf);
static void __init print_details(enum ind_thunk thunk)
{
-unsigned int _7d0 = 0, _7d2 = 0, e8b = 0, max = 0, tmp;
+unsigned int _7d0 = 0, _7d2 = 0, e8b = 0, e21a = 0, max = 0, tmp;
uint64_t caps = 0;
/* Collect diagnostics about available mitigations. */
@@ -399,7 +399,10 @@ static void __init print_details(enum ind_thunk thunk)
if ( max >= 2 )
cpuid_count(7, 2, &tmp, &tmp, &tmp, &_7d2);
if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
+{
cpuid(0x8008, &tmp, &e8b, &tmp, &tmp);
+cpuid(0x8021, &e21a, &tmp, &tmp, &tmp);
+}
if ( cpu_has_arch_caps )
rdmsrl(MSR_ARCH_CAPABILITIES, caps);
@@ -430,11 +433,12 @@ static void __init print_details(enum ind_thunk thunk)
(e8b & cpufeat_mask(X86_FEATURE_IBPB_RET)) ? " IBPB_RET"
: "");
/* Hardware features which need driving to mitigate issues. */
-printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s\n",
+printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
(e8b & cpufeat_mask(X86_FEATURE_IBPB)) ||
(_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBPB"
: "",
(e8b & cpufeat_mask(X86_FEATURE_IBRS)) ||
(_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS"
: "",
+ (e21a & cpufeat_mask(X86_FEATURE_AUTOMATIC_IBRS)) ? " AUTO_IBRS"
: "",
(e8b & cpufeat_mask(X86_FEATURE_AMD_STIBP)) ||
(_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP"
: "",
(e8b & cpufeat_mask(X86_FEATURE_AMD_SSBD)) ||
@@ -468,7 +472,9 @@ static void __init print_details(enum ind_thunk thunk)
thunk == THUNK_JMP ? "JMP" : "?",
(!boot_cpu_has(X86_FEATURE_IBRSB) &&
!boot_cpu_has(X86_FEATURE_IBRS)) ? "No" :
- (default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
+ (cpu_has_auto_ibrs &&
+(default_xen_spec_ctrl & SPEC_CTRL_IBRS)) ? "AUTO_IBRS+" :
+(default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
(!boot_cpu_has(X86_FEATURE_STIBP) &&
!boot_cpu_has(X86_FEATURE_AMD_STIBP))? "" :
(default_xen_spec_ctrl & SPEC_CTRL_STIBP) ? " STIBP+" : " STIBP-",
@@ -1150,15 +1156,20 @@ void __init init_speculation_mitigations(void)
}
else
{
-/*
- * Evaluate the safest Branch Target Injection mitigations to use.
- * First, begin with compiler-aided mitigations.
- */
-if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+/* Evaluate the safest BTI mitigations with lowest overhead */
+if ( cpu_has_auto_ibrs )
+{
+/*
+ * We'd rather use Automatic IBRS if present. It helps in order
+ * to avoid stuffing the RSB manually on every VMEXIT.
+ */
+ibrs = true;
+}
+else if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
{
/*
- * On all hardware, we'd like to use retpoline in preference to
- * IBRS, but onl
Re: [PATCH v2] xen/x86/pvh: handle ACPI RSDT table in PVH Dom0 build
On 26.05.2023 01:18, Stefano Stabellini wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -966,7 +966,16 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d,
> paddr_t madt_addr,
> rc = -EINVAL;
> goto out;
> }
> -xsdt_paddr = rsdp->xsdt_physical_address;
> +/*
> + * Note the header is the same for both RSDT and XSDT, so it's fine to
> + * copy the native RSDT header to the Xen crafted XSDT if no native
> + * XSDT is available.
> + */
> +if ( rsdp->revision > 1 && rsdp->xsdt_physical_address )
> +xsdt_paddr = rsdp->xsdt_physical_address;
> +else
> +xsdt_paddr = rsdp->rsdt_physical_address;
> +
> acpi_os_unmap_memory(rsdp, sizeof(*rsdp));
> table = acpi_os_map_memory(xsdt_paddr, sizeof(*table));
> if ( !table )
To continue context some:
{
printk("Unable to map XSDT\n");
rc = -EINVAL;
goto out;
}
xsdt->header = *table;
acpi_os_unmap_memory(table, sizeof(*table));
You're now pointing the guest's XSDT addr at a table that's really an
RSDT. After copying, I think you want to adjust the table signature
('R' -> 'X'). Luckily a revision of 1 is valid for both tables.
Jan
[PATCH v1] xentrace: adjust exit code for --help option
Invoking the --help option of any tool should not return with an error,
if that tool does have a documented and implemented help option.
Adjust the usage() function to exit with either error or success.
Handle the existing entry in the option table to call usage accordingly.
Adjust the getopt value for help. The char '?' is returned for unknown
options. Returning 'h' instead of '?' allows to handle --help.
Signed-off-by: Olaf Hering
---
tools/xentrace/xentrace.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
index 3548255123..be6226f088 100644
--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -807,7 +807,7 @@ static void monitor_tbufs(void)
const char *program_version = "xentrace v1.2";
const char *program_bug_address = "";
-static void usage(void)
+static void usage(int status)
{
#define USAGE_STR \
"Usage: xentrace [OPTION...] [output file]\n" \
@@ -854,7 +854,7 @@ static void usage(void)
printf(USAGE_STR);
printf("\nReport bugs to %s\n", program_bug_address);
-exit(EXIT_FAILURE);
+exit(status);
}
/* convert the argument string pointed to by arg to a long int representation,
@@ -873,7 +873,7 @@ long sargtol(const char *restrict arg, int base)
{
fprintf(stderr, "Invalid option argument: %s\n", arg);
fprintf(stderr, "Error: %s\n\n", strerror(errno));
-usage();
+usage(EXIT_FAILURE);
}
else if (endp == arg)
{
@@ -901,7 +901,7 @@ long sargtol(const char *restrict arg, int base)
invalid:
fprintf(stderr, "Invalid option argument: %s\n\n", arg);
-usage();
+usage(EXIT_FAILURE);
return 0; /* not actually reached */
}
@@ -917,10 +917,10 @@ static long argtol(const char *restrict arg, int base)
if (errno != 0) {
fprintf(stderr, "Invalid option argument: %s\n", arg);
fprintf(stderr, "Error: %s\n\n", strerror(errno));
-usage();
+usage(EXIT_FAILURE);
} else if (endp == arg || *endp != '\0') {
fprintf(stderr, "Invalid option argument: %s\n\n", arg);
-usage();
+usage(EXIT_FAILURE);
}
return val;
@@ -1090,7 +1090,7 @@ static void parse_args(int argc, char **argv)
{ "discard-buffers", no_argument, 0, 'D' },
{ "dont-disable-tracing", no_argument, 0, 'x' },
{ "start-disabled", no_argument, 0, 'X' },
-{ "help", no_argument, 0, '?' },
+{ "help", no_argument, 0, 'h' },
{ "version",no_argument, 0, 'V' },
{ 0, 0, 0, 0 }
};
@@ -1144,8 +1144,12 @@ static void parse_args(int argc, char **argv)
opts.memory_buffer = sargtol(optarg, 0);
break;
+case 'h':
+usage(EXIT_SUCCESS);
+break;
+
default:
-usage();
+usage(EXIT_FAILURE);
}
}
Re: [XEN PATCH] tools/xenstore: remove deprecated parameter from xenstore commands help
On 25.05.23 21:06, Cyril Rébert wrote:
Completing commit c65687e ("tools/xenstore: remove socket-only option from xenstore
client").
As the socket-only option (-s) has been removed from the Xenstore access
commands (xenstore-*),
also remove the parameter from the commands help (xenstore-* -h).
Suggested-by: Yann Dirson
Signed-off-by: Cyril Rébert
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [XEN v7 00/11] Add support for 32-bit physical address
Hi Ayan, On 18/05/2023 15:39, Ayan Kumar Halder wrote: Ayan Kumar Halder (11): xen/arm: domain_build: Track unallocated pages using the frame number xen/arm: Typecast the DT values into paddr_t xen/arm: Introduce a wrapper for dt_device_get_address() to handle paddr_t xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to SMMU_CBn_TTBR0 xen/arm: domain_build: Check if the address fits the range of physical address xen: dt: Replace u64 with uint64_t as the callback function parameters for dt_for_each_range() I have committed the patches up to here. xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64 xen/arm: Introduce choice to enable 64/32 bit physical addressing xen/arm: guest_walk: LPAE specific bits should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32" xen/arm: Restrict zeroeth_table_offset for ARM_64 xen/arm: p2m: Enable support for 32bit IPA for ARM_32 Cheers, -- Julien Grall
Re: [PATCH v2] xen/arm: un-break build with clang
Hi,
On 25/05/2023 20:15, Stewart Hildebrand wrote:
clang doesn't like extern with __attribute__((__used__)):
./arch/arm/include/asm/setup.h:171:8: error: 'used' attribute ignored
[-Werror,-Wignored-attributes]
extern DEFINE_BOOT_PAGE_TABLE(boot_pgtable);
^
./arch/arm/include/asm/lpae.h:273:29: note: expanded from macro
'DEFINE_BOOT_PAGE_TABLE'
lpae_t __aligned(PAGE_SIZE) __section(".data.page_aligned")
\
^
./include/xen/compiler.h:71:27: note: expanded from macro '__section'
#define __section(s) __used __attribute__((__section__(s)))
^
./include/xen/compiler.h:104:39: note: expanded from macro '__used'
#define __used __attribute__((__used__))
^
Simplify the declarations by getting rid of the macro (and thus the
__aligned/__section/__used attributes) in the header. No functional change
intended as the macro/attributes are present in the respective definitions in
xen/arch/arm/mm.c.
Fixes: 1c78d76b67e1 ("xen/arm64: mm: Introduce helpers to prepare/enable/disable the
identity mapping")
Signed-off-by: Stewart Hildebrand
Acked-by: Julien Grall
Cheers,
--
Julien Grall
[qemu-mainline test] 180958: regressions - FAIL
flight 180958 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180958/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
Re: [PATCH v1 2/3] xentrace: remove return value from monitor_tbufs
Fri, 26 May 2023 11:11:58 +0100 George Dunlap : > With that change: > Reviewed-by: George Dunlap > If that sounds OK to you I'll modify it on check-in. Yes, sounds good. Thank you. Olaf pgpKoa3nTL64Q.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH 2/4] x86/spec-ctrl: Synthesize missing RSBA/RRSBA bits
On 26/05/2023 12:06 pm, Andrew Cooper wrote: > --- > xen/arch/x86/include/asm/cpufeature.h | 1 + > xen/arch/x86/spec_ctrl.c | 50 +++ > 2 files changed, 44 insertions(+), 7 deletions(-) Sorry, please ignore this patch and look at the other patch 2, which has a commit message. ~Andrew
[PATCH 3/4] x86/cpu-policy: Rearrange guest_common_default_feature_adjustments()
This is prep work, split out to simply the diff on the following change.
* Split the INTEL check out of the IvyBridge RDRAND check, as the former will
be reused.
* Use asm/intel-family.h to remove a raw 0x3a model number.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/cpu-policy.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 74266d30b551..bdbc5660acd4 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -429,21 +430,24 @@ static void __init
guest_common_max_feature_adjustments(uint32_t *fs)
static void __init guest_common_default_feature_adjustments(uint32_t *fs)
{
-/*
- * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS
- * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to
- * compensate.
- *
- * Mitigate by hiding RDRAND from guests by default, unless explicitly
- * overridden on the Xen command line (cpuid=rdrand). Irrespective of the
- * default setting, guests can use RDRAND if explicitly enabled
- * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were
- * previously using RDRAND can migrate in.
- */
-if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
- boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a &&
- cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) )
-__clear_bit(X86_FEATURE_RDRAND, fs);
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+{
+/*
+ * IvyBridge client parts suffer from leakage of RDRAND data due to
SRBDS
+ * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to
+ * compensate.
+ *
+ * Mitigate by hiding RDRAND from guests by default, unless explicitly
+ * overridden on the Xen command line (cpuid=rdrand). Irrespective of
the
+ * default setting, guests can use RDRAND if explicitly enabled
+ * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were
+ * previously using RDRAND can migrate in.
+ */
+if ( boot_cpu_data.x86 == 6 &&
+ boot_cpu_data.x86_model == INTEL_FAM6_IVYBRIDGE &&
+ cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) )
+__clear_bit(X86_FEATURE_RDRAND, fs);
+}
/*
* On certain hardware, speculative or errata workarounds can result in
--
2.30.2
[PATCH 2/4] x86/spec-ctrl: Synthesize RSBA/RRSBA bits with older microcode
In order to level a VM safely for migration, the toolstack needs to know the
RSBA/RRSBA properties of the CPU, whether or not they happen to be enumerated.
Synthesize the bits when missing.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/spec_ctrl.c | 50 +++
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm/cpufeature.h
index 50235f098d70..08e3eedd1280 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -192,6 +192,7 @@ static inline bool boot_cpu_has(unsigned int feat)
#define cpu_has_tsx_ctrlboot_cpu_has(X86_FEATURE_TSX_CTRL)
#define cpu_has_taa_no boot_cpu_has(X86_FEATURE_TAA_NO)
#define cpu_has_fb_clearboot_cpu_has(X86_FEATURE_FB_CLEAR)
+#define cpu_has_rrsba boot_cpu_has(X86_FEATURE_RRSBA)
/* Synthesized. */
#define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0774d40627dd..2647784615cc 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -578,7 +578,10 @@ static bool __init check_smt_enabled(void)
return false;
}
-/* Calculate whether Retpoline is known-safe on this CPU. */
+/*
+ * Calculate whether Retpoline is known-safe on this CPU. Synthesize missing
+ * RSBA/RRSBA bits when running with old microcode.
+ */
static bool __init retpoline_calculations(void)
{
unsigned int ucode_rev = this_cpu(cpu_sig).rev;
@@ -592,13 +595,18 @@ static bool __init retpoline_calculations(void)
return false;
/*
- * RSBA may be set by a hypervisor to indicate that we may move to a
- * processor which isn't retpoline-safe.
- *
* Processors offering Enhanced IBRS are not guarenteed to be
* repoline-safe.
*/
-if ( cpu_has_rsba || cpu_has_eibrs )
+if ( cpu_has_eibrs )
+goto unsafe_maybe_fixup_rrsba;
+
+/*
+ * RSBA is explicitly enumerated in some cases, but may also be set by a
+ * hypervisor to indicate that we may move to a processor which isn't
+ * retpoline-safe.
+ */
+if ( cpu_has_rsba )
return false;
switch ( boot_cpu_data.x86_model )
@@ -648,6 +656,8 @@ static bool __init retpoline_calculations(void)
/*
* Skylake, Kabylake and Cannonlake processors are not retpoline-safe.
+ * Note: the eIBRS-capable steppings are filtered out earlier, so the
+ * remainder here are the ones which suffer only RSBA behaviour.
*/
case 0x4e: /* Skylake M */
case 0x55: /* Skylake X */
@@ -656,7 +666,7 @@ static bool __init retpoline_calculations(void)
case 0x67: /* Cannonlake? */
case 0x8e: /* Kabylake M */
case 0x9e: /* Kabylake D */
-return false;
+goto unsafe_maybe_fixup_rsba;
/*
* Atom processors before Goldmont Plus/Gemini Lake are retpoline-safe.
@@ -687,6 +697,32 @@ static bool __init retpoline_calculations(void)
if ( safe )
return true;
+/*
+ * The meaning of the RSBA and RRSBA bits have evolved over time. The
+ * agreed upon meaning at the time of writing (May 2023) is thus:
+ *
+ * - RSBA (RSB Alterantive) means that an RSB may fall back to an
+ * alternative predictor on underflow. Skylake uarch and later all have
+ * this property. Broadwell too, when running microcode versions prior
+ * to Jan 2018.
+ *
+ * - All eIBRS-capable processors suffer RSBA, but eIBRS also introduces
+ * tagging of predictions with the mode in which they were learned. So
+ * when eIBRS is active, RSBA becomes RRSBA (Restricted RSBA).
+ *
+ * Some parts (Broadwell) are not expected to ever enumerate this
+ * behaviour directly. Other parts have differing enumeration with
+ * microcode version. Fix up Xen's idea, so we can advertise them safely
+ * to guests, and so toolstacks can level a VM safelty for migration.
+ */
+ unsafe_maybe_fixup_rrsba:
+if ( !cpu_has_rrsba )
+setup_force_cpu_cap(X86_FEATURE_RRSBA);
+
+ unsafe_maybe_fixup_rsba:
+if ( !cpu_has_rsba )
+setup_force_cpu_cap(X86_FEATURE_RSBA);
+
return false;
}
@@ -1146,7 +1182,7 @@ void __init init_speculation_mitigations(void)
thunk = THUNK_JMP;
}
-/* Determine if retpoline is safe on this CPU. */
+/* Determine if retpoline is safe on this CPU. Fix up RSBA/RRSBA
enumerations. */
retpoline_safe = retpoline_calculations();
/*
--
2.30.2
[PATCH 1/4] x86/spec-ctrl: Rename retpoline_safe() to retpoline_calculations()
This is prep work, split out to simply the diff on the following change.
* Rename to retpoline_calculations(), and call unconditionally. It is
shortly going to synthesize missing enumerations required for guest safety.
* For Broadwell, store the ucode revision calculation in a variable and fall
out of the bottom of the switch statement.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/spec_ctrl.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 50d467f74cf8..0774d40627dd 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -579,9 +579,10 @@ static bool __init check_smt_enabled(void)
}
/* Calculate whether Retpoline is known-safe on this CPU. */
-static bool __init retpoline_safe(void)
+static bool __init retpoline_calculations(void)
{
unsigned int ucode_rev = this_cpu(cpu_sig).rev;
+bool safe = false;
if ( boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
return true;
@@ -626,18 +627,18 @@ static bool __init retpoline_safe(void)
* versions.
*/
case 0x3d: /* Broadwell */
-return ucode_rev >= 0x2a;
+safe = ucode_rev >= 0x2a; break;
case 0x47: /* Broadwell H */
-return ucode_rev >= 0x1d;
+safe = ucode_rev >= 0x1d; break;
case 0x4f: /* Broadwell EP/EX */
-return ucode_rev >= 0xb21;
+safe = ucode_rev >= 0xb21; break;
case 0x56: /* Broadwell D */
switch ( boot_cpu_data.x86_mask )
{
-case 2: return ucode_rev >= 0x15;
-case 3: return ucode_rev >= 0x712;
-case 4: return ucode_rev >= 0xf11;
-case 5: return ucode_rev >= 0xe09;
+case 2: safe = ucode_rev >= 0x15; break;
+case 3: safe = ucode_rev >= 0x712; break;
+case 4: safe = ucode_rev >= 0xf11; break;
+case 5: safe = ucode_rev >= 0xe09; break;
default:
printk("Unrecognised CPU stepping %#x - assuming not reptpoline
safe\n",
boot_cpu_data.x86_mask);
@@ -681,6 +682,12 @@ static bool __init retpoline_safe(void)
boot_cpu_data.x86_model);
return false;
}
+
+/* Only Broadwell gets here. */
+if ( safe )
+return true;
+
+return false;
}
/*
@@ -1113,7 +1120,7 @@ void __init init_speculation_mitigations(void)
{
enum ind_thunk thunk = THUNK_DEFAULT;
bool has_spec_ctrl, ibrs = false, hw_smt_enabled;
-bool cpu_has_bug_taa;
+bool cpu_has_bug_taa, retpoline_safe;
hw_smt_enabled = check_smt_enabled();
@@ -1139,6 +1146,9 @@ void __init init_speculation_mitigations(void)
thunk = THUNK_JMP;
}
+/* Determine if retpoline is safe on this CPU. */
+retpoline_safe = retpoline_calculations();
+
/*
* Has the user specified any custom BTI mitigations? If so, follow their
* instructions exactly and disable all heuristics.
@@ -1160,7 +1170,7 @@ void __init init_speculation_mitigations(void)
* On all hardware, we'd like to use retpoline in preference to
* IBRS, but only if it is safe on this hardware.
*/
-if ( retpoline_safe() )
+if ( retpoline_safe )
thunk = THUNK_RETPOLINE;
else if ( has_spec_ctrl )
ibrs = true;
--
2.30.2
[PATCH 0/4] x86: RSBA and RRSBA handling
This series deals with the hanlding of the RSBA and RRSBA bits across all
parts and all mistakes encountered in various microcode versions.
With it in place, here are some examples from various generations of Intel
hardware:
BDX Raw
BDX Host
BDX HVM Max rsba
KBL Raw rsba misc-pkg-ctrl energy-ctrl
KBL Host rsba misc-pkg-ctrl energy-ctrl
KBL HVM Max rsba
SKX Raw rsba misc-pkg-ctrl energy-ctrl
SKX Host rsba misc-pkg-ctrl energy-ctrl
SKX HVM Max rsba
CFL Raw rdcl-no eibrs skip-l1dfl mds-no tsx-ctrl misc-pkg-ctrl
energy-ctrl fb-clear
CFL Host rdcl-no eibrs rsba skip-l1dfl mds-no tsx-ctrl misc-pkg-ctrl
energy-ctrl fb-clear rrsba
CFL HVM Max rdcl-no eibrs rsba mds-no fb-clear rrsba
CLX Raw rdcl-no eibrs skip-l1dfl mds-no tsx-ctrl misc-pkg-ctrl
energy-ctrl sbdr-ssdp-no psdp-no fb-clear rrsba
CLX Host rdcl-no eibrs rsba skip-l1dfl mds-no tsx-ctrl misc-pkg-ctrl
energy-ctrl sbdr-ssdp-no psdp-no fb-clear rrsba
CLX HVM Max rdcl-no eibrs rsba mds-no sbdr-ssdp-no psdp-no fb-clear rrsba
SPR Raw rdcl-no eibrs skip-l1dfl mds-no if-pschange-mc-no tsx-ctrl
taa-no misc-pkg-ctrl energy-ctrl
SPR Host rdcl-no eibrs rsba skip-l1dfl mds-no if-pschange-mc-no tsx-ctrl
taa-no misc-pkg-ctrl energy-ctrl rrsba
SPR HVM Max rdcl-no eibrs rsba mds-no if-pschange-mc-no taa-no rrsba
Of note:
* The SPR CPU is pre-release and didn't get the MMIO ucode in the end
(sbdr-ssdp-no psdp-no fb-clear).
* SKX/KBL enumerate RSBA following the energy filtering microcode. Prior to
that, they don't enumerate MSR_ARCH_CAPS at all.
* CFL and SPR fails to enumerate both RSBA and RRSBA. CLX fails to enumerate
RSBA. These should be addressed in due course.
Andrew Cooper (4):
x86/spec-ctrl: Rename retpoline_safe() to retpoline_calculations()
x86/spec-ctrl: Synthesize missing RSBA/RRSBA bits
x86/cpu-policy: Rearrange guest_common_default_feature_adjustments()
x86/cpu-policy: Derive {,R}RSBA for guest policies
xen/arch/x86/cpu-policy.c | 59 ++--
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/spec_ctrl.c | 78 +--
xen/tools/gen-cpuid.py| 5 +-
4 files changed, 111 insertions(+), 32 deletions(-)
--
2.30.2
[PATCH 4/4] x86/cpu-policy: Derive {,R}RSBA for guest policies
The RSBA bit, "RSB Alternative", means that the RSB may use alternative
predictors when empty. From a practical point of view, this mean "Retpoline
not safe".
Enhanced IBRS (officially IBRS_ALL in Intel's docs, previously IBRS_ATT) is a
statement that IBRS is implemented in hardware (as opposed to the form
retrofitted to existing CPUs in microcode).
The RRSBA bit, "Restricted-RSBA", is a combination of RSBA, and the eIBRS
property that predictions are tagged with the mode in which they were learnt.
Therefore, it means "when eIBRS is active, the RSB may fall back to
alternative predictors but restricted to the current prediction mode". As
such, it's stronger statement than RSBA, but still means "Retpoline not safe".
Add feature dependencies for EIBRS and RRSBA. While technically they're not
linked, absolutely nothing good can of letting the guest see RRSBA without
EIBRS. Furthermore, we use this dependency to simplify the max/default
derivation logic.
The max policies gets RSBA and RRSBA unconditionally set (with the EIBRS
dependency maybe hiding RRSBA). We can run any VM, even if it has been told
"somewhere else, Retpoline isn't safe".
The default policies inherit the host settings, because the guest wants to run
with as few (anti)features as it can safely get away with.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/cpu-policy.c | 25 +
xen/tools/gen-cpuid.py| 5 -
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index bdbc5660acd4..eb1ecb75f593 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -423,8 +423,14 @@ static void __init
guest_common_max_feature_adjustments(uint32_t *fs)
* Retpoline not safe)", so these need to be visible to a guest in all
* cases, even when it's only some other server in the pool which
* suffers the identified behaviour.
+ *
+ * We can always run any VM which has previously (or will
+ * subsequently) run on hardware where Retpoline is not safe. Note:
+ * The dependency logic may hide RRSBA for other reasons.
*/
__set_bit(X86_FEATURE_ARCH_CAPS, fs);
+__set_bit(X86_FEATURE_RSBA, fs);
+__set_bit(X86_FEATURE_RRSBA, fs);
}
}
@@ -432,6 +438,25 @@ static void __init
guest_common_default_feature_adjustments(uint32_t *fs)
{
if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
{
+/*
+ * The {,R}RSBA bits under virt mean "you might migrate somewhere
+ * where retpoline is not safe". In particular, a VM's settings may
+ * not be applicable to the current host.
+ *
+ * Discard the settings inherited from the max policy, and and feed in
+ * the host values. The ideal case for a VM is for neither of these
+ * bits to be set, but toolstacks must accumuate them across anywhere
+ * the VM might migrate to, in case any possible destination happens
+ * to be unsafe.
+ *
+ * Note: The dependency logic might hide RRSBA for other reasons.
+ */
+fs[FEATURESET_m10Al] &= ~(cpufeat_mask(X86_FEATURE_RSBA) |
+ cpufeat_mask(X86_FEATURE_RRSBA));
+fs[FEATURESET_m10Al] |=
+host_cpu_policy.arch_caps.lo & (cpufeat_mask(X86_FEATURE_RSBA) |
+cpufeat_mask(X86_FEATURE_RRSBA));
+
/*
* IvyBridge client parts suffer from leakage of RDRAND data due to
SRBDS
* (XSA-320 / CVE-2020-0543), and won't be receiving microcode to
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index f28ff708a2fc..22294a26adc0 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -318,7 +318,7 @@ def crunch_numbers(state):
# IBRSB/IBRS, and we pass this MSR directly to guests. Treating them
# as dependent features simplifies Xen's logic, and prevents the guest
# from seeing implausible configurations.
-IBRSB: [STIBP, SSBD, INTEL_PSFD],
+IBRSB: [STIBP, SSBD, INTEL_PSFD, EIBRS],
IBRS: [AMD_STIBP, AMD_SSBD, PSFD,
IBRS_ALWAYS, IBRS_FAST, IBRS_SAME_MODE],
AMD_STIBP: [STIBP_ALWAYS],
@@ -328,6 +328,9 @@ def crunch_numbers(state):
# The ARCH_CAPS CPUID bit enumerates the availability of the whole
register.
ARCH_CAPS: list(range(RDCL_NO, RDCL_NO + 64)),
+
+# The behaviour described by RRSBA depend on eIBRS being active.
+EIBRS: [RRSBA],
}
deep_features = tuple(sorted(deps.keys()))
--
2.30.2
[PATCH 2/4] x86/spec-ctrl: Synthesize missing RSBA/RRSBA bits
---
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/spec_ctrl.c | 50 +++
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm/cpufeature.h
index 50235f098d70..08e3eedd1280 100644
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -192,6 +192,7 @@ static inline bool boot_cpu_has(unsigned int feat)
#define cpu_has_tsx_ctrlboot_cpu_has(X86_FEATURE_TSX_CTRL)
#define cpu_has_taa_no boot_cpu_has(X86_FEATURE_TAA_NO)
#define cpu_has_fb_clearboot_cpu_has(X86_FEATURE_FB_CLEAR)
+#define cpu_has_rrsba boot_cpu_has(X86_FEATURE_RRSBA)
/* Synthesized. */
#define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0774d40627dd..daf77d77e139 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -578,7 +578,10 @@ static bool __init check_smt_enabled(void)
return false;
}
-/* Calculate whether Retpoline is known-safe on this CPU. */
+/*
+ * Calculate whether Retpoline is known-safe on this CPU. Fixes up missing
+ * RSBA/RRSBA enumeration from older microcode versions.
+ */
static bool __init retpoline_calculations(void)
{
unsigned int ucode_rev = this_cpu(cpu_sig).rev;
@@ -592,13 +595,18 @@ static bool __init retpoline_calculations(void)
return false;
/*
- * RSBA may be set by a hypervisor to indicate that we may move to a
- * processor which isn't retpoline-safe.
- *
* Processors offering Enhanced IBRS are not guarenteed to be
* repoline-safe.
*/
-if ( cpu_has_rsba || cpu_has_eibrs )
+if ( cpu_has_eibrs )
+goto unsafe_maybe_fixup_rrsba;
+
+/*
+ * RSBA is explicitly enumerated in some cases, but may also be set by a
+ * hypervisor to indicate that we may move to a processor which isn't
+ * retpoline-safe.
+ */
+if ( cpu_has_rsba )
return false;
switch ( boot_cpu_data.x86_model )
@@ -648,6 +656,8 @@ static bool __init retpoline_calculations(void)
/*
* Skylake, Kabylake and Cannonlake processors are not retpoline-safe.
+ * Note: the eIBRS-capable steppings are filtered out earlier, so the
+ * remainder here are the ones which suffer only RSBA behaviour.
*/
case 0x4e: /* Skylake M */
case 0x55: /* Skylake X */
@@ -656,7 +666,7 @@ static bool __init retpoline_calculations(void)
case 0x67: /* Cannonlake? */
case 0x8e: /* Kabylake M */
case 0x9e: /* Kabylake D */
-return false;
+goto unsafe_maybe_fixup_rsba;
/*
* Atom processors before Goldmont Plus/Gemini Lake are retpoline-safe.
@@ -687,6 +697,32 @@ static bool __init retpoline_calculations(void)
if ( safe )
return true;
+/*
+ * The meaning of the RSBA and RRSBA bits have evolved over time. The
+ * agreed upon meaning at the time of writing (May 2023) is thus:
+ *
+ * - RSBA (RSB Alterantive) means that an RSB may fall back to an
+ * alternative predictor on underflow. Skylake uarch and later all have
+ * this property. Broadwell too, when running microcode versions prior
+ * to Jan 2018.
+ *
+ * - All eIBRS-capable processors suffer RSBA, but eIBRS also introduces
+ * tagging of predictions with the mode in which they were learned. So
+ * when eIBRS is active, RSBA becomes RRSBA (Restricted RSBA).
+ *
+ * Some parts (Broadwell) are not expected to ever enumerate this
+ * behaviour directly. Other parts have differing enumeration with
+ * microcode version. Fix up Xen's idea, so we can advertise them safely
+ * to guests, and so toolstacks can level a VM safelty for migration.
+ */
+ unsafe_maybe_fixup_rrsba:
+if ( !cpu_has_rrsba )
+setup_force_cpu_cap(X86_FEATURE_RRSBA);
+
+ unsafe_maybe_fixup_rsba:
+if ( !cpu_has_rsba )
+setup_force_cpu_cap(X86_FEATURE_RSBA);
+
return false;
}
@@ -1146,7 +1182,7 @@ void __init init_speculation_mitigations(void)
thunk = THUNK_JMP;
}
-/* Determine if retpoline is safe on this CPU. */
+/* Determine if retpoline is safe on this CPU. Fix up RSBA/RRSBA
enumerations. */
retpoline_safe = retpoline_calculations();
/*
--
2.30.2
[xen-unstable-smoke test] 180956: tolerable all pass - PUSHED
flight 180956 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/180956/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass version targeted for testing: xen 40cd186bfd15655b7d9d3ee149292c718c208917 baseline version: xen 354be8936d97d4f2cb8cc004bb0296826d89bd8d Last test of basis 180943 2023-05-25 13:01:48 Z0 days Testing same since 180956 2023-05-26 08:01:52 Z0 days1 attempts People who touched revisions under test: Alistair Francis Andrew Cooper Anthony PERARD Jan Beulich Luca Fancellu Olaf Hering Roger Pau Monné Yann Dirson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 354be8936d..40cd186bfd 40cd186bfd15655b7d9d3ee149292c718c208917 -> smoke
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Wed, May 24 2023 at 23:48, Kirill A. Shutemov wrote:
> On Mon, May 08, 2023 at 09:44:17PM +0200, Thomas Gleixner wrote:
>> #ifdef CONFIG_SMP
>> -/**
>> - * apic_id_is_primary_thread - Check whether APIC ID belongs to a primary
>> thread
>> - * @apicid: APIC ID to check
>> - */
>> -bool apic_id_is_primary_thread(unsigned int apicid)
>> +static void cpu_mark_primary_thread(unsigned int cpu, unsigned int apicid)
>> {
>> -u32 mask;
>> -
>> -if (smp_num_siblings == 1)
>> -return true;
>> /* Isolate the SMT bit(s) in the APICID and check for 0 */
>> -mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
>> -return !(apicid & mask);
>> +u32 mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
>> +
>> +if (smp_num_siblings == 1 || !(apicid & mask))
>> +cpumask_set_cpu(cpu, &__cpu_primary_thread_mask);
>> }
>> +#else
>> +static inline void cpu_mark_primary_thread(unsigned int cpu, unsigned int
>> apicid) { }
>> #endif
>>
>> /*
>
> This patch causes boot regression on TDX guest. The guest crashes on SMP
> bring up.
I rather call it a security feature: It makes TDX unbreakably secure.
> The change makes use of smp_num_siblings earlier than before: the mask get
> constructed in acpi_boot_init() codepath. Later on smp_num_siblings gets
> updated in detect_ht().
>
> In my setup with 16 vCPUs, smp_num_siblings is 16 before detect_ht() and
> set to 1 in detect_ht().
early_init_intel(c)
if (detect_extended_topology_early(c) < 0)
detect_ht_early(c);
acpi_boot_init()
identify_boot_cpu(c)
detect_ht(c);
Aaargh. That whole CPU identification code is a complete horrorshow.
I'll have a look
Re: [PATCH v1 2/3] xentrace: remove return value from monitor_tbufs
On Fri, May 26, 2023 at 8:29 AM Olaf Hering wrote: > The function always returns zero. > I think a better argument (which I propose to replace the content of the commit message) would be something like this: --- The program is structured so that fatal errors cause exit() to be called directly, rather than being passed up the stack; returning a value here may mislead people into believing otherwise. --- With that change: Reviewed-by: George Dunlap If that sounds OK to you I'll modify it on check-in. -George
[linux-linus test] 180950: regressions - FAIL
flight 180950 linux-linus real [real] flight 180957 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180950/ http://logs.test-lab.xenproject.org/osstest/logs/180957/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278 test-amd64-amd64-libvirt-qcow2 19 guest-start/debian.repeat fail REGR. vs. 180278 Tests which are failing intermittently (not blocking): test-amd64-amd64-freebsd12-amd64 18 guest-saverestore.2 fail pass in 180957-retest test-amd64-coresched-amd64-xl 13 debian-fixup fail pass in 180957-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-examine 8 reboot fail like 180278 test-armhf-armhf-xl-arndale 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-qcow2 8 xen-bootfail like 180278 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180278 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-vhd 8 xen-boot fail like 180278 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180278 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180278 test-armhf-armhf-xl-multivcpu 8 xen-boot fail like 180278 test-armhf-armhf-libvirt-raw 8 xen-boot fail like 180278 test-armhf-armhf-libvirt 8 xen-boot fail like 180278 test-armhf-armhf-xl-credit2 8 xen-boot fail like 180278 test-armhf-armhf-xl-rtds 8 xen-boot fail like 180278 test-armhf-armhf-xl 8 xen-boot fail like 180278 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180278 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linux9db898594c541444e19b2d20fb8a06262cf8fcd9 baseline version: linux6c538e1adbfc696ac4747fb10d63e704344f763d Last test of basis 180278 2023-04-16 19:41:46 Z 39 days Failing since180281 2023-04-17 06:24:36 Z 39 days 72 attempts Testing same since 180950 2023-05-25 22:12:20 Z0 days1 attempts 2518 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass
Re: [PATCH v1 1/3] xentrace: allow xentrace to write to stdout
On Fri, May 26, 2023 at 8:29 AM Olaf Hering wrote: > The output file is optional. In case it is missing, xentrace is supposed > to write to stdout - unless it is a tty, which is checked prior using it. > > Signed-off-by: Olaf Hering > Acked-by: George Dunlap
Re: [PATCH v1 3/3] xentrace: close output file in the function which opened it
On Fri, May 26, 2023 at 8:29 AM Olaf Hering wrote: > Signed-off-by: Olaf Hering > Wow, this file is ugly. Reviewed-by: George Dunlap
[qemu-mainline test] 180954: regressions - FAIL
flight 180954 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/180954/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 180691 build-amd64-xsm 6 xen-buildfail REGR. vs. 180691 build-i386-xsm6 xen-buildfail REGR. vs. 180691 build-i3866 xen-buildfail REGR. vs. 180691 build-arm64 6 xen-buildfail REGR. vs. 180691 build-arm64-xsm 6 xen-buildfail REGR. vs. 180691 build-armhf 6 xen-buildfail REGR. vs. 180691 Tests which did not succeed, but are not blocking: 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-ovmf-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-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-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 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-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 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 build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-arm64-libvirt 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 build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 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-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 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-libvirt-qemuu-de
[PATCH v1 3/3] xentrace: close output file in the function which opened it
Signed-off-by: Olaf Hering --- tools/xentrace/xentrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c index a073cab26d..3548255123 100644 --- a/tools/xentrace/xentrace.c +++ b/tools/xentrace/xentrace.c @@ -794,7 +794,6 @@ static void monitor_tbufs(void) free(meta); free(data); /* don't need to munmap - cleanup is automatic */ -close(outfd); } @@ -1225,6 +1224,7 @@ int main(int argc, char **argv) monitor_tbufs(); +close(outfd); return 0; }
[PATCH v1 1/3] xentrace: allow xentrace to write to stdout
The output file is optional. In case it is missing, xentrace is supposed to write to stdout - unless it is a tty, which is checked prior using it. Signed-off-by: Olaf Hering --- tools/xentrace/xentrace.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c index 864e30d50c..b81abe8a51 100644 --- a/tools/xentrace/xentrace.c +++ b/tools/xentrace/xentrace.c @@ -1152,11 +1152,9 @@ static void parse_args(int argc, char **argv) } } -/* get outfile (required last argument) */ -if (optind != (argc-1)) -usage(); - -opts.outfile = argv[optind]; +/* get outfile (optional last argument) */ +if (argc > optind) +opts.outfile = argv[optind]; } /* *BSD has no O_LARGEFILE */
[PATCH v1 0/3] xentrace changes
Olaf Hering (3): xentrace: allow xentrace to write to stdout xentrace: remove return value from monitor_tbufs xentrace: close output file in the function which opened it tools/xentrace/xentrace.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-)
[PATCH] x86/vPIC: register only one ELCR handler instance
There's no point consuming two port-I/O slots. Even less so considering
that some real hardware permits both ports to be accessed in one go,
emulating of which requires there to be only a single instance.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vpic.c
+++ b/xen/arch/x86/hvm/vpic.c
@@ -377,25 +377,34 @@ static int cf_check vpic_intercept_elcr_
int dir, unsigned int port, unsigned int bytes, uint32_t *val)
{
struct hvm_hw_vpic *vpic;
-uint32_t data;
+unsigned int data, shift = 0;
-BUG_ON(bytes != 1);
+BUG_ON(bytes > 2 - (port & 1));
vpic = ¤t->domain->arch.hvm.vpic[port & 1];
-if ( dir == IOREQ_WRITE )
-{
-/* Some IRs are always edge trig. Slave IR is always level trig. */
-data = *val & vpic_elcr_mask(vpic);
-if ( vpic->is_master )
-data |= 1 << 2;
-vpic->elcr = data;
-}
-else
-{
-/* Reader should not see hardcoded level-triggered slave IR. */
-*val = vpic->elcr & vpic_elcr_mask(vpic);
-}
+do {
+if ( dir == IOREQ_WRITE )
+{
+/* Some IRs are always edge trig. Slave IR is always level trig. */
+data = (*val >> shift) & vpic_elcr_mask(vpic);
+if ( vpic->is_master )
+data |= 1 << 2;
+vpic->elcr = data;
+}
+else
+{
+/* Reader should not see hardcoded level-triggered slave IR. */
+data = vpic->elcr & vpic_elcr_mask(vpic);
+if ( !shift )
+*val = data;
+else
+*val |= data << shift;
+}
+
+++vpic;
+shift += 8;
+} while ( --bytes );
return X86EMUL_OKAY;
}
@@ -470,8 +479,7 @@ void vpic_init(struct domain *d)
register_portio_handler(d, 0x20, 2, vpic_intercept_pic_io);
register_portio_handler(d, 0xa0, 2, vpic_intercept_pic_io);
-register_portio_handler(d, 0x4d0, 1, vpic_intercept_elcr_io);
-register_portio_handler(d, 0x4d1, 1, vpic_intercept_elcr_io);
+register_portio_handler(d, 0x4d0, 2, vpic_intercept_elcr_io);
}
void vpic_irq_positive_edge(struct domain *d, int irq)
[PATCH v1 2/3] xentrace: remove return value from monitor_tbufs
The function always returns zero.
Signed-off-by: Olaf Hering
---
tools/xentrace/xentrace.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
index b81abe8a51..a073cab26d 100644
--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -668,7 +668,7 @@ static void wait_for_event_or_timeout(unsigned long
milliseconds)
* monitor_tbufs - monitor the contents of tbufs and output to a file
* @logfile: the FILE * representing the file to log to
*/
-static int monitor_tbufs(void)
+static void monitor_tbufs(void)
{
int i;
@@ -795,8 +795,6 @@ static int monitor_tbufs(void)
free(data);
/* don't need to munmap - cleanup is automatic */
close(outfd);
-
-return 0;
}
@@ -1164,7 +1162,6 @@ static void parse_args(int argc, char **argv)
int main(int argc, char **argv)
{
-int ret;
struct sigaction act;
opts.outfile = 0;
@@ -1226,9 +1223,9 @@ int main(int argc, char **argv)
sigaction(SIGINT, &act, NULL);
sigaction(SIGALRM, &act, NULL);
-ret = monitor_tbufs();
+monitor_tbufs();
-return ret;
+return 0;
}
/*
Re: [RFC] Xen crashes on ASSERT on suspend/resume, suggested fix
On 25.05.2023 21:54, Stefano Stabellini wrote: > On Thu, 25 May 2023, Jan Beulich wrote: >> On 25.05.2023 01:51, Stefano Stabellini wrote: >>> xen/irq: fix races between send_cleanup_vector and _clear_irq_vector >> >> This title is, I'm afraid, already misleading. No such race can occur >> afaict, as both callers of _clear_irq_vector() acquire the IRQ >> descriptor lock first, and irq_complete_move() (the sole caller of >> send_cleanup_vector()) is only ever invoked as or by an ->ack() >> hook, which in turn is only invoked with, again, the descriptor lock >> held. > > Yes I see that you are right about the locking, and thank you for taking > the time to look into it. > > One last question: could it be that a second interrupt arrives while > ->ack() is being handled? do_IRQ() is running with interrupts disabled? It is, at least as far as the invocation of ->ack() is concerned. Else the locking scheme would be broken. You may not that around ->handler() invocation we enable interrupts. Jan
