[linux-5.4 test] 160116: tolerable FAIL - PUSHED
flight 160116 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/160116/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 159939 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159939 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 159939 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 159939 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 159939 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 159939 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 159939 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 159939 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 159939 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 159939 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 159939 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-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-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-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-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 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-amd64-amd64-libvirt-vhd 14 migrate-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-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linux0437de26e28dd844f51fde7a749a82cb2d3694ad baseline version: linuxce615a08404c821bcb3c6f358b8f34307bfe30c9 Last test of basis 159939 2021-03-11 13:40:17 Z6 days Testing same since 160116 2021-03-17 16:11:22 Z0 days1 attempts People who touched revisions under test: Abhishek Sahu Adrian Hunter Al Viro Alain Volmat Aleksandr Miloserdov Andreas Kempe Andreas Larsson Andrew Morton Andrey Konovalov Andy Shevchenko Anna Schumaker Anna-Maria Behnsen Anshuman Khandual Antony Antony Ard Biesheuvel Arnaldo Carvalho de Mel
[ovmf test] 160117: all pass - PUSHED
flight 160117 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/160117/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 030ba3097a6e7d08b99f8a9d19a322f61409c1f6 baseline version: ovmf e4ff3773b711527ff46759759f34ea1cb9ff2a45 Last test of basis 160114 2021-03-17 11:39:41 Z0 days Testing same since 160117 2021-03-17 20:41:58 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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/osstest/ovmf.git e4ff3773b7..030ba3097a 030ba3097a6e7d08b99f8a9d19a322f61409c1f6 -> xen-tested-master
[linux-linus test] 160115: regressions - FAIL
flight 160115 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/160115/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 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-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-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-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check
[qemu-mainline test] 160113: regressions - FAIL
flight 160113 qemu-mainline real [real] flight 160118 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/160113/ http://logs.test-lab.xenproject.org/osstest/logs/160118/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 160118-retest Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-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-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-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-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 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 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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 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 version targeted for testing: qemuu5d1428d6c43942cfb40a909e4c30a5cbb81bda8f baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 209 days Failing since152659 2020-08-21 14:07:39 Z 208 days 404 attempts Testing s
Re: [PATCH] xen/evtchn: replace if (cond) BUG() with BUG_ON()
On 3/16/21 11:04 PM, Jiapeng Chong wrote: > Fix the following coccicheck warnings: > > ./drivers/xen/evtchn.c:412:2-5: WARNING: Use BUG_ON instead of if > condition followed by BUG. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/xen/evtchn.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c > index c99415a..b1c59bc 100644 > --- a/drivers/xen/evtchn.c > +++ b/drivers/xen/evtchn.c > @@ -408,8 +408,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, > evtchn_port_t port) > err: > /* bind failed, should close the port now */ > close.port = port; > - if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0) > - BUG(); > + BUG_ON(HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0); Is it actually worth doing a BUG() here at all? Seems to me WARN_ON_ONCE() should be sufficient. -boris > del_evtchn(u, evtchn); > return rc; > }
[ovmf test] 160114: all pass - PUSHED
flight 160114 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/160114/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e4ff3773b711527ff46759759f34ea1cb9ff2a45 baseline version: ovmf 2e51b27fed31eb7b2a2cb4245806c8c7859207f7 Last test of basis 160106 2021-03-17 04:11:49 Z0 days Testing same since 160114 2021-03-17 11:39:41 Z0 days1 attempts People who touched revisions under test: Jason Lou Lou, Yun jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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/osstest/ovmf.git 2e51b27fed..e4ff3773b7 e4ff3773b711527ff46759759f34ea1cb9ff2a45 -> xen-tested-master
[xen-unstable test] 160109: tolerable FAIL
flight 160109 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/160109/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 160101 pass in 160109 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 160101 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 160101 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 160101 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 160101 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 160101 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 160101 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 160101 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 160101 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 160101 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 160101 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 160101 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 160101 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-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-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-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-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-xsm 15 migrate-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-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail 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-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: xen 21657ad4f01a634beac570c64c0691e51b9cf366 baseline version: xen 21657ad4f01a634beac570c64c0691e51b9cf366 Last test of basis 160109 2021-03-17 06:59:53 Z0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 06:57:42PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > > - if (!io_tlb_alloc_size)
> > > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > > - __func__, alloc_size, PAGE_SIZE);
> > > >
> > > > Shouldn't this be converted to:
> > > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > if (...)
> > > >
> > > > Seems that it got lost in the search and replace?
> > >
> > > Yes, I messed that up during the rebase. That being said it magically
> > > gets fixed in the next patch..
> >
> > Yes. However if someone does a bisection they are going to be mighty unhappy
> > with you.
>
> Sure, I was planning on fixing it anyway. Just waiting for feedback
> on the rest of the patches before doing a respin.
I put the patches up-to this one on :
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb
devel/for-linus-5.13
Would you be OK rebasing on top of that and sending the patches?
Juergen, would you be OK testing that branch on your Xen setup?
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > - if (!io_tlb_alloc_size)
> > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > - __func__, alloc_size, PAGE_SIZE);
> > >
> > > Shouldn't this be converted to:
> > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > if (...)
> > >
> > > Seems that it got lost in the search and replace?
> >
> > Yes, I messed that up during the rebase. That being said it magically
> > gets fixed in the next patch..
>
> Yes. However if someone does a bisection they are going to be mighty unhappy
> with you.
Sure, I was planning on fixing it anyway. Just waiting for feedback
on the rest of the patches before doing a respin.
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > - if (!io_tlb_alloc_size)
> > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > - __func__, alloc_size, PAGE_SIZE);
> >
> > Shouldn't this be converted to:
> > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > if (...)
> >
> > Seems that it got lost in the search and replace?
>
> Yes, I messed that up during the rebase. That being said it magically
> gets fixed in the next patch..
Yes. However if someone does a bisection they are going to be mighty unhappy
with you.
Re: [PATCH] xen/arm: introduce XENFEAT_direct_mapped and XENFEAT_not_direct_mapped
On 2/25/21 6:51 PM, Stefano Stabellini wrote: > Newer Xen versions expose two Xen feature flags to tell us if the domain > is directly mapped or not. Only when a domain is directly mapped it > makes sense to enable swiotlb-xen on ARM. > > Introduce a function on ARM to check the new Xen feature flags and also > to deal with the legacy case. Call the function xen_swiotlb_detect. > > Also rename the existing pci_xen_swiotlb_detect on x86 to > xen_swiotlb_detect so that we can share a common function declaration. > > Signed-off-by: Stefano Stabellini > --- > > This is the corresponding Xen patch under review: > https://marc.info/?l=xen-devel&m=161421618217686 > > We don't *have to* make the x86 function and the ARM function exactly > the same, but I thought it would be much nicer if we did. However, we > can't really call it pci_* on ARM as there is no PCI necessarily. I would prefer to keep existing names for consistency on x86 side (but making that inconsistent with ARM, as you point out). But if you feel strongly about making the change you would have to have x86 maintainers agree to this (arch/x86/kernel/pci-swiotlb.c). -boris
Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring
On Tue, Mar 16, 2021 at 04:22:21PM +0100, Hsu, Chiahao wrote: > > > Leon Romanovsky 於 2021/3/14 11:04 寫道: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and know > > the content is safe. > > > > > > > > On Fri, Mar 12, 2021 at 09:36:59PM +0100, Andrew Lunn wrote: > > > On Fri, Mar 12, 2021 at 04:18:02PM +0100, Hsu, Chiahao wrote: > > > > Andrew Lunn 於 2021/3/12 15:52 寫道: > > > > > CAUTION: This email originated from outside of the organization. Do > > > > > not click links or open attachments unless you can confirm the sender > > > > > and know the content is safe. > > > > > > > > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 10:59:44PM +, ChiaHao Hsu wrote: > > > > > > In order to support live migration of guests between kernels > > > > > > that do and do not support 'feature-ctrl-ring', we add a > > > > > > module parameter that allows the feature to be disabled > > > > > > at run time, instead of using hardcode value. > > > > > > The default value is enable. > > > > > Hi ChiaHao > > > > > > > > > > There is a general dislike for module parameters. What other > > > > > mechanisms > > > > > have you looked at? Would an ethtool private flag work? > > > > > > > > > >Andrew > > > > > > > > Hi Andrew, > > > > > > > > I can survey other mechanisms, however before I start doing that, > > > > > > > > could you share more details about what the problem is with using module > > > > parameters? thanks. > > > It is not very user friendly. No two kernel modules use the same > > > module parameters. Often you see the same name, but different > > > meaning. There is poor documentation, you often need to read the > > > kernel sources it figure out what it does, etc. > > +1, It is also global parameter to whole system/devices that use this > > module, which is rarely what users want. > > > > Thanks > > Hi, > I think I would say the current implementation(modparams) isappropriate > after reviewing it again. > > We are talking about 'feature leveling', a way to support live migrationof > guest > between kernels that do and do not support the features. So we want to > refrain > fromadding the features if guest would be migrated to the kernel which does > not support the feature. Everythingshould be done (in probe function) before > frontend connects, and this is why ethtool is not appropriate for this. It wouldn't be a surprise to you that feature discovery is not supposed to be done through module parameters. Instead of asking from user to randomly disable some feature, the system is expected to be backward compatible and robust enough to query the list of supported/needed features. Thanks > > Thanks > >
Re: [PATCH] xen/arm: Prevent Dom0 to be loaded when using dom0less
Hi,
I’ve checked the common code and the arm part, I can confirm that the domid 0
is never allocated even if the domain 0 is not present, here the only places
where domain_create(…) is called using a variable value:
1) xen/arch/arm/domain_build.c
d = domain_create(++max_init_domid, &d_cfg, false);
Where max_init_domid has value 0 and it is defined in setup.c
2) xen/common/domctl.c
d = domain_create(dom, &op->u.createdomain, false);
For me seems that the dom variable won’t take the 0 value, if someone could
give another feedback it would be great.
On every other part where domain_create(…) is used, it is called with a
constant value different from 0.
For the hardware_domain being NULL and not handled in some situation, it seems
that it’s not directly related to this patch, but I can handle it on a next
serie, from a quick look it seems that many cases can be handled by checking if
the domain is NULL in is_hardware_domain(…).
So, if the community agree, I can push a v2 patch with all the discussed things
(moving dom0 creation code)
Cheers,
Luca
> On 12 Mar 2021, at 11:31, Julien Grall wrote:
>
> Hi Luca,
>
> On 12/03/2021 09:38, Luca Fancellu wrote:
+
size_t __read_mostly dcache_line_bytes;
/* C entry point for boot CPU */
@@ -804,7 +833,7 @@ void __init start_xen(unsigned long boot_phys_offset,
int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
-struct domain *dom0;
+struct domain *dom0 = NULL;
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
.max_evtchn_port = -1,
@@ -964,28 +993,33 @@ void __init start_xen(unsigned long boot_phys_offset,
apply_alternatives_all();
enable_errata_workarounds();
-/* Create initial domain 0. */
-/* The vGIC for DOM0 is exactly emulating the hardware GIC */
-dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
-/*
- * Xen vGIC supports a maximum of 992 interrupt lines.
- * 32 are substracted to cover local IRQs.
- */
-dom0_cfg.arch.nr_spis = min(gic_number_lines(), (unsigned int) 992) -
32;
-if ( gic_number_lines() > 992 )
-printk(XENLOG_WARNING "Maximum number of vGIC IRQs exceeded.\n");
-dom0_cfg.arch.tee_type = tee_get_type();
-dom0_cfg.max_vcpus = dom0_max_vcpus();
-
-if ( iommu_enabled )
-dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
-
-dom0 = domain_create(0, &dom0_cfg, true);
-if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
-panic("Error creating domain 0\n");
-
-if ( construct_dom0(dom0) != 0)
-panic("Could not set up DOM0 guest OS\n");
+if ( !is_dom0less_mode() )
+{
+/* Create initial domain 0. */
+/* The vGIC for DOM0 is exactly emulating the hardware GIC */
+dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+/*
+* Xen vGIC supports a maximum of 992 interrupt lines.
+* 32 are substracted to cover local IRQs.
+*/
+dom0_cfg.arch.nr_spis = min(gic_number_lines(), (unsigned int)
992) - 32;
+if ( gic_number_lines() > 992 )
+printk(XENLOG_WARNING "Maximum number of vGIC IRQs
exceeded.\n");
+dom0_cfg.arch.tee_type = tee_get_type();
+dom0_cfg.max_vcpus = dom0_max_vcpus();
+
+if ( iommu_enabled )
+dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
+dom0 = domain_create(0, &dom0_cfg, true);
+if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
+panic("Error creating domain 0\n");
+
+if ( construct_dom0(dom0) != 0)
+panic("Could not set up DOM0 guest OS\n");
+}
>>>
>>> It always felt a bit strange the dom0 creation is partly happening in
>>> setup.c when for domU everythink will happen in domain_build.c.
>>>
>>> Woule you be able to create a patch that will first move the code in a new
>>> function (maybe create_dom0())? The function would return NULL in case of
>>> an error or the domain.
>> Yes I will create a new patch with this change and I will put on top the v2
>> dom0less patch
>
> I think it would be better to put it first. This will avoid some churn if the
> code movmement comes second (you would first indent and then move the code).
>
> Cheers,
>
> --
> Julien Grall
Re: libxl / xen-pciback interaction [and 1 more messages]
Jan Beulich writes ("Re: libxl / xen-pciback interaction [and 1 more
messages]"):
> On 17.03.2021 16:12, Ian Jackson wrote:
> > How does what libxl is doing differ from a setup, immediately followed
> > by a hot-add ?
>
> In the hot-add case libxl drives things through Reconfiguring state.
> I'm not sure this would be an appropriate (and backwards compatible)
> thing to do when initially populating xenstore.
Ah. Tbanks, that is precisely the answer to my question.
I think that means, therefore, populating the whole lot in one
transaction.
(From what you say it doesn't sound like it's possible to write only a
subset, perhaps with state "not ready yet" and then set them all go
"go" at the end.)
Ian.
Re: libxl / xen-pciback interaction [and 1 more messages]
On 17.03.2021 16:12, Ian Jackson wrote:
> Jan Beulich writes ("libxl / xen-pciback interaction"):
>> while trying to test a pciback fix for how SR-IOV VFs get placed in the
>> guest PCI topology I noticed that my test VM would only ever see the 1st
>> out of 3 VFs that I passed to it. As it turns out, the driver watches
>> its own (backend) node, and upon first receiving notification it
>> evaluates state found in xenstore to set up the backend device.
>> Subsequently it switches the device to Initialised. After this switching,
>> not further instances of the watch triggering would do anything.
>
> This makes it sound like this driver does not support hotplug.
>
>> While doing this it also occurred to me as odd how "num_devs" is
>> actually used: It's not really a "number of devices" indicator, but
>> instead a "next device has this number" one: libxl reads the present
>> value and increments it by one for every new device. Destroying
>> (hot-unplugging) of devices doesn't have any effect on the value.
>
> But this makes it sound like the driver *does* support hotplug.
>
> How does what libxl is doing differ from a setup, immediately followed
> by a hot-add ?
In the hot-add case libxl drives things through Reconfiguring state.
I'm not sure this would be an appropriate (and backwards compatible)
thing to do when initially populating xenstore.
Jan
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
Roger Pau Monné writes ("Re: [PATCH 1/3] Revert "x86/msr: drop compatibility
#GP handling in guest_{rd,wr}msr()""):
> On Wed, Mar 17, 2021 at 02:46:20PM +, Ian Jackson wrote:
> > Roger, can I get your opinion about the possible downside risks of
> > this patch ?
>
> For patches 1 and 2 the risk is low I think. This is already the same
> handling that we do in pre-4.15, so it's unlikely to cause issues.
> >From a guests PoV they don't change the result of trying to access any
> of the modified MSRs, accessing them will still result in a #GP being
> injected to the guest.
>
> The main risk for patch 3 would be that reporting 0 for
> MSR_RAPL_POWER_UNIT would result in some kind of issue on certain
> guests, or that it triggers the poking of other MSRs in the
> expectation that they would be available. I think those are quite
> unlikely, and the patch fixes a real issue with Solaris guests.
Thanks. That is very helpful.
All three patches
Release-Acked-by: Ian Jackson
but subject to Jan's questions on patch 3 being resolved somehow.
Ian.
Re: libxl / xen-pciback interaction [and 1 more messages]
Jan Beulich writes ("libxl / xen-pciback interaction"):
> while trying to test a pciback fix for how SR-IOV VFs get placed in the
> guest PCI topology I noticed that my test VM would only ever see the 1st
> out of 3 VFs that I passed to it. As it turns out, the driver watches
> its own (backend) node, and upon first receiving notification it
> evaluates state found in xenstore to set up the backend device.
> Subsequently it switches the device to Initialised. After this switching,
> not further instances of the watch triggering would do anything.
This makes it sound like this driver does not support hotplug.
> While doing this it also occurred to me as odd how "num_devs" is
> actually used: It's not really a "number of devices" indicator, but
> instead a "next device has this number" one: libxl reads the present
> value and increments it by one for every new device. Destroying
> (hot-unplugging) of devices doesn't have any effect on the value.
But this makes it sound like the driver *does* support hotplug.
How does what libxl is doing differ from a setup, immediately followed
by a hot-add ?
> If addition / removal of a device happens a number of times for a
> VM, quite a few leftover, no longer used entries would accumulate
> afaict. This isn't only consuming space in xenstore for no good
> reason, but also means pciback has to do an increasing amount of
> processing every time a reconfigure event happens.
I'm kind of surprised that num_devs is used this way by the driver. I
guess the obvious approach of just listing the directory to find the
devices would often be accidentally-quadratic in the number of
simultaneous PCI devices but that hardly seems like a problem.
I wonder if there is some race/reuse hazard that would prevent libxl
knowing when to reuse a dev number.
Ian.
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
On Wed, Mar 17, 2021 at 02:46:20PM +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 1/3] Revert "x86/msr: drop compatibility
> #GP handling in guest_{rd,wr}msr()""):
> > On 17/03/2021 13:37, Ian Jackson wrote:
> > > AFAICT there is no explanation for why patches 1/ and 2/ deserve to go
> > > into 4.15.
>
> I see now, rereading the thread, that there was a sentence about this
> in each patch betwen the commit message and the diff. Sorry for
> missing that. (Although TBH at least one of those messages could
> usefully have gone into the commit message, as useful motivational
> background.)
>
> > > We are late in the freeze now, so I would ideally be
> > > looking for a clear and compelling argument. I'd also like to
> > > understand what the risks are of taking these. Can someone please
> > > enlighten me ?
> >
> > To make the code in 4.15 match 4.14, so patch 3 can be written in the
> > first place.
> >
> > Also, as a side benefit, patches 1 and 2 reduce the quantity of logspew
> > from the impacted MSRs.
> >
> > We cannot simply take patch 3 as-is, and say "4.14 and earlier" for
> > backport, because that still forces end users to specify msr_relaxed to
> > unbreak their Solaris guests, which is usability regression vs 4.14
>
> This is plausible and going in the right direction but I still feel
> uncertain.
>
> Jan, what is your summary opinion about patch 3 ?
>
> Roger, can I get your opinion about the possible downside risks of
> this patch ?
For patches 1 and 2 the risk is low I think. This is already the same
handling that we do in pre-4.15, so it's unlikely to cause issues.
>From a guests PoV they don't change the result of trying to access any
of the modified MSRs, accessing them will still result in a #GP being
injected to the guest.
The main risk for patch 3 would be that reporting 0 for
MSR_RAPL_POWER_UNIT would result in some kind of issue on certain
guests, or that it triggers the poking of other MSRs in the
expectation that they would be available. I think those are quite
unlikely, and the patch fixes a real issue with Solaris guests.
Roger.
Re: [PATCH for-next v2 2/2] xen/arm64: Place a speculation barrier following an ret instruction
Hi Julien,
> On 13 Mar 2021, at 16:06, Julien Grall wrote:
>
> From: Julien Grall
>
> Some CPUs can speculate past a RET instruction and potentially perform
> speculative accesses to memory before processing the return.
>
> There is no known gadget available after the RET instruction today.
> However some of the registers (such as in check_pending_guest_serror())
> may contain a value provided by the guest.
>
> In order to harden the code, it would be better to add a speculation
> barrier after each RET instruction. The performance impact is meant to
> be negligeable as the speculation barrier is not meant to be
> architecturally executed.
>
> Rather than manually inserting a speculation barrier, use a macro
> which overrides the mnemonic RET and replace with RET + SB. We need to
> use the opcode for RET to prevent any macro recursion.
>
> This patch is only covering the assembly code. C code would need to be
> covered separately using the compiler support.
>
> This is part of the work to mitigate straight-line speculation.
>
> Signed-off-by: Julien Grall
The macro solution is definitely a great improvement compared to v1 and I could
confirm the presence of the sb in the generated code.
I also think that the mitigation on arm32/v7 would be messy to do.
Shall we mark v7/aarch32 as not security supported ?
Apart from this global question (which does not need to be answered in this
serie):
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
>
> ---
>
> It is not clear to me whether Armv7 (we don't officially support 32-bit
> hypervisor on Armv8) is also affected by straight-line speculation.
>
> But the mitigation is a lot messier because opcode can be optionally
> executed. So this Arm32 is left alone for now.
>
>Changes in v2:
>- Use a macro rather than inserting the speculation barrier
>manually
>- Remove mitigation for arm32
> ---
> xen/arch/arm/arm32/entry.S | 1 +
> xen/arch/arm/arm32/lib/lib1funcs.S | 1 +
> xen/include/asm-arm/arm64/macros.h | 6 ++
> xen/include/asm-arm/macros.h | 18 +-
> 4 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> index f2f1bc7a3158..d0a066484f13 100644
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -441,6 +441,7 @@ ENTRY(__context_switch)
>
> add r4, r1, #VCPU_arch_saved_context
> ldmia r4, {r4 - sl, fp, sp, pc} /* Load registers and return
> */
> +sb
>
> /*
> * Local variables:
> diff --git a/xen/arch/arm/arm32/lib/lib1funcs.S
> b/xen/arch/arm/arm32/lib/lib1funcs.S
> index f1278bd6c139..8c33ffbbcc4c 100644
> --- a/xen/arch/arm/arm32/lib/lib1funcs.S
> +++ b/xen/arch/arm/arm32/lib/lib1funcs.S
> @@ -382,5 +382,6 @@ UNWIND(.save {lr})
> bl __div0
> mov r0, #0 @ About as wrong as it could be.
> ldr pc, [sp], #8
> + sb
> UNWIND(.fnend)
> ENDPROC(Ldiv0)
> diff --git a/xen/include/asm-arm/arm64/macros.h
> b/xen/include/asm-arm/arm64/macros.h
> index f981b4f43e84..4614394b3dd5 100644
> --- a/xen/include/asm-arm/arm64/macros.h
> +++ b/xen/include/asm-arm/arm64/macros.h
> @@ -21,6 +21,12 @@
> ldr \dst, [\dst, \tmp]
> .endm
>
> +.macro ret
> +// ret opcode
> +.inst 0xd65f03c0
> +sb
> +.endm
> +
> /*
> * Register aliases.
> */
> diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
> index 4833671f4ced..1aa373760f98 100644
> --- a/xen/include/asm-arm/macros.h
> +++ b/xen/include/asm-arm/macros.h
> @@ -5,6 +5,15 @@
> # error "This file should only be included in assembly file"
> #endif
>
> +/*
> + * Speculative barrier
> + * XXX: Add support for the 'sb' instruction
> + */
> +.macro sb
> +dsb nsh
> +isb
> +.endm
> +
> #if defined (CONFIG_ARM_32)
> # include
> #elif defined(CONFIG_ARM_64)
> @@ -20,13 +29,4 @@
> .endr
> .endm
>
> -/*
> - * Speculative barrier
> - * XXX: Add support for the 'sb' instruction
> - */
> -.macro sb
> -dsb nsh
> -isb
> -.endm
> -
> #endif /* __ASM_ARM_MACROS_H */
> --
> 2.17.1
>
Call for tools backports (was Re: preparations for 4.13.3)
Julien Grall writes ("Re: preparations for 4.13.3"):
> On 08/03/2021 09:49, Jan Beulich wrote:
> > All,
> >
> > the release is overdue (my apologies). Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant.
> > > Ones that I have queued already, but which hadn't passed the push
> > gate to master yet when doing a swipe late last week, are
> >
> > c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
> > 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without
> > reserved bits
> > 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when
> > running virtualized
>
> I would like to also consider the following one:
>
> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1,
> 2} drivers (4.11+ as updating the security support)
> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
> To support newer kernel on stable Xen
> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped
> (4.13 only)
> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before
> vcpu_pause() returns (4.13 only)
>
> I have put in parentheses the list of versions targeted.
My backport list seems to have very few tools patches on it.
If anyone has any tools bugfixes that ought to go into 4.13 please do
let me know!
Additionally, perhaps this one commit to be backported ?
935e0836710ce8cab584155b2844cea8497a5159
arm: replace typeof() with __typeof__()
Thanks,
Ian.
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
Andrew Cooper writes ("Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP
handling in guest_{rd,wr}msr()""):
> On 17/03/2021 13:37, Ian Jackson wrote:
> > AFAICT there is no explanation for why patches 1/ and 2/ deserve to go
> > into 4.15.
I see now, rereading the thread, that there was a sentence about this
in each patch betwen the commit message and the diff. Sorry for
missing that. (Although TBH at least one of those messages could
usefully have gone into the commit message, as useful motivational
background.)
> > We are late in the freeze now, so I would ideally be
> > looking for a clear and compelling argument. I'd also like to
> > understand what the risks are of taking these. Can someone please
> > enlighten me ?
>
> To make the code in 4.15 match 4.14, so patch 3 can be written in the
> first place.
>
> Also, as a side benefit, patches 1 and 2 reduce the quantity of logspew
> from the impacted MSRs.
>
> We cannot simply take patch 3 as-is, and say "4.14 and earlier" for
> backport, because that still forces end users to specify msr_relaxed to
> unbreak their Solaris guests, which is usability regression vs 4.14
This is plausible and going in the right direction but I still feel
uncertain.
Jan, what is your summary opinion about patch 3 ?
Roger, can I get your opinion about the possible downside risks of
this patch ?
Thanks,
Ian.
Re: [PATCH for-next v2 1/2] xen/arm: Include asm/asm-offsets.h and asm/macros.h on every assembly files
Hi Julien, > On 13 Mar 2021, at 16:06, Julien Grall wrote: > > From: Julien Grall > > In a follow-up patch we may want to automatically replace some > mnemonics (such as ret) with a different sequence. > > To ensure all the assembly files will include asm/macros.h it is best to > automatically include it on single assembly. This can be done via > config.h. > > It was necessary to include a few more headers as dependency: > - to define sizeof_* > - which is already a latent issue given STACK_ORDER > rely on PAGE_SIZE. > > Unfortunately the build system will use -D__ASSEMBLY__ when generating > the linker script. A new option -D__LINKER__ is introduceed and used for > the linker script to avoid including headers (such as asm/macros.h) that > may not be compatible with the syntax. > > Lastly, take the opportunity to remove both asm/asm-offsets.h and > asm/macros.h from the various assembly files as they are now > automagically included. > > Signed-off-by: Julien Grall Everything is now building :-) I could not find a better then your define as filtering out or undefining __ASSEMBLY__ is actually not working. So with the fix from offset to defns: Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > xen/arch/arm/Makefile| 2 +- > xen/arch/arm/arm32/entry.S | 1 - > xen/arch/arm/arm32/head.S| 1 - > xen/arch/arm/arm32/proc-v7.S | 1 - > xen/arch/arm/arm64/debug-cadence.inc | 1 - > xen/arch/arm/arm64/debug-pl011.inc | 2 -- > xen/arch/arm/arm64/entry.S | 2 -- > xen/arch/arm/arm64/head.S| 2 -- > xen/arch/arm/arm64/smc.S | 3 --- > xen/include/asm-arm/config.h | 6 ++ > 10 files changed, 7 insertions(+), 14 deletions(-) > > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > index 16e6523e2cc6..9ffc3f771c51 100644 > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -135,7 +135,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c > $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $< > > xen.lds: xen.lds.S > - $(CPP) -P $(a_flags) -MQ $@ -o $@ $< > + $(CPP) -P $(a_flags) -D__LINKER__ -MQ $@ -o $@ $< > > dtb.o: $(CONFIG_DTB_FILE) > > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S > index b228d44b190c..f2f1bc7a3158 100644 > --- a/xen/arch/arm/arm32/entry.S > +++ b/xen/arch/arm/arm32/entry.S > @@ -1,4 +1,3 @@ > -#include > #include > #include > #include > diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S > index c404fa973e9b..9084023a6ed9 100644 > --- a/xen/arch/arm/arm32/head.S > +++ b/xen/arch/arm/arm32/head.S > @@ -18,7 +18,6 @@ > */ > > #include > -#include > #include > > #define ZIMAGE_MAGIC_NUMBER 0x016f2818 > diff --git a/xen/arch/arm/arm32/proc-v7.S b/xen/arch/arm/arm32/proc-v7.S > index 46bfc7a9074c..1efde2d72da0 100644 > --- a/xen/arch/arm/arm32/proc-v7.S > +++ b/xen/arch/arm/arm32/proc-v7.S > @@ -17,7 +17,6 @@ > * GNU General Public License for more details. > */ > > -#include > #include > #include > > diff --git a/xen/arch/arm/arm64/debug-cadence.inc > b/xen/arch/arm/arm64/debug-cadence.inc > index 7df0abe4756f..0b6f2e094e18 100644 > --- a/xen/arch/arm/arm64/debug-cadence.inc > +++ b/xen/arch/arm/arm64/debug-cadence.inc > @@ -17,7 +17,6 @@ > * GNU General Public License for more details. > */ > > -#include > #include > > /* > diff --git a/xen/arch/arm/arm64/debug-pl011.inc > b/xen/arch/arm/arm64/debug-pl011.inc > index 385deff49b1b..1928a2e3ffbb 100644 > --- a/xen/arch/arm/arm64/debug-pl011.inc > +++ b/xen/arch/arm/arm64/debug-pl011.inc > @@ -16,8 +16,6 @@ > * GNU General Public License for more details. > */ > > -#include > - > /* > * PL011 UART initialization > * xb: register which containts the UART base address > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S > index 175ea2981e72..ab9a65fc1475 100644 > --- a/xen/arch/arm/arm64/entry.S > +++ b/xen/arch/arm/arm64/entry.S > @@ -1,6 +1,4 @@ > -#include > #include > -#include > #include > #include > #include > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S > index 5d44667bd89d..fa7a3ffd2926 100644 > --- a/xen/arch/arm/arm64/head.S > +++ b/xen/arch/arm/arm64/head.S > @@ -21,11 +21,9 @@ > */ > > #include > -#include > #include > #include > #include > -#include > > #define PT_PT 0xf7f /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=1 P=1 */ > #define PT_MEM0xf7d /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=0 P=1 */ > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S > index b0752be57e8f..91bae62dd4d2 100644 > --- a/xen/arch/arm/arm64/smc.S > +++ b/xen/arch/arm/arm64/smc.S > @@ -13,9 +13,6 @@ > * GNU General Public License for more details. > */ > > -#include > -#include > - > /* > * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > * register_t a3, register_t a4, register_t a5, > diff --git a/xen/include/asm-arm/config.h b/xen
xen/evtchn: Dom0 boot hangs using preempt_rt kernel 5.10
Hi all, we've been encountering an issue when using the kernel 5.10 with preempt_rt support for Dom0, the problem is that during the boot of Dom0, it hits a BUG_ON(!irqs_disabled()) from the function evtchn_fifo_unmask defined in events_fifo.c. This is the call stack: [ 17.817018] [ cut here ] [ 17.817021] kernel BUG at drivers/xen/events/events_fifo.c:258! [ 18.817079] Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP [ 18.817081] Modules linked in: bridge stp llc ipv6 [ 18.817086] CPU: 3 PID: 558 Comm: xenstored Not tainted 5.10.16-rt25-yocto-preempt-rt #1 [ 18.817089] Hardware name: Arm Neoverse N1 System Development Platform (DT) [ 18.817090] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 18.817092] pc : evtchn_fifo_unmask+0xd4/0xe0 [ 18.817099] lr : xen_irq_lateeoi_locked+0xec/0x200 [ 18.817102] sp : 8000123f3cc0 [ 18.817102] x29: 8000123f3cc0 x28: 427b1d80 [ 18.817104] x27: x26: [ 18.817106] x25: 0001 x24: 0001 [ 18.817107] x23: 412fc900 x22: 0004 [ 18.817109] x21: x20: 42e06990 [ 18.817110] x19: 427b1d80 x18: 0010 [ 18.817112] x17: x16: [ 18.817113] x15: 0002 x14: 0001 [ 18.817114] x13: 0001a7e8 x12: 0040 [ 18.817116] x11: 40400248 x10: 4040024a [ 18.817117] x9 : 800011be5200 x8 : 40400270 [ 18.817119] x7 : x6 : 0003 [ 18.817120] x5 : x4 : 40400308 [ 18.817121] x3 : 408a400c x2 : [ 18.817122] x1 : x0 : 408a4000 [ 18.817124] Call trace: [ 18.817125] evtchn_fifo_unmask+0xd4/0xe0 [ 18.817127] xen_irq_lateeoi_locked+0xec/0x200 [ 18.817129] xen_irq_lateeoi+0x48/0x64 [ 18.817131] evtchn_write+0x124/0x15c [ 18.817134] vfs_write+0xf0/0x2cc [ 18.817137] ksys_write+0xe0/0x100 [ 18.817139] __arm64_sys_write+0x20/0x30 [ 18.817142] el0_svc_common.constprop.0+0x78/0x1a0 [ 18.817145] do_el0_svc+0x24/0x90 [ 18.817147] el0_svc+0x14/0x20 [ 18.817151] el0_sync_handler+0x1a4/0x1b0 [ 18.817153] el0_sync+0x174/0x180 [ 18.817156] Code: 52800120 b90023e6 97e6d104 17f0 (d421) [ 18.817158] ---[ end trace 0002 ]--- Our last tested kernel was the 5.4 and our analysis pointed out that the introduction of the lateeoi framework (xen/events: add a new "late EOI" evtchn framework) in conjunction with the preempt_rt patches (irqs kept enabled between spinlock_t/rwlock_t _irqsave/_irqrestore operations) is the root cause. Given that many modifications were made to the mask/unmask operations, a big one from Juergen Gross (xen/events: don't unmask an event channel when an eoi is pending), is the BUG_ON(...) still needed? With the mentioned commit every call to a mask/unmask operation is protected by a spinlock, so I would like to have some feedbacks from who has more experience than me on this part of the code. Thank you, Luca
Re: [PATCH for-next v2 0/2] xen/arm: Mitigate straight-line speculation
Hi Julien, > On 17 Mar 2021, at 11:20, Julien Grall wrote: > > > > On 16/03/2021 17:16, Bertrand Marquis wrote: >> Hi Julien, > > Hi Bertrand, > >>> On 16 Mar 2021, at 15:27, Julien Grall wrote: >>> >>> >>> >>> On 15/03/2021 13:32, Bertrand Marquis wrote: Hi Julien, >>> >>> Hi Bertrand, >>> > On 13 Mar 2021, at 16:06, Julien Grall wrote: > > From: Julien Grall > > Hi all, > > Last year, Arm released a whitepaper about a new category of speculation. > (see [1] and [2]). In short, a processor may be able to speculate past > some of the unconditional control flow instructions (e.g eret, smc, br). > > In some of the cases, the registers will contain values controlled by > the guest. While there is no known gadget afterwards, we still want to > prevent any leakage in the future. > > The mitigation is planned in two parts: > 1) Arm provided patches for both GCC and LLVM to add speculation barrier > and remove problematic code sequence. > 2) Inspection of assembly code and call to higher level (e.g smc in our > case). > > I still haven't looked at 1) and how to mitigate properly Arm32 (see > patch #1) and SMC call. So this issue is not fully addressed. > > Note that the ERET instruction was already addressed as part of XSA-312. On my tests, this serie is breaking the arm64 build: | aarch64-poky-linux-ld --sysroot=/home/bermar01/Development/xen-dev/build/profile-fvp-base.prj/tmp/work/fvp_base-poky-linux/xen/4.15+git1-r0/recipe-sysroot -EL --fix-cortex-a53-843419 --fix-cortex-a53-843419 -r -o built_in.o memcpy.o memcmp.o memmove.o memset.o memchr.o clear_page.o bitops.o find_next_bit.o strchr.o strcmp.o strlen.o strncmp.o strnlen.o strrchr.o >>> >>> I can't see any build failure with the following GCC: >>> >>> 42sh> aarch64-linux-gnu-gcc >>> aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>> Copyright (C) 2017 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> >>> AFAICT, there is also no compilation issue reported by gitlab: >>> >>> https://gitlab.com/xen-project/patchew/xen/-/pipelines/269989894 >>> >>> What's the version of your compiler? Do you have steps to reproduce your >>> setup? >> You need to have earlyprintk enabled >> I am using gcc 7.5.0: >> aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >> one configuration triggering the issue is using the default .config with the >> following items added: >> CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y >> CONFIG_DEBUG_LOCK_PROFILE=y >> CONFIG_PERF_COUNTERS=y >> CONFIG_PERF_ARRAYS=y >> CONFIG_DEVICE_TREE_DEBUG=y >> CONFIG_DEBUG_TRACE=y >> CONFIG_EARLY_PRINTK_JUNO=y >> CONFIG_EARLY_UART_PL011=y >> CONFIG_EARLY_PRINTK=y >> CONFIG_EARLY_UART_BASE_ADDRESS=0x7ff8 >> CONFIG_EARLY_UART_PL011_BAUD_RATE=115200 >> CONFIG_EARLY_UART_INIT=y >> CONFIG_EARLY_PRINTK_INC="debug-pl011.inc” > > Thanks for providing the .config. I managed to reproduce it. So I removed > "asm_defns.h" everywhere but forgot to include it in the "config.h" :/. > > This small change fixed the error: > > diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h > index 51273b9db1fc..c7b77912013e 100644 > --- a/xen/include/asm-arm/config.h > +++ b/xen/include/asm-arm/config.h > @@ -192,7 +192,7 @@ extern unsigned long frametable_virt_end; > #define watchdog_enable() ((void)0) > > #if defined(__ASSEMBLY__) && !defined(__LINKER__) > -#include > +#include > #include > #endif > > Would you still be happy to review the series before I send a v3? Sure, I will restart my tests with this change now and review the v2 once passed. Cheers Bertrand > > Cheers, > > -- > Julien Grall
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rzeszutek Wilk wrote:
> > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > - if (!io_tlb_alloc_size)
> > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > - __func__, alloc_size, PAGE_SIZE);
>
> Shouldn't this be converted to:
> mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> if (...)
>
> Seems that it got lost in the search and replace?
Yes, I messed that up during the rebase. That being said it magically
gets fixed in the next patch..
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
On 17/03/2021 13:37, Ian Jackson wrote: > I have read this thread and with my release manager hat on I feel > confused and/or ignorant. > > Patch 3/ has a good explanation of what the problem is it is > addressing and why this is important for 4.15. But then there is > Jan's most recent reply starting "I find all of this confusing". Jan, > can you please tell me in words of one syllable what the implication > of that message is ? In particular is any of what you say a reason > for me to withhold my release-ack ? > > AFAICT there is no explanation for why patches 1/ and 2/ deserve to go > into 4.15. We are late in the freeze now, so I would ideally be > looking for a clear and compelling argument. I'd also like to > understand what the risks are of taking these. Can someone please > enlighten me ? To make the code in 4.15 match 4.14, so patch 3 can be written in the first place. Also, as a side benefit, patches 1 and 2 reduce the quantity of logspew from the impacted MSRs. We cannot simply take patch 3 as-is, and say "4.14 and earlier" for backport, because that still forces end users to specify msr_relaxed to unbreak their Solaris guests, which is usability regression vs 4.14 ~Andrew
Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
..snip..
> int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> verbose)
> {
..snip..
> /*
>* Allocate and initialize the free list array. This array is used
>* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
> - * between io_tlb_start and io_tlb_end.
> + * between mem->start and mem->end.
>*/
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(int));
> - io_tlb_list = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_list)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(int));
> + mem->list = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->list)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(phys_addr_t));
> - io_tlb_orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_orig_addr)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(phys_addr_t));
> + mem->orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->orig_addr)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_alloc_size)
> - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> - __func__, alloc_size, PAGE_SIZE);
Shouldn't this be converted to:
mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
if (...)
Seems that it got lost in the search and replace?
> -
> - for (i = 0; i < io_tlb_nslabs; i++) {
> - io_tlb_list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> - io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> - io_tlb_alloc_size[i] = 0;
> + for (i = 0; i < mem->nslabs; i++) {
> + mem->list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> + mem->orig_addr[i] = INVALID_PHYS_ADDR;
> + mem->alloc_size[i] = 0;
> }
> - io_tlb_index = 0;
> no_iotlb_memory = false;
>
> if (verbose)
> swiotlb_print_info();
>
> - swiotlb_set_max_segment(io_tlb_nslabs << IO_TLB_SHIFT);
> + swiotlb_set_max_segment(mem->nslabs << IO_TLB_SHIFT);
> return 0;
> }
>
..snip..
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
I have read this thread and with my release manager hat on I feel confused and/or ignorant. Patch 3/ has a good explanation of what the problem is it is addressing and why this is important for 4.15. But then there is Jan's most recent reply starting "I find all of this confusing". Jan, can you please tell me in words of one syllable what the implication of that message is ? In particular is any of what you say a reason for me to withhold my release-ack ? AFAICT there is no explanation for why patches 1/ and 2/ deserve to go into 4.15. We are late in the freeze now, so I would ideally be looking for a clear and compelling argument. I'd also like to understand what the risks are of taking these. Can someone please enlighten me ? Thanks, Ian.
[linux-linus test] 160105: regressions - FAIL
flight 160105 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/160105/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 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-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-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-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check
Re: [PATCH for-4.15 v3] SUPPORT.MD: Mark LiveUpdate of C/OCaml XenStored daemon as Tech Preview
On 17/03/2021 12:31, Jürgen Groß wrote: > On 17.03.21 13:08, Julien Grall wrote: >> From: Julien Grall >> >> Support to liveupdate C/OCaml XenStored daemon was added during the >> 4.15 development cycle. Add two new sections in SUPPORT.MD to explain >> what is the support state. >> >> For now, it is a tech preview. >> >> Signed-off-by: Julien Grall > > Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper I'll add "how to live update" to my pile of docs needing to happen for 4.15.
Re: [PATCH for-4.15 v3] SUPPORT.MD: Mark LiveUpdate of C/OCaml XenStored daemon as Tech Preview
On 17.03.21 13:08, Julien Grall wrote: From: Julien Grall Support to liveupdate C/OCaml XenStored daemon was added during the 4.15 development cycle. Add two new sections in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[PATCH for-4.15 v3] SUPPORT.MD: Mark LiveUpdate of C/OCaml XenStored daemon as Tech Preview
From: Julien Grall Support to liveupdate C/OCaml XenStored daemon was added during the 4.15 development cycle. Add two new sections in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall --- CC: Juergen Gross Changes in v3: - Add a section of OCaml XenStored Changes in v2: - Clarify this is only supported for the daemon version - Fix typoes --- SUPPORT.md | 8 1 file changed, 8 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 7db4568f1a0f..1021a24801dc 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -177,6 +177,14 @@ Support for running qemu-xen device model in a linux stubdomain. Status: Tech Preview +## Liveupdate of C XenStored daemon + +Status: Tech Preview + +## Liveupdate of OCaml XenStored daemon + +Status: Tech Preview + ## Toolstack/3rd party ### libvirt driver for xl -- 2.17.1
Re: [PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
Hi Andrew, On 17/03/2021 11:59, Andrew Cooper wrote: On 17/03/2021 11:54, Julien Grall wrote: On 17/03/2021 11:49, Andrew Cooper wrote: On 17/03/2021 11:27, Julien Grall wrote: From: Julien Grall Support to liveupdate C XenStored daemon was added during the 4.15 development cycle. Add a section in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall What about oxenstored ? Oh, I read your answer as there is no support. I can resend a patch with the following title: "LiveUpdate of C/Ocaml XenStored daemon" I'd put it at tech preview, just like Cxenstored. In particular, it has the same issues concerning outstanding transactions. I have some work planned for C XenStored to mitigate that as Paul recently discovered that some Windows PV drivers may leak transactions (see [1]). It might however be worth having separate line items in SUPPORT.md to start with, just in case the different implementations progress to supported at different times. (More likely, as there isn't an embargo adding urgency the work now.) Sure. Let me respin the patch. Cheers, [1] https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenbus.git;a=commit;h=4d3c233a51aef91d464db4d295a1d76ef774a27d -- Julien Grall
Re: [PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
On 17/03/2021 11:54, Julien Grall wrote: > On 17/03/2021 11:49, Andrew Cooper wrote: >> On 17/03/2021 11:27, Julien Grall wrote: >>> From: Julien Grall >>> >>> Support to liveupdate C XenStored daemon was added during the 4.15 >>> development cycle. Add a section in SUPPORT.MD to explain what is the >>> support state. >>> >>> For now, it is a tech preview. >>> >>> Signed-off-by: Julien Grall >> >> What about oxenstored ? > > Oh, I read your answer as there is no support. I can resend a patch > with the following title: > > "LiveUpdate of C/Ocaml XenStored daemon" I'd put it at tech preview, just like Cxenstored. In particular, it has the same issues concerning outstanding transactions. It might however be worth having separate line items in SUPPORT.md to start with, just in case the different implementations progress to supported at different times. (More likely, as there isn't an embargo adding urgency the work now.) ~Andrew
Re: [PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
On 17/03/2021 11:49, Andrew Cooper wrote: On 17/03/2021 11:27, Julien Grall wrote: From: Julien Grall Support to liveupdate C XenStored daemon was added during the 4.15 development cycle. Add a section in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall What about oxenstored ? Oh, I read your answer as there is no support. I can resend a patch with the following title: "LiveUpdate of C/Ocaml XenStored daemon" Cheers, -- Julien Grall
Re: [PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
On 17/03/2021 11:27, Julien Grall wrote: > From: Julien Grall > > Support to liveupdate C XenStored daemon was added during the 4.15 > development cycle. Add a section in SUPPORT.MD to explain what is the > support state. > > For now, it is a tech preview. > > Signed-off-by: Julien Grall What about oxenstored ? ~Andrew
Re: [PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
On 17.03.21 12:27, Julien Grall wrote: From: Julien Grall Support to liveupdate C XenStored daemon was added during the 4.15 development cycle. Add a section in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] xen: introduce XENFEAT_direct_mapped and XENFEAT_not_direct_mapped
Hi Stefano, On 17/03/2021 00:04, Stefano Stabellini wrote: On Tue, 16 Mar 2021, Jan Beulich wrote: On 15.03.2021 21:01, Stefano Stabellini wrote: On Mon, 15 Mar 2021, Jan Beulich wrote: On 13.03.2021 00:16, Stefano Stabellini wrote: Introduce two feature flags to tell the domain whether it is direct-mapped or not. It allows the guest kernel to make informed decisions on things such as swiotlb-xen enablement. The introduction of both flags (XENFEAT_direct_mapped and XENFEAT_not_direct_mapped) allows the guest kernel to avoid any guesswork if one of the two is present, or fallback to the current checks if neither of them is present. XENFEAT_direct_mapped is always set for not auto-translated guests. For auto-translated guests, only Dom0 on ARM is direct-mapped. Also, see is_domain_direct_mapped() which refers to auto-translated guests: xen/include/asm-arm/domain.h:is_domain_direct_mapped xen/include/asm-x86/domain.h:is_domain_direct_mapped Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: andrew.coop...@citrix.com CC: jul...@xen.org Any particular reason my previously given R-b isn't here? I reworded part of the comment in the public header, and I decided to err on the side of caution and not add your R-b given this change compared to the previous version. I see. FAOD, despite me not being overly happy with the "older Xen assumptions" part of the comment, feel free to add it back. Thank you! Julien, please go ahead and commit it to your for-next/4.16 branch when it is convenient. I have committed it to my for-next/4.16 branch. I will merge the branch after the tree has re-opened. Cheers, -- Julien Grall
[PATCH for-4.15 v2] SUPPORT.MD: Mark LiveUpdate of C XenStored daemon as Tech Preview
From: Julien Grall Support to liveupdate C XenStored daemon was added during the 4.15 development cycle. Add a section in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall --- CC: Juergen Gross Changes in v2: - Clarify this is only supported for the daemon version - Fix typoes --- SUPPORT.md | 4 1 file changed, 4 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 7db4568f1a0f..4c93afa3613b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -177,6 +177,10 @@ Support for running qemu-xen device model in a linux stubdomain. Status: Tech Preview +## Liveupdate of C XenStored daemon + +Status: Tech Preview + ## Toolstack/3rd party ### libvirt driver for xl -- 2.17.1
Re: [PATCH for-4.15] SUPPORT.MD: Mark C XenStored LiveUpdate as Tech Preview
Hi Juergen, On 16/03/2021 14:58, Jürgen Groß wrote: On 16.03.21 15:39, Julien Grall wrote: On 16/03/2021 14:36, Jürgen Groß wrote: On 16.03.21 15:35, Julien Grall wrote: Hi, On 15/03/2021 12:17, Andrew Cooper wrote: On 13/03/2021 13:55, Julien Grall wrote: From: Julien Grall Support to liveupdate C XenStored was adding during the 4.15 development cycle. Add a section in SUPPORT.MD to explain what is the support state. For now, it is a tech preview. Signed-off-by: Julien Grall --- CC: Juergen Gross It looks like the OCaml side was not merged in 4.15. Yes it was. So I have only described the support state for C XenStored. What about stub-cxenstored? I think it wants pointing out specifically, whatever its status, to avoid confusion. Is it even working? @Juergen? LU of xenstore-stubdom isn't working yet. Ok. Would renaming the section to "Dom0 C Xen-Stored LiveUpdate" would be suitable? "Xen-Stored" in rather unusual. What about "LiveUpdate of C Xenstore daemon"? I am fine with that. I will respin it. Cheers, -- Julien Grall
Re: [PATCH for-next v2 0/2] xen/arm: Mitigate straight-line speculation
On 16/03/2021 17:16, Bertrand Marquis wrote: Hi Julien, Hi Bertrand, On 16 Mar 2021, at 15:27, Julien Grall wrote: On 15/03/2021 13:32, Bertrand Marquis wrote: Hi Julien, Hi Bertrand, On 13 Mar 2021, at 16:06, Julien Grall wrote: From: Julien Grall Hi all, Last year, Arm released a whitepaper about a new category of speculation. (see [1] and [2]). In short, a processor may be able to speculate past some of the unconditional control flow instructions (e.g eret, smc, br). In some of the cases, the registers will contain values controlled by the guest. While there is no known gadget afterwards, we still want to prevent any leakage in the future. The mitigation is planned in two parts: 1) Arm provided patches for both GCC and LLVM to add speculation barrier and remove problematic code sequence. 2) Inspection of assembly code and call to higher level (e.g smc in our case). I still haven't looked at 1) and how to mitigate properly Arm32 (see patch #1) and SMC call. So this issue is not fully addressed. Note that the ERET instruction was already addressed as part of XSA-312. On my tests, this serie is breaking the arm64 build: | aarch64-poky-linux-ld --sysroot=/home/bermar01/Development/xen-dev/build/profile-fvp-base.prj/tmp/work/fvp_base-poky-linux/xen/4.15+git1-r0/recipe-sysroot -EL --fix-cortex-a53-843419 --fix-cortex-a53-843419 -r -o built_in.o memcpy.o memcmp.o memmove.o memset.o memchr.o clear_page.o bitops.o find_next_bit.o strchr.o strcmp.o strlen.o strncmp.o strnlen.o strrchr.o I can't see any build failure with the following GCC: 42sh> aarch64-linux-gnu-gcc aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. AFAICT, there is also no compilation issue reported by gitlab: https://gitlab.com/xen-project/patchew/xen/-/pipelines/269989894 What's the version of your compiler? Do you have steps to reproduce your setup? You need to have earlyprintk enabled I am using gcc 7.5.0: aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 one configuration triggering the issue is using the default .config with the following items added: CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS=y CONFIG_DEBUG_LOCK_PROFILE=y CONFIG_PERF_COUNTERS=y CONFIG_PERF_ARRAYS=y CONFIG_DEVICE_TREE_DEBUG=y CONFIG_DEBUG_TRACE=y CONFIG_EARLY_PRINTK_JUNO=y CONFIG_EARLY_UART_PL011=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_UART_BASE_ADDRESS=0x7ff8 CONFIG_EARLY_UART_PL011_BAUD_RATE=115200 CONFIG_EARLY_UART_INIT=y CONFIG_EARLY_PRINTK_INC="debug-pl011.inc” Thanks for providing the .config. I managed to reproduce it. So I removed "asm_defns.h" everywhere but forgot to include it in the "config.h" :/. This small change fixed the error: diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h index 51273b9db1fc..c7b77912013e 100644 --- a/xen/include/asm-arm/config.h +++ b/xen/include/asm-arm/config.h @@ -192,7 +192,7 @@ extern unsigned long frametable_virt_end; #define watchdog_enable() ((void)0) #if defined(__ASSEMBLY__) && !defined(__LINKER__) -#include +#include #include #endif Would you still be happy to review the series before I send a v3? Cheers, -- Julien Grall
[xen-unstable-coverity test] 160110: regressions - ALL FAIL
flight 160110 xen-unstable-coverity real [real] flight 160112 xen-unstable-coverity real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/160110/ http://logs.test-lab.xenproject.org/osstest/logs/160112/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd647 coverity-upload fail REGR. vs. 159907 version targeted for testing: xen 21657ad4f01a634beac570c64c0691e51b9cf366 baseline version: xen 1b47cc852fd130ed9ce274a0f1600a4a62949a2c Last test of basis 159907 2021-03-10 09:18:33 Z7 days Failing since160076 2021-03-14 09:18:27 Z3 days2 attempts Testing same since 160110 2021-03-17 09:20:42 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky Christian Lindig Dario Faggioli Doug Goldstein Elliott Mitchell Ian Jackson Igor Druzhinin Jan Beulich Julien Grall Roger Pau Monne Roger Pau Monné Wei Liu jobs: coverity-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 389 lines long.)
[qemu-mainline test] 160104: regressions - FAIL
flight 160104 qemu-mainline real [real] flight 160111 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/160104/ http://logs.test-lab.xenproject.org/osstest/logs/160111/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-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-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-armhf-armhf-xl-credit2 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-armhf-armhf-xl-credit2 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-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 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 test-armhf-armhf-libvirt 15 migrate-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 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 version targeted for testing: qemuu5b7f5586d182b0cafb1f8d558992a14763e2953e baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 209 days Failing since152659 2020-08-21 14:07:39 Z 207 days 403 attempts Testing same since 160104 2021-03-16 22:09:11 Z0 days1 attempts 453 people touched revis
[PATCH 2/2] Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"
This partially reverts commit 882213990d32fd224340a4533f6318dd152be4b2.
There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order
to correctly size the p2m. The generic memory hotplug option has
already been tied together with the Xen hotplug limit, so enabling
memory hotplug should already trigger a properly sized p2m on Xen PV.
Leave the check added to __set_phys_to_machine.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: xen-devel@lists.xenproject.org
---
arch/x86/include/asm/xen/page.h | 12
arch/x86/xen/p2m.c | 3 ---
arch/x86/xen/setup.c| 25 ++---
3 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 7068e4bb057d..1a162e559753 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -86,18 +86,6 @@ clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref
*unmap_ops,
}
#endif
-/*
- * The maximum amount of extra memory compared to the base size. The
- * main scaling factor is the size of struct page. At extreme ratios
- * of base:extra, all the base memory can be filled with page
- * structures for the extra memory, leaving no space for anything
- * else.
- *
- * 10x seems like a reasonable balance between scaling flexibility and
- * leaving a practically usable system.
- */
-#define XEN_EXTRA_MEM_RATIO(10)
-
/*
* Helper functions to write or read unsigned long values to/from
* memory, when the access may fault.
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index a33902d05e45..ac06ca32e9ef 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -416,9 +416,6 @@ void __init xen_vmalloc_p2m_tree(void)
xen_p2m_last_pfn = xen_max_p2m_pfn;
p2m_limit = (phys_addr_t)P2M_LIMIT * 1024 * 1024 * 1024 / PAGE_SIZE;
- if (!p2m_limit && IS_ENABLED(CONFIG_XEN_UNPOPULATED_ALLOC))
- p2m_limit = xen_start_info->nr_pages * XEN_EXTRA_MEM_RATIO;
-
vm.flags = VM_ALLOC;
vm.size = ALIGN(sizeof(unsigned long) * max(xen_max_p2m_pfn, p2m_limit),
PMD_SIZE * PMDS_PER_MID_PAGE);
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1a3b75652fa4..7eab14d56369 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -59,6 +59,18 @@ static struct {
} xen_remap_buf __initdata __aligned(PAGE_SIZE);
static unsigned long xen_remap_mfn __initdata = INVALID_P2M_ENTRY;
+/*
+ * The maximum amount of extra memory compared to the base size. The
+ * main scaling factor is the size of struct page. At extreme ratios
+ * of base:extra, all the base memory can be filled with page
+ * structures for the extra memory, leaving no space for anything
+ * else.
+ *
+ * 10x seems like a reasonable balance between scaling flexibility and
+ * leaving a practically usable system.
+ */
+#define EXTRA_MEM_RATIO(10)
+
static bool xen_512gb_limit __initdata = IS_ENABLED(CONFIG_XEN_512GB);
static void __init xen_parse_512gb(void)
@@ -778,13 +790,20 @@ char * __init xen_memory_setup(void)
extra_pages += max_pages - max_pfn;
/*
-* Clamp the amount of extra memory to a XEN_EXTRA_MEM_RATIO
-* factor the base size.
+* Clamp the amount of extra memory to a EXTRA_MEM_RATIO
+* factor the base size. On non-highmem systems, the base
+* size is the full initial memory allocation; on highmem it
+* is limited to the max size of lowmem, so that it doesn't
+* get completely filled.
*
* Make sure we have no memory above max_pages, as this area
* isn't handled by the p2m management.
+*
+* In principle there could be a problem in lowmem systems if
+* the initial memory is also very large with respect to
+* lowmem, but we won't try to deal with that here.
*/
- extra_pages = min3(XEN_EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
+ extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
extra_pages, max_pages - max_pfn);
i = 0;
addr = xen_e820_table.entries[0].addr;
--
2.30.1
[PATCH 1/2] xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on MEMORY_HOTPLUG
The Xen memory hotplug limit should depend on the memory hotplug
generic option, rather than the Xen balloon configuration. It's
possible to have a kernel with generic memory hotplug enabled, but
without Xen balloon enabled, at which point memory hotplug won't work
correctly due to the size limitation of the p2m.
Rename the option to XEN_MEMORY_HOTPLUG_LIMIT since it's no longer
tied to ballooning.
Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory")
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/p2m.c | 4 ++--
drivers/xen/Kconfig | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 17d80f751fcb..a33902d05e45 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -98,8 +98,8 @@ EXPORT_SYMBOL_GPL(xen_p2m_size);
unsigned long xen_max_p2m_pfn __read_mostly;
EXPORT_SYMBOL_GPL(xen_max_p2m_pfn);
-#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
-#define P2M_LIMIT CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
+#ifdef CONFIG_XEN_MEMORY_HOTPLUG_LIMIT
+#define P2M_LIMIT CONFIG_XEN_MEMORY_HOTPLUG_LIMIT
#else
#define P2M_LIMIT 0
#endif
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 41645fe6ad48..ea0efd290c37 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -50,11 +50,11 @@ config XEN_BALLOON_MEMORY_HOTPLUG
SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f
/sys$devpath/state ] && echo online > /sys$devpath/state'"
-config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
+config XEN_MEMORY_HOTPLUG_LIMIT
int "Hotplugged memory limit (in GiB) for a PV guest"
default 512
depends on XEN_HAVE_PVMMU
- depends on XEN_BALLOON_MEMORY_HOTPLUG
+ depends on MEMORY_HOTPLUG
help
Maxmium amount of memory (in GiB) that a PV guest can be
expanded to when using memory hotplug.
--
2.30.1
[PATCH 0/2] xen/x86: alternative fix for XSA-369
Hello, This is a proposal for an alternative fix for XSA-369 that instead of special casing XEN_UNPOPULATED_ALLOC to size the p2m relies on making XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on the generic MEMORY_HOTPLUG option rather than XEN_BALLOON_MEMORY_HOTPLUG. I think this is safer, as we don't want to be special casing any option that pulls in generic MEMORY_HOTPLUG without XEN_BALLOON_MEMORY_HOTPLUG. Without this we would also need to at least special case ZONE_DEVICE which also relies on MEMORY_HOTPLUG, and is what pulls the generic MEMORY_HOTPLUG option even when XEN_BALLOON_MEMORY_HOTPLUG is disabled with XEN_UNPOPULATED_ALLOC. Thanks, Roger. Roger Pau Monne (2): xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on MEMORY_HOTPLUG Revert "xen: fix p2m size in dom0 for disabled memory hotplug case" arch/x86/include/asm/xen/page.h | 12 arch/x86/xen/p2m.c | 7 ++- arch/x86/xen/setup.c| 25 ++--- drivers/xen/Kconfig | 4 ++-- 4 files changed, 26 insertions(+), 22 deletions(-) -- 2.30.1
Re: [PATCH 3/3] x86/msr: Fix Solaris and turbostat following XSA-351
On 16.03.2021 17:18, Andrew Cooper wrote: > @@ -284,6 +283,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t > *val) > goto gp_fault; > break; > > +case MSR_RAPL_POWER_UNIT: > +/* > + * This MSR is non-architectural. However, some versions of Solaris > + * blindly reads it without a #GP guard, and some versions of > + * turbostat crash after expecting a read of /proc/cpu/0/msr not to > + * fail. Read as zero on Intel hardware. > + */ > +if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ) > +goto gp_fault; > +*val = 0; > +break; > + > /* > * These MSRs are not enumerated in CPUID. They have been around > * since the Pentium 4, and implemented by other vendors. > I find all of this confusing, at best: I'd expect any entity reading this MSR to - when successful - go on and read further MSRs. I have a hard time seeing why those subsequent reads would be any less prone to being unguarded. In fact I went and looked at the turbostat sources. From its introduction the read of this MSR was done with - afaict - appropriate error handling. There are anomalies (do_rapl getting set prior to the probing of this MSR), but they look to not matter stability-wise as the respective MSR reads are similarly guarded. Were the observed crashes perhaps just in some private versions of the tool? If so, I guess saying so in the comment (or description) would be appropriate, but this still wouldn't invalidate the general aspect of my remark. On the good side the value of zero isn't entirely invalid, at least as far as defined bitfields of the MSR go. While looking around I also came across MSR_PLATFORM_ENERGY_COUNTER. This one has specific precautions in the SDM: "This MSR is valid only if both platform vendor hardware implementation and BIOS enablement support it. This MSR will read 0 if not valid." Isn't this a fairly strong suggestion that instead of raising #GP for it, we'd better return zero as well? Because of the remark, unlike for certain other MSRs, consumers have to expect zero possibly coming back. Jan
Re: [PATCH 2/3] x86/msr: Forward port XSA-351 changes from 4.14
On Tue, Mar 16, 2021 at 04:18:43PM +, Andrew Cooper wrote: > staging was not impacted by XSA-351 at the time of release, due to c/s > 322ec7c89f and 84e848fd7a which disallows read access by default. > > Forward port the XSA-351 changes to make the code structure consistent between > 4.14 and 4.15. > > This removes logspew for guests probing for the RAPL interface. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Wei Liu > CC: Boris Ostrovsky > CC: Ian Jackson > > Technically this breaks Solaris/turbostat insofar as you can no longer use > msr_relaxed to "fix" the guest. The subsequent patch will unbreak it > differently. > > For 4.15. Restoring behaviour closer to 4.14, and prereq for a bugfix needing > backporting. > --- > xen/arch/x86/msr.c | 19 +++ > xen/include/asm-x86/msr-index.h | 39 +++ > 2 files changed, 58 insertions(+) > > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index c3a988bd11..5927b6811b 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -188,6 +188,13 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t > *val) > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > +case MSR_RAPL_POWER_UNIT: > +case MSR_PKG_POWER_LIMIT ... MSR_PKG_POWER_INFO: > +case MSR_DRAM_POWER_LIMIT ... MSR_DRAM_POWER_INFO: > +case MSR_PP0_POWER_LIMIT ... MSR_PP0_POLICY: > +case MSR_PP1_POWER_LIMIT ... MSR_PP1_POLICY: > +case MSR_PLATFORM_ENERGY_COUNTER: > +case MSR_PLATFORM_POWER_LIMIT: > case MSR_U_CET: > case MSR_S_CET: > case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: > @@ -195,6 +202,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t > *val) > case MSR_AMD64_LWP_CBADDR: > case MSR_PPIN_CTL: > case MSR_PPIN: > +case MSR_F15H_CU_POWER ... MSR_F15H_CU_MAX_POWER: > +case MSR_AMD_RAPL_POWER_UNIT ... MSR_AMD_PKG_ENERGY_STATUS: > case MSR_AMD_PPIN_CTL: > case MSR_AMD_PPIN: > goto gp_fault; > @@ -412,6 +421,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t > val) > case MSR_INTEL_CORE_THREAD_COUNT: > case MSR_INTEL_PLATFORM_INFO: > case MSR_ARCH_CAPABILITIES: > +case MSR_IA32_PERF_STATUS: Should the MSR_IA32_PERF_STATUS addition maybe be part of the previous commit, as it's not related to the XSA-351 content? The rest LGTM: Reviewed-by: Roger Pau Monné I wonder whether we could squash this with 3/3 for staging commit, and then only backport 3/3 for older branches. But it's likely too much work just to prevent breaking msr_relaxed for Solaris for a single commit time span. Thanks, Roger.
Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"
On Tue, Mar 16, 2021 at 04:18:42PM +, Andrew Cooper wrote: > In hindsight, this was a poor move. Some of these MSRs require probing for, > causing unhelpful spew into xl dmesg, as well as spew from unit tests > explicitly checking behaviour. > > This restores behaviour close to that of Xen 4.14. I think it might be worth adding that guest access to those MSRs will now always trigger a #GP, even when msr_relaxed is used. This is however fine, as that's not a regression when compared to older Xen versions, where access to the MSRs also trigger a #GP unconditionally. I assume the wrmsr side is added so that when using msr_relaxed Xen also injects a #GP for writes to those MSRs, as it would do for reads? Thanks, Roger.
[ovmf test] 160106: all pass - PUSHED
flight 160106 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/160106/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 2e51b27fed31eb7b2a2cb4245806c8c7859207f7 baseline version: ovmf 66a31de7eeed62a7aa68fe0613a597a8bf08bc16 Last test of basis 160103 2021-03-16 21:09:41 Z0 days Testing same since 160106 2021-03-17 04:11:49 Z0 days1 attempts People who touched revisions under test: Chandramohan Akula jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 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/osstest/ovmf.git 66a31de7ee..2e51b27fed 2e51b27fed31eb7b2a2cb4245806c8c7859207f7 -> xen-tested-master
Re: [PATCH 3/3] x86/msr: Fix Solaris and turbostat following XSA-351
On Tue, Mar 16, 2021 at 09:20:10PM +, Andrew Cooper wrote: > On 16/03/2021 16:56, Roger Pau Monné wrote: > > On Tue, Mar 16, 2021 at 04:18:44PM +, Andrew Cooper wrote: > >> Signed-off-by: Andrew Cooper > > Thanks! > > > >> --- > >> CC: Jan Beulich > >> CC: Roger Pau Monné > >> CC: Wei Liu > >> CC: Boris Ostrovsky > >> CC: Ian Jackson > >> > >> For 4.15 This wants backporting to all security trees, as it is a fix to a > >> regression introduced in XSA-351. > >> > >> Also it means that users don't need msr_relaxed=1 to unbreak Solaris > >> guests, > >> which is a strict useability improvement. > >> --- > >> xen/arch/x86/msr.c | 13 - > >> 1 file changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > >> index 5927b6811b..a83a1d7fba 100644 > >> --- a/xen/arch/x86/msr.c > >> +++ b/xen/arch/x86/msr.c > >> @@ -188,7 +188,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t > >> *val) > >> case MSR_TSX_CTRL: > >> case MSR_MCU_OPT_CTRL: > >> case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > >> -case MSR_RAPL_POWER_UNIT: > >> case MSR_PKG_POWER_LIMIT ... MSR_PKG_POWER_INFO: > >> case MSR_DRAM_POWER_LIMIT ... MSR_DRAM_POWER_INFO: > >> case MSR_PP0_POWER_LIMIT ... MSR_PP0_POLICY: > >> @@ -284,6 +283,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, > >> uint64_t *val) > >> goto gp_fault; > >> break; > >> > >> +case MSR_RAPL_POWER_UNIT: > >> +/* > >> + * This MSR is non-architectural. However, some versions of > >> Solaris > >> + * blindly reads it without a #GP guard, and some versions of > >> + * turbostat crash after expecting a read of /proc/cpu/0/msr not > >> to > >> + * fail. Read as zero on Intel hardware. > >> + */ > >> +if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ) > >> +goto gp_fault; > > AFAICT from Linux usage this is Intel specific (not present in any of > > the clones). > > Indeed. > > > > >> +*val = 0; > >> +break; > > Do we also need to care about MSR_AMD_RAPL_POWER_UNIT (0xc0010299) for > > Solaris? > > AMD has a CPUID bit for this interface, 0x8007.EDX[14]. Right, I see now on the manual. I guess I was confused because I don't seem to see Linux checking this CPUID bit in: https://elixir.bootlin.com/linux/latest/source/arch/x86/events/rapl.c#L773 And instead it seems to attach the RAPL driver based on CPU model information. That's fine on Linux because accesses are using the _safe variants. The patch looks good to me, I wonder whether you should move the "users don't need msr_relaxed=1..." to the commit log, but that might be weird if the patch is backported, because it won't make sense for any older Xen version. Reviewed-by: Roger Pau Monné Thanks.
[PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd thread hangs, and as
a result the entire boot process.
For some reason this does not affect pvops based kernels. This is
most likely caused by the fact that unplugging happens very early
during boot.
Signed-off-by: Olaf Hering
---
hw/ide/piix.c| 5 +
include/hw/ide/pci.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index b9860e35a5..7f1998bf04 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -109,6 +109,9 @@ static void piix_ide_reset(DeviceState *dev)
uint8_t *pci_conf = pd->config;
int i;
+if (d->xen_unplug_done == true) {
+return;
+}
for (i = 0; i < 2; i++) {
ide_bus_reset(&d->bus[i]);
}
@@ -151,6 +154,7 @@ static void pci_piix_ide_realize(PCIDevice *dev, Error
**errp)
PCIIDEState *d = PCI_IDE(dev);
uint8_t *pci_conf = dev->config;
+d->xen_unplug_done = false;
pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
bmdma_setup_bar(d);
@@ -170,6 +174,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
BlockBackend *blk;
pci_ide = PCI_IDE(dev);
+pci_ide->xen_unplug_done = true;
for (i = aux ? 1 : 0; i < 4; i++) {
idebus = &pci_ide->bus[i / 2];
diff --git a/include/hw/ide/pci.h b/include/hw/ide/pci.h
index d8384e1c42..9e71cfec3b 100644
--- a/include/hw/ide/pci.h
+++ b/include/hw/ide/pci.h
@@ -50,6 +50,7 @@ struct PCIIDEState {
IDEBus bus[2];
BMDMAState bmdma[2];
uint32_t secondary; /* used only for cmd646 */
+bool xen_unplug_done;
MemoryRegion bmdma_bar;
MemoryRegion cmd_bar[2];
MemoryRegion data_bar[2];
