[xen-4.15-testing test] 173522: regressions - FAIL
flight 173522 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173522/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 172547 build-arm64-xsm 6 xen-buildfail REGR. vs. 172547 build-amd64-xsm 6 xen-buildfail REGR. vs. 172547 build-amd64 6 xen-buildfail REGR. vs. 172547 build-i386-xsm6 xen-buildfail REGR. vs. 172547 build-i3866 xen-buildfail REGR. vs. 172547 build-armhf 6 xen-buildfail REGR. vs. 172547 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1)
[xen-4.15-testing bisection] complete build-arm64
branch xen-4.15-testing xenbranch xen-4.15-testing job build-arm64 testid xen-build Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: c5215044578e88b401a1296ed6302df05c113c5f Bug not present: 45336d8f88725aec65ee177b1b09abf6eef1dc8d Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/173543/ commit c5215044578e88b401a1296ed6302df05c113c5f Author: Henry Wang Date: Tue Oct 11 15:10:16 2022 +0200 xen/arm, libxl: Implement XEN_DOMCTL_shadow_op for Arm This commit implements the `XEN_DOMCTL_shadow_op` support in Xen for Arm. The p2m pages pool size for xl guests is supposed to be determined by `XEN_DOMCTL_shadow_op`. Hence, this commit: - Introduces a function `p2m_domctl` and implements the subops `XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION` and `XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION` of `XEN_DOMCTL_shadow_op`. - Adds the `XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION` support in libxl. Therefore enabling the setting of shadow memory pool size when creating a guest from xl and getting shadow memory pool size from Xen. Note that the `XEN_DOMCTL_shadow_op` added in this commit is only a dummy op, and the functionality of setting/getting p2m memory pool size for xl guests will be added in following commits. This is part of CVE-2022-33747 / XSA-409. Signed-off-by: Henry Wang Reviewed-by: Stefano Stabellini master commit: cf2a68d2ffbc3ce95e01449d46180bddb10d24a0 master date: 2022-10-11 14:28:42 +0200 For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.15-testing/build-arm64.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.15-testing/build-arm64.xen-build --summary-out=tmp/173543.bisection-summary --basis-template=172547 --blessings=real,real-bisect,real-retry xen-4.15-testing build-arm64 xen-build Searching for failure / basis pass: 173498 fail [host=laxton1] / 172547 ok. Failure / basis pass flights: 173498 / 172547 Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest f80580f56b267c96f16f985dbf707b2f96947da4 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9690bb261d5fa09cb281e1fa124d93db7b84fda5 Basis pass 444260d45ec2a84e8f8c192b3539a3cd5591d009 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/osstest/ovmf.git#444260d45ec2a84e8f8c192b3539a3cd5591d009-f80580f56b267c96f16f985dbf707b2f96947da4 git://xenbits.xen.org/qemu-xen.git#6503bd6a1b5364ffd346a8a475e1eb91b9f756e5-6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 git://xenbits.xen.org/osstest/seabios.git#46de2eec93bffa0706e6229c0da2919763c8eb04-46de2eec93bffa0706e6229c0da2919763c8eb04 git://xenbits.xen.org/xen.git#9acedc3c58c31930737edbe212f2ccf437a0b757-9690bb261d5fa\ 09cb281e1fa124d93db7b84fda5 Loaded 10001 nodes in revision graph Searching for test results: 172547 pass 444260d45ec2a84e8f8c192b3539a3cd5591d009 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 173494 fail f80580f56b267c96f16f985dbf707b2f96947da4 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9690bb261d5fa09cb281e1fa124d93db7b84fda5 173499 pass 444260d45ec2a84e8f8c192b3539a3cd5591d009 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 173507 fail f80580f56b267c96f16f985dbf707b2f96947da4 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9690bb261d5fa09cb281e1fa124d93db7b84fda5 173508 pass e8a537d28d37c092bd03093064264071f2938ca8 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 173509 pass 7aa06237b856fd6f8187cc1715a3fe08ab4e98ed 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 173512 pass a670f12a741a9511d9cedc7257d3693567f8fc43 6503bd6a1b5364ffd346a8a475e1eb91b9f756e5 46de2eec93bffa0706e6229c0da2919763c8eb04 9acedc3c58c31930737edbe212f2ccf437a0b757 173513 pass f80580f56b267c96f16f985dbf707b2f96947da4
[xen-unstable-smoke test] 173506: regressions - FAIL
flight 173506 xen-unstable-smoke real [real] flight 173523 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/173506/ http://logs.test-lab.xenproject.org/osstest/logs/173523/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 14 guest-start fail REGR. vs. 173457 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass version targeted for testing: xen 87a20c98d9f0f422727fe9b4b9e22c2c43a5cd9c baseline version: xen 9029bc265cdf2bd63376dde9fdd91db4ce9c0586 Last test of basis 173457 2022-10-07 14:03:14 Z4 days Testing same since 173492 2022-10-11 13:01:50 Z0 days3 attempts People who touched revisions under test: Henry Wang Jan Beulich Julien Grall Roger Pau Monné Tim Deegan jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 427 lines long.)
[qemu-mainline test] 173497: regressions - FAIL
flight 173497 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/173497/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 173447 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 173447 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173447 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 173447 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173447 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 173447 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 173447 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173447 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 173447 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173447 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-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-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-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 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-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: qemuu42e1e350bffc8d4614e568a03380b2ec34a131bf baseline version: qemuuf1d33f55c47dfdaf8daacd618588ad3ae4c452d1 Last test of basis 173447 2022-10-06 14:38:42 Z5 days Testing same since 173497 2022-10-11 15:38:33 Z0 days1 attempts People who touched revisions under test: Daniel Henrique Barboza David Hildenbrand Janosch Frank Marc-André Lureau Stefan Hajnoczi jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
RE: [xen-4.15-testing test] 173498: regressions - FAIL
Hi all, > -Original Message- > Subject: [xen-4.15-testing test] 173498: regressions - FAIL > > flight 173498 xen-4.15-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/173498/ > > Regressions :-( I think these regressions are from the backporting happened yesterday, see below... > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-arm64 6 xen-buildfail REGR. vs. > 172547 > build-arm64-xsm 6 xen-buildfail REGR. vs. > 172547 > build-amd64 6 xen-buildfail REGR. vs. > 172547 > build-armhf 6 xen-buildfail REGR. vs. > 172547 ...The arm/arm64 regression is from the backporting of commit: xen/arm, libxl: Implement XEN_DOMCTL_shadow_op for Arm The issue is: In 4.16, commit 2107cc76db3a libxc: split xc_logdirty_control() from xc_shadow_control() changes the prototype of xc_shadow_control(), and hence the calling of xc_shadow_control() in 4.13, 4.14 and 4.15 does not match the calling of xc_shadow_control() in 4.16 and after. > build-i3866 xen-buildfail REGR. vs. > 172547 > build-i386-xsm6 xen-buildfail REGR. vs. > 172547 > build-amd64-xsm 6 xen-buildfail REGR. vs. > 172547 I think the x86 regression is from the backporting of commit: xen/gnttab: fix gnttab_acquire_resource() As the error message is: make[5]: Entering directory '/home/osstest/build.173498.build-amd64/xen/tools/tests/resource' test-resource.c: In function 'test_gnttab': test-resource.c:74:19: error: 'gnttab' undeclared (first use in this function) (void **), PROT_READ | PROT_WRITE, 0); ^~ Kind regards, Henry
[xen-4.13-testing test] 173495: regressions - FAIL
flight 173495 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173495/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 172549 build-arm64 6 xen-buildfail REGR. vs. 172549 test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10 fail REGR. vs. 172549 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 172549 build-armhf 6 xen-buildfail REGR. vs. 172549 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172549 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172549 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172549 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172549 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172549 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172549 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172549 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172549 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172549 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: xen 042de0843936b690acbc6dbcf57d26f6adccfc06 baseline version: xen bde3b13043e31fd757c44bcec182b0ff1fe36d22 Last test of basis 172549 2022-08-15 14:37:33 Z 57 days Testing same since 173495 2022-10-11 14:08:01 Z0 days1 attempts People who touched revisions under test: Henry Wang Jan Beulich Julien Grall Roger Pau Monné Tim Deegan jobs: build-amd64-xsm pass build-arm64-xsm fail build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 fail build-armhf fail build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked
[xen-4.15-testing test] 173498: regressions - FAIL
flight 173498 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173498/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 172547 build-arm64-xsm 6 xen-buildfail REGR. vs. 172547 build-amd64 6 xen-buildfail REGR. vs. 172547 build-armhf 6 xen-buildfail REGR. vs. 172547 build-i3866 xen-buildfail REGR. vs. 172547 build-i386-xsm6 xen-buildfail REGR. vs. 172547 build-amd64-xsm 6 xen-buildfail REGR. vs. 172547 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1)
[xen-4.14-testing test] 173496: regressions - FAIL
flight 173496 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173496/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-intel 20 guest-localmigrate/x10 fail REGR. vs. 172550 build-arm64-xsm 6 xen-buildfail REGR. vs. 172550 build-arm64 6 xen-buildfail REGR. vs. 172550 build-armhf 6 xen-buildfail REGR. vs. 172550 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172550 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172550 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172550 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172550 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172550 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172550 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172550 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172550 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172550 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass 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-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass version targeted for testing: xen 6e5608d1c50e0f91ed3226489d9591c70fa37c30 baseline version: xen 4ed063a71bf9ec291a1b71d0b7b36c0416ca544d Last test of basis 172550 2022-08-15 14:37:34 Z 57 days Testing same since 173496 2022-10-11 14:08:01 Z0 days1 attempts People who touched revisions under test: Henry Wang Jan Beulich Julien Grall Roger Pau Monné Tim Deegan jobs: build-amd64-xsm pass build-arm64-xsm fail build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 fail build-armhf fail build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt blocked
[xen-4.16-testing test] 173493: regressions - FAIL
flight 173493 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173493/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 172623 test-arm64-arm64-xl-seattle 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl-vhd 12 debian-di-installfail REGR. vs. 172623 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 172623 test-armhf-armhf-xl-multivcpu 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl-arndale 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl-credit2 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-xl-cubietruck 14 guest-startfail REGR. vs. 172623 test-armhf-armhf-libvirt 14 guest-start fail REGR. vs. 172623 test-armhf-armhf-libvirt-qcow2 12 debian-di-install fail REGR. vs. 172623 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 172623 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 172623 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 172623 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 172623 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 172623 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 172623 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 172623 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 172623 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 172623 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 172623 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen 1bce7fb1f702da4f7a749c6f1457ecb20bf74fca baseline version: xen cea5ed49bb5716698a11312a3f38bc8865cd1e67 Last test of basis 172623 2022-08-18 12:08:13 Z 54 days Testing same since 173493 2022-10-11 13:07:01 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Henry Wang Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Stefano Stabellini Tamas K Lengyel Tim Deegan jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf
Re: Issue: Networking performance in Xen VM on Arm64
On Tue, 11 Oct 2022, Leo Yan wrote: > > > The second question is how to mitigate the long latency when send data > > > from DomU. A possible solution is the Xen network forend driver copies > > > skb into mediate (bounce) buffer, just like what does in Xen net > > > backend driver with gnttab_batch_copy(), in this way the forend driver > > > doesn't need to wait for backend driver response and directly return > > > back. > > > > About this, I am not super familiar with drivers/net/xen-netfront.c but > > I take you are referring to xennet_tx_buf_gc? Is that the function that > > is causing xennet_start_xmit to wait? > > No. We can take the whole flow in xen-netfront.c as: > > xennet_start_xmit() > --> notify Xen Dom0 to process skb > <- Dom0 copies skb and notify back to DomU > xennet_tx_buf_gc() > softirq/NET_TX : __kfree_skb() Let me premise again that I am not an expert in PV netfront/netback. However, I think the above is only true if DomU and Dom0 are running on the same physical CPU. If you use sched=null as I suggested above, you'll get domU and dom0 running at the same time on different physical CPUs and the workflow doesn't work as described. It should be: CPU1: xennet_start_xmit() || CPU2: doing something else CPU1: notify Xen Dom0 to process skb || CPU2: receive notification CPU1: return from xennet_start_xmit() || CPU2: Dom0 copies skb CPU1: do something else || CPU2: notify back to DomU CPU1: receive irq, xennet_tx_buf_gc() || CPU2: do something else > > I didn't think that waiting for the backend is actually required. I > > mean, in theory xennet_start_xmit could return without calling > > xennet_tx_buf_gc, it is just an optimization. But I am not sure about > > this. > > The function xennet_start_xmit() will not wait and directly return > back, but if we review the whole flow we can see the skb is freed until > the softirq NET_TX. Is it an issue that the skb is not freed until later? Is that affecting the latency results? It shouldn't, right? What matters is when dom0 is getting those packets on the physical network interface and that happens before the skb is freed. I am just trying to figure out if we are focusing on the right problem. > In this whole flow, it needs DomU and Dom0 to work > together (includes two context switches) to process skb. There are not necessarily 2 context switches as things should run in parallel. > Here I mean the optimization is to allow Dom0 and DomU to work in > parallel. It could be something like blow, the key point is DomU > doesn't need to wait for Dom0's notification. I think it is already the case that domU doesn't need to wait for dom0's notification? It is true that domU is waiting for dom0's notification to free the skb but that shouldn't affect latency? >DomU | Dom0 > --+--- > xennet_start_xmit() | > copy skb in grant page| > notify Xen Dom0 | > | fetch skb from grant page > xennet_tx_buf_gc()| deliver skb to bridge > kfree_skb() |
[xen-unstable-smoke test] 173501: regressions - FAIL
flight 173501 xen-unstable-smoke real [real] flight 173503 xen-unstable-smoke real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/173501/ http://logs.test-lab.xenproject.org/osstest/logs/173503/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 14 guest-start fail REGR. vs. 173457 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass version targeted for testing: xen 87a20c98d9f0f422727fe9b4b9e22c2c43a5cd9c baseline version: xen 9029bc265cdf2bd63376dde9fdd91db4ce9c0586 Last test of basis 173457 2022-10-07 14:03:14 Z4 days Testing same since 173492 2022-10-11 13:01:50 Z0 days2 attempts People who touched revisions under test: Henry Wang Jan Beulich Julien Grall Roger Pau Monné Tim Deegan jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 427 lines long.)
[linux-linus test] 173491: regressions - FAIL
flight 173491 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/173491/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 173462 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173462 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173462 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-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-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 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 version targeted for testing: linux60bb8154d1d77042a5d43d335a68fdb202302cbe baseline version: linux9d84bb40bcb30a7fa16f33baa967aeb9953dda78 Last test of basis 173462 2022-10-07 18:41:45 Z4 days Failing since173470 2022-10-08 06:21:34 Z3 days 12 attempts Testing same since 173491 2022-10-11 11:42:23 Z0 days1 attempts 927 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl fail test-armhf-armhf-xl fail
Re: [PATCH v2] Use EfiACPIReclaimMemory for ESRT
On Tue, Oct 11, 2022 at 11:59:01AM +0200, Jan Beulich wrote: > On 11.10.2022 05:42, Demi Marie Obenour wrote: > > A previous patch tried to get Linux to use the ESRT under Xen if it is > > in memory of type EfiRuntimeServicesData. However, this turns out to be > > a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory > > winds up fragmenting both the EFI page tables and the direct map, > > Can this statement please be made describe Xen, not Linux? Aiui at least > the directmap aspect doesn't apply to Xen. Should it apply to Xen? My understanding is that Ard’s statements regarding mismatched attributes refer to any kernel, not just Linux. You would be in a better position to judge that, though. > > and > > that EfiACPIReclaimMemory is a much better choice for this purpose. > > I think the "better" wants explaining here, without requiring people to > follow ... Something like, “EfiACPIReclaimMemory is the correct type for configuration tables that are only used by the OS.”? > > Link: > > https://lists.xenproject.org/archives/html/xen-devel/2022-09/msg01365.html > > ... this link. Since the code change looks okay to me, I'd be okay to > replace the description with an adjusted one while committing. That is fine with me. > However, > if you expect the change to go into 4.17, you will want to resubmit > with Henry on Cc:, so he can consider giving the now necessary release- > ack. Will do, with your updated commit message. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
[xen-unstable-smoke test] 173492: regressions - FAIL
flight 173492 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/173492/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 173457 test-armhf-armhf-xl 14 guest-start fail REGR. vs. 173457 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass version targeted for testing: xen 87a20c98d9f0f422727fe9b4b9e22c2c43a5cd9c baseline version: xen 9029bc265cdf2bd63376dde9fdd91db4ce9c0586 Last test of basis 173457 2022-10-07 14:03:14 Z4 days Testing same since 173492 2022-10-11 13:01:50 Z0 days1 attempts People who touched revisions under test: Henry Wang Jan Beulich Julien Grall Roger Pau Monné Tim Deegan jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 427 lines long.)
[xen-4.15-testing test] 173494: regressions - FAIL
flight 173494 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/173494/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 172547 build-arm64-xsm 6 xen-buildfail REGR. vs. 172547 build-amd64 6 xen-buildfail REGR. vs. 172547 build-amd64-xsm 6 xen-buildfail REGR. vs. 172547 build-armhf 6 xen-buildfail REGR. vs. 172547 build-i386-xsm6 xen-buildfail REGR. vs. 172547 build-i3866 xen-buildfail REGR. vs. 172547 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1)
Re: [PATCH v3 1/5] x86/mwait-idle: add 'preferred-cstates' command line option
On Thu, Aug 18, 2022 at 03:03:33PM +0200, Jan Beulich wrote:
> From: Artem Bityutskiy
>
> On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
> exclusive - only one of them can be enabled. By default, 'intel_idle' driver
> enables C1 and disables C1E. However, some users prefer to use C1E instead of
> C1, because it saves more energy.
>
> This patch adds a new module parameter ('preferred_cstates') for enabling C1E
> and disabling C1. Here is the idea behind it.
>
> 1. This option has effect only for "mutually exclusive" C-states like C1 and
>C1E on SPR.
> 2. It does not have any effect on independent C-states, which do not require
>other C-states to be disabled (most states on most platforms as of today).
> 3. For mutually exclusive C-states, the 'intel_idle' driver always has a
>reasonable default, such as enabling C1 on SPR by default. On other
>platforms, the default may be different.
> 4. Users can override the default using the 'preferred_cstates' parameter.
> 5. The parameter accepts the preferred C-states bit-mask, similarly to the
>existing 'states_off' parameter.
> 6. This parameter is not limited to C1/C1E, and leaves room for supporting
>other mutually exclusive C-states, if they come in the future.
>
> Today 'intel_idle' can only be compiled-in, which means that on SPR, in order
> to disable C1 and enable C1E, users should boot with the following kernel
> argument: intel_idle.preferred_cstates=4
>
> Signed-off-by: Artem Bityutskiy
> Signed-off-by: Rafael J. Wysocki
> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> da0e58c038e6
>
> Enable C1E (if requested) not only on the BSP's socket / package. Alter
> command line option to fit our model, and extend it to also accept
> string form arguments.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Also accept string form arguments for command line option. Restore
> C1E-control related enum from Linux, despite our somewhat different
> use (and bigger code churn).
>
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1912,6 +1912,12 @@ paging controls access to usermode addre
> ### ple_window (Intel)
> > `= `
>
> +### preferred-cstates (x86)
> +> `= ( | List of ( C1 | C1E | C2 | ... )`
> +
> +This is a mask of C-states which are to be used preferably. This option is
> +applicable only on hardware were certain C-states are exclusive of one
> another.
> +
> ### psr (Intel)
> > `= List of ( cmt: | rmid_max: | cat: |
> cos_max: | cdp: )`
>
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -82,10 +82,29 @@ boolean_param("mwait-idle", opt_mwait_id
>
> static unsigned int mwait_substates;
>
> +/*
> + * Some platforms come with mutually exclusive C-states, so that if one is
> + * enabled, the other C-states must not be used. Example: C1 and C1E on
> + * Sapphire Rapids platform. This parameter allows for selecting the
> + * preferred C-states among the groups of mutually exclusive C-states - the
> + * selected C-states will be registered, the other C-states from the mutually
> + * exclusive group won't be registered. If the platform has no mutually
> + * exclusive C-states, this parameter has no effect.
> + */
> +static unsigned int __ro_after_init preferred_states_mask;
> +static char __initdata preferred_states[64];
> +string_param("preferred-cstates", preferred_states);
> +
> #define LAPIC_TIMER_ALWAYS_RELIABLE 0x
> /* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1. */
> static unsigned int lapic_timer_reliable_states = (1 << 1);
>
> +enum c1e_promotion {
> + C1E_PROMOTION_PRESERVE,
> + C1E_PROMOTION_ENABLE,
> + C1E_PROMOTION_DISABLE
> +};
> +
> struct idle_cpu {
> const struct cpuidle_state *state_table;
>
> @@ -95,7 +114,7 @@ struct idle_cpu {
>*/
> unsigned long auto_demotion_disable_flags;
> bool byt_auto_demotion_disable_flag;
> - bool disable_promotion_to_c1e;
> + enum c1e_promotion c1e_promotion;
> };
>
> static const struct idle_cpu *icpu;
> @@ -924,6 +943,15 @@ static void cf_check byt_auto_demotion_d
> wrmsrl(MSR_MC6_DEMOTION_POLICY_CONFIG, 0);
> }
>
> +static void cf_check c1e_promotion_enable(void *dummy)
> +{
> + uint64_t msr_bits;
> +
> + rdmsrl(MSR_IA32_POWER_CTL, msr_bits);
> + msr_bits |= 0x2;
> + wrmsrl(MSR_IA32_POWER_CTL, msr_bits);
> +}
> +
> static void cf_check c1e_promotion_disable(void *dummy)
> {
> u64 msr_bits;
> @@ -936,7 +964,7 @@ static void cf_check c1e_promotion_disab
> static const struct idle_cpu idle_cpu_nehalem = {
> .state_table = nehalem_cstates,
> .auto_demotion_disable_flags = NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE,
> - .disable_promotion_to_c1e = true,
> + .c1e_promotion = C1E_PROMOTION_DISABLE,
> };
>
> static const struct idle_cpu idle_cpu_atom = {
> @@ -954,64 +982,64 @@ static const struct idle_cpu
[PATCH for-4.17 1/4] amd/virt_ssbd: set SSBD at vCPU context switch
The current logic for AMD SSBD context switches it on every
vm{entry,exit} if the Xen and guest selections don't match. This is
expensive when not using SPEC_CTRL, and hence should be avoided as
much as possible.
When SSBD is not being set from SPEC_CTRL on AMD don't context switch
at vm{entry,exit} and instead only context switch SSBD when switching
vCPUs. This has the side effect of running Xen code with the guest
selection of SSBD, which renders the ssbd option without effect (in a
similar way to what already happens on Intel hardware).
This fixes an issue with running C code in a GIF=0 region, that's
problematic when using UBSAN or other instrumentation techniques.
As a result of no longer running the code to set SSBD in a GIF=0
region the locking of amd_set_legacy_ssbd() can be done using normal
spinlocks, and some more checks can be added to assure it works as
intended.
Finally it's also worth noticing that since the guest SSBD selection
is no longer set on vmentry the VIRT_SPEC_MSR handling needs to
propagate the value to the hardware as part of handling the wrmsr.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/amd.c | 50 ++
xen/arch/x86/hvm/svm/entry.S | 6 +---
xen/arch/x86/hvm/svm/svm.c | 45 --
xen/arch/x86/include/asm/amd.h | 2 +-
xen/arch/x86/msr.c | 7 +
5 files changed, 52 insertions(+), 58 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 98c52d0686..a1582e1cc9 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -742,7 +742,7 @@ void amd_init_ssbd(const struct cpuinfo_x86 *c)
}
static struct ssbd_ls_cfg {
-bool locked;
+spinlock_t lock;
unsigned int count;
} __cacheline_aligned *ssbd_ls_cfg;
static unsigned int __ro_after_init ssbd_max_cores;
@@ -776,46 +776,48 @@ bool __init amd_setup_legacy_ssbd(void)
if (!ssbd_ls_cfg)
return false;
- if (opt_ssbd)
- for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++)
- /* Set initial state, applies to any (hotplug) CPU. */
- ssbd_ls_cfg[i].count = boot_cpu_data.x86_num_siblings;
+ for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++) {
+ /* Set initial state, applies to any (hotplug) CPU. */
+ ssbd_ls_cfg[i].count = opt_ssbd ? boot_cpu_data.x86_num_siblings
+ : 0;
+ spin_lock_init(_ls_cfg[i].lock);
+ }
return true;
}
-/*
- * Executed from GIF==0 context: avoid using BUG/ASSERT or other functionality
- * that relies on exceptions as those are not expected to run in GIF==0
- * context.
- */
-void amd_set_legacy_ssbd(bool enable)
+static void core_set_legacy_ssbd(bool enable)
{
const struct cpuinfo_x86 *c = _cpu_data;
struct ssbd_ls_cfg *status;
+ unsigned long flags;
if ((c->x86 != 0x17 && c->x86 != 0x18) || c->x86_num_siblings <= 1) {
- set_legacy_ssbd(c, enable);
+ BUG_ON(!set_legacy_ssbd(c, enable));
return;
}
+ BUG_ON(c->phys_proc_id >= AMD_FAM17H_MAX_SOCKETS);
+ BUG_ON(c->cpu_core_id >= ssbd_max_cores);
status = _ls_cfg[c->phys_proc_id * ssbd_max_cores +
c->cpu_core_id];
- /*
-* Open code a very simple spinlock: this function is used with GIF==0
-* and different IF values, so would trigger the checklock detector.
-* Instead of trying to workaround the detector, use a very simple lock
-* implementation: it's better to reduce the amount of code executed
-* with GIF==0.
-*/
- while (test_and_set_bool(status->locked))
- cpu_relax();
+ spin_lock_irqsave(>lock, flags);
status->count += enable ? 1 : -1;
+ ASSERT(status->count <= c->x86_num_siblings);
if (enable ? status->count == 1 : !status->count)
- set_legacy_ssbd(c, enable);
- barrier();
- write_atomic(>locked, false);
+ BUG_ON(!set_legacy_ssbd(c, enable));
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+void amd_set_ssbd(bool enable)
+{
+ if ( cpu_has_virt_ssbd )
+ wrmsr(MSR_VIRT_SPEC_CTRL, enable ? SPEC_CTRL_SSBD : 0, 0);
+ else if ( amd_legacy_ssbd )
+ core_set_legacy_ssbd(enable);
+ else
+ ASSERT_UNREACHABLE();
}
/*
diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index a26589aa9a..94089e61bc 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -59,9 +59,6 @@ __UNLIKELY_END(nsvm_hap)
clgi
-ALTERNATIVE "", STR(call vmentry_virt_spec_ctrl), \
-X86_FEATURE_VIRT_SC_MSR_HVM
-
/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
/*
[PATCH 4/4] amd/virt_ssbd: add to max HVM policy when SSB_NO is available
Hardware that exposes SSB_NO can implement the setting of SSBD as a
no-op because it's not affected by SSB.
Take advantage of that and allow exposing VIRT_SPEC_CTRL.SSBD to guest
running on hadrware that has SSB_NO. Only set VIRT_SSBD on the max
policy though, as the feature is only intended to be used for
migration compatibility.
Signed-off-by: Roger Pau Monné
---
As there's no hardware with SSB_NO so far the patch is untested. Post
it for reference if there's hardware with the bit set.
---
xen/arch/x86/cpu/amd.c | 4 +++-
xen/arch/x86/cpuid.c | 7 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index cfeb8d1daf..74cfeffc29 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -814,7 +814,9 @@ void amd_set_ssbd(bool enable)
wrmsr(MSR_VIRT_SPEC_CTRL, enable ? SPEC_CTRL_SSBD : 0, 0);
else if ( amd_legacy_ssbd )
core_set_legacy_ssbd(enable);
- else
+ else if ( cpu_has_ssb_no ) {
+ /* Nothing to do. */
+ } else
ASSERT_UNREACHABLE();
}
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index acc2f606ce..e394dbe669 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -558,11 +558,16 @@ static void __init calculate_hvm_max_policy(void)
__clear_bit(X86_FEATURE_IBRSB, hvm_featureset);
__clear_bit(X86_FEATURE_IBRS, hvm_featureset);
}
-else if ( boot_cpu_has(X86_FEATURE_AMD_SSBD) )
+else if ( boot_cpu_has(X86_FEATURE_AMD_SSBD) ||
+ boot_cpu_has(X86_FEATURE_SSB_NO) )
/*
* If SPEC_CTRL.SSBD is available VIRT_SPEC_CTRL.SSBD can be exposed
* and implemented using the former. Expose in the max policy only as
* the preference is for guests to use SPEC_CTRL.SSBD if available.
+ *
+ * Allow VIRT_SSBD in the max policy if SSB_NO is exposed for migration
+ * compatibility reasons. If SSB_NO is present setting
+ * VIRT_SPEC_CTRL.SSBD is a no-op.
*/
__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
--
2.37.3
[PATCH for-4.17 0/4] amd/virt_ssbd: refactoring and cleanup
Hello,
The following series aims to remove running C code with GIF=0 on the AMD
vm{entry,exit} paths. As a result, the context switching of SSBD is
done when context switching vCPUs, and hence Xen code is run with the
guest selection of SSBD.
First patch is the one strictly needed, but patches 2 and 3 are also
desirable as cleanups and fixes to the documentation.
Patch 4 is untested, as there's no hardware with SSB_NO.
I tested on Naples and Milan CPUs (and migrating from Naples to Milan
correctly carrying the VIRT_SSBD bit), but I haven't tested on a
platform that exposes VIRT_SSBD itself. I think the path is
sufficiently similar to the legacy one.
Currently running a gitlab CI loop in order to check everything is OK.
Roger Pau Monne (4):
amd/virt_ssbd: set SSBD at vCPU context switch
amd: remove VIRT_SC_MSR_HVM synthetic feature
amd/ssbd: remove hypervisor SSBD selection
amd/virt_ssbd: add to max HVM policy when SSB_NO is available
docs/misc/xen-command-line.pandoc | 8 +---
xen/arch/x86/cpu/amd.c | 54 +-
xen/arch/x86/cpuid.c | 16 +---
xen/arch/x86/hvm/svm/entry.S | 6 +--
xen/arch/x86/hvm/svm/svm.c | 45 -
xen/arch/x86/include/asm/amd.h | 3 +-
xen/arch/x86/include/asm/cpufeatures.h | 2 +-
xen/arch/x86/include/asm/spec_ctrl.h | 1 -
xen/arch/x86/msr.c | 7
xen/arch/x86/spec_ctrl.c | 27 +++--
10 files changed, 73 insertions(+), 96 deletions(-)
--
2.37.3
[PATCH for-4.17 3/4] amd/ssbd: remove hypervisor SSBD selection
Like on Intel AMD guests are now capable of setting SSBD on their own,
either from SPEC_CTRL or from VIRT_SPEC_CTRL. As a result the
unconditional setting of SSBD from Xen in order to cope with the bit
not being exposed to guests is no longer needed.
Remove the Xen command line `spec-ctrl=ssbd` option and related
settings.
Signed-off-by: Roger Pau Monné
---
docs/misc/xen-command-line.pandoc| 8 +---
xen/arch/x86/cpu/amd.c | 11 ---
xen/arch/x86/include/asm/spec_ctrl.h | 1 -
xen/arch/x86/spec_ctrl.c | 19 +--
4 files changed, 6 insertions(+), 33 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 68389843b2..f2666b881a 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2297,7 +2297,7 @@ By default SSBD will be mitigated at runtime (i.e
`ssbd=runtime`).
### spec-ctrl (x86)
> `= List of [ , xen=, {pv,hvm}=,
> {msr-sc,rsb,md-clear,ibpb-entry}=|{pv,hvm}=,
-> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,psfd,
+> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,psfd,
> eager-fpu,l1d-flush,branch-harden,srb-lock,
> unpriv-mmio}= ]`
@@ -2365,12 +2365,6 @@ On hardware supporting STIBP (Single Thread Indirect
Branch Predictors), the
By default, Xen will use STIBP when IBRS is in use (IBRS implies STIBP), and
when hardware hints recommend using it as a blanket setting.
-On hardware supporting SSBD (Speculative Store Bypass Disable), the `ssbd=`
-option can be used to force or prevent Xen using the feature itself. On AMD
-hardware, this is a global option applied at boot, and not virtualised for
-guest use. On Intel hardware, the feature is virtualised for guests,
-independently of Xen's choice of setting.
-
On hardware supporting PSFD (Predictive Store Forwarding Disable), the `psfd=`
option can be used to force or prevent Xen using the feature itself. By
default, Xen will not use PSFD. PSFD is implied by SSBD, and SSBD is off by
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c28f2d5220..cfeb8d1daf 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -730,11 +730,12 @@ void amd_init_ssbd(const struct cpuinfo_x86 *c)
}
if (cpu_has_virt_ssbd) {
- wrmsrl(MSR_VIRT_SPEC_CTRL, opt_ssbd ? SPEC_CTRL_SSBD : 0);
+ /* Handled by context switch logic. */
return;
}
- if (!set_legacy_ssbd(c, opt_ssbd)) {
+ /* Test whether legacy SSBD is available. */
+ if (!set_legacy_ssbd(c, 0)) {
printk_once(XENLOG_ERR "No SSBD controls available\n");
if (amd_legacy_ssbd)
panic("CPU feature mismatch: no legacy SSBD\n");
@@ -777,12 +778,8 @@ bool __init amd_setup_legacy_ssbd(void)
if (!ssbd_ls_cfg)
return false;
- for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++) {
- /* Set initial state, applies to any (hotplug) CPU. */
- ssbd_ls_cfg[i].count = opt_ssbd ? boot_cpu_data.x86_num_siblings
- : 0;
+ for (i = 0; i < ssbd_max_cores * AMD_FAM17H_MAX_SOCKETS; i++)
spin_lock_init(_ls_cfg[i].lock);
- }
return true;
}
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h
b/xen/arch/x86/include/asm/spec_ctrl.h
index 9403b81dc7..ee5c7b8d54 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -66,7 +66,6 @@ void init_speculation_mitigations(void);
void spec_ctrl_init_domain(struct domain *d);
extern int8_t opt_ibpb_ctxt_switch;
-extern bool opt_ssbd;
extern int8_t opt_eager_fpu;
extern int8_t opt_l1d_flush;
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 0b94af6b86..dcee9795a5 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -56,7 +56,6 @@ static enum ind_thunk {
static int8_t __initdata opt_ibrs = -1;
int8_t __initdata opt_stibp = -1;
-bool __ro_after_init opt_ssbd;
int8_t __initdata opt_psfd = -1;
int8_t __ro_after_init opt_ibpb_ctxt_switch = -1;
@@ -126,7 +125,6 @@ static int __init cf_check parse_spec_ctrl(const char *s)
opt_thunk = THUNK_JMP;
opt_ibrs = 0;
opt_ibpb_ctxt_switch = false;
-opt_ssbd = false;
opt_l1d_flush = 0;
opt_branch_harden = false;
opt_srb_lock = 0;
@@ -263,8 +261,6 @@ static int __init cf_check parse_spec_ctrl(const char *s)
opt_ibrs = val;
else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
opt_stibp = val;
-else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
-opt_ssbd = val;
else if ( (val = parse_boolean("psfd", s, ss)) >= 0 )
opt_psfd = val;
@@ -471,7 +467,7 @@ static void __init
[PATCH for-4.17 2/4] amd: remove VIRT_SC_MSR_HVM synthetic feature
Since the VIRT_SPEC_CTRL.SSBD selection is no longer context switched
on vm{entry,exit} there's no need to use a synthetic feature bit for
it anymore.
Remove the bit and instead use a global variable.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/amd.c | 1 +
xen/arch/x86/cpuid.c | 9 +
xen/arch/x86/include/asm/amd.h | 1 +
xen/arch/x86/include/asm/cpufeatures.h | 2 +-
xen/arch/x86/spec_ctrl.c | 8
5 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index a1582e1cc9..c28f2d5220 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -49,6 +49,7 @@ boolean_param("allow_unsafe", opt_allow_unsafe);
/* Signal whether the ACPI C1E quirk is required. */
bool __read_mostly amd_acpi_c1e_quirk;
bool __ro_after_init amd_legacy_ssbd;
+bool __ro_after_init amd_virt_spec_ctrl;
static inline int rdmsr_amd_safe(unsigned int msr, unsigned int *lo,
unsigned int *hi)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 822f9ace10..acc2f606ce 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -543,9 +544,9 @@ static void __init calculate_hvm_max_policy(void)
/*
* VIRT_SSBD is exposed in the default policy as a result of
- * VIRT_SC_MSR_HVM being set, it also needs exposing in the max policy.
+ * amd_virt_spec_ctrl being set, it also needs exposing in the max policy.
*/
-if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
+if ( amd_virt_spec_ctrl )
__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
/*
@@ -606,9 +607,9 @@ static void __init calculate_hvm_def_policy(void)
/*
* Only expose VIRT_SSBD if AMD_SSBD is not available, and thus
- * VIRT_SC_MSR_HVM is set.
+ * amd_virt_spec_ctrl is set.
*/
-if ( boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) )
+if ( amd_virt_spec_ctrl )
__set_bit(X86_FEATURE_VIRT_SSBD, hvm_featureset);
sanitise_featureset(hvm_featureset);
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 81ed71710f..5c100784dd 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -152,6 +152,7 @@ extern bool amd_acpi_c1e_quirk;
void amd_check_disable_c1e(unsigned int port, u8 value);
extern bool amd_legacy_ssbd;
+extern bool amd_virt_spec_ctrl;
bool amd_setup_legacy_ssbd(void);
void amd_set_ssbd(bool enable);
diff --git a/xen/arch/x86/include/asm/cpufeatures.h
b/xen/arch/x86/include/asm/cpufeatures.h
index 3895de4faf..efd3a667ef 100644
--- a/xen/arch/x86/include/asm/cpufeatures.h
+++ b/xen/arch/x86/include/asm/cpufeatures.h
@@ -24,7 +24,7 @@ XEN_CPUFEATURE(APERFMPERF,X86_SYNTH( 8)) /*
APERFMPERF */
XEN_CPUFEATURE(MFENCE_RDTSC, X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC
*/
XEN_CPUFEATURE(XEN_SMEP, X86_SYNTH(10)) /* SMEP gets used by Xen
itself */
XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by Xen
itself */
-XEN_CPUFEATURE(VIRT_SC_MSR_HVM, X86_SYNTH(12)) /* MSR_VIRT_SPEC_CTRL exposed
to HVM */
+/* Bit 12 unused. */
XEN_CPUFEATURE(IND_THUNK_LFENCE, X86_SYNTH(13)) /* Use IND_THUNK_LFENCE */
XEN_CPUFEATURE(IND_THUNK_JMP, X86_SYNTH(14)) /* Use IND_THUNK_JMP */
XEN_CPUFEATURE(SC_NO_BRANCH_HARDEN, X86_SYNTH(15)) /* (Disable) Conditional
branch hardening */
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 4e53056624..0b94af6b86 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -514,12 +514,12 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
(boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ||
boot_cpu_has(X86_FEATURE_IBPB_ENTRY_HVM) ||
-boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM) ||
+amd_virt_spec_ctrl ||
opt_eager_fpu || opt_md_clear_hvm) ? "" : "
None",
boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ? " MSR_SPEC_CTRL" : "",
(boot_cpu_has(X86_FEATURE_SC_MSR_HVM) ||
-boot_cpu_has(X86_FEATURE_VIRT_SC_MSR_HVM)) ? " MSR_VIRT_SPEC_CTRL"
- : "",
+amd_virt_spec_ctrl) ? " MSR_VIRT_SPEC_CTRL"
+ : "",
boot_cpu_has(X86_FEATURE_SC_RSB_HVM) ? " RSB" : "",
opt_eager_fpu ? " EAGER_FPU" : "",
opt_md_clear_hvm ? " MD_CLEAR" : "",
@@ -1247,7 +1247,7 @@ void __init init_speculation_mitigations(void)
/* Support VIRT_SPEC_CTRL.SSBD if AMD_SSBD is not available. */
if ( opt_msr_sc_hvm && !cpu_has_amd_ssbd &&
RE: [PATCH 2/2] acpi: Add TPM2 interface definition.
Hi,
Are any further changes needed to upstream this patch series?
Cheers,
-jenny
-Original Message-
From: Jennifer Herbert
Sent: 15 September 2022 21:40
To: jbeul...@suse.com; Andrew Cooper ; w...@xen.org;
Roger Pau Monne
Cc: xen-devel@lists.xenproject.org; Jennifer Herbert
Subject: [PATCH 2/2] acpi: Add TPM2 interface definition.
This patch introduces an optional TPM 2 interface definition to the ACPI table,
which is to be used as part of a vTPM 2 implementation.
Signed-off-by: Jennifer Herbert
---
tools/firmware/hvmloader/config.h | 1 +
tools/firmware/hvmloader/util.c | 7 ++
tools/libacpi/Makefile| 2 +-
tools/libacpi/acpi2_0.h | 26 ++
tools/libacpi/build.c | 35 ++
tools/libacpi/libacpi.h | 1 +
tools/libacpi/ssdt_tpm2.asl | 36 +++
7 files changed, 107 insertions(+), 1 deletion(-) create mode 100644
tools/libacpi/ssdt_tpm2.asl
diff --git a/tools/firmware/hvmloader/config.h
b/tools/firmware/hvmloader/config.h
index c82adf6dc5..4dec7195f0 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -56,6 +56,7 @@ extern uint8_t ioapic_version;
#define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+#define ACPI_CRB_HDR_ADDRESS 0xFED40034UL
extern uint32_t pci_mem_start;
extern const uint32_t pci_mem_end;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 87bc2d677f..6e5d3609b9 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -1009,6 +1009,13 @@ void hvmloader_acpi_build_tables(struct acpi_config
*config,
config->table_flags |= ACPI_HAS_TPM;
config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
break;
+case 2:
+config->table_flags |= ACPI_HAS_TPM;
+config->crb_hdr = (uint16_t *)ACPI_CRB_HDR_ADDRESS;
+
+mem_hole_populate_ram(TPM_LOG_AREA_ADDRESS >> PAGE_SHIFT, TPM_LOG_SIZE
>> PAGE_SHIFT);
+memset((void *)(TPM_LOG_AREA_ADDRESS), 0, TPM_LOG_SIZE);
+break;
}
config->numa.nr_vmemranges = nr_vmemranges; diff --git
a/tools/libacpi/Makefile b/tools/libacpi/Makefile index 60860eaa00..125f29fb54
100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -25,7 +25,7 @@ C_SRC-$(CONFIG_X86) = dsdt_anycpu.c dsdt_15cpu.c
dsdt_anycpu_qemu_xen.c dsdt_pvh
C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c DSDT_FILES ?= $(C_SRC-y) C_SRC =
$(addprefix $(ACPI_BUILD_DIR)/, $(DSDT_FILES)) -H_SRC = $(addprefix
$(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
ssdt_laptop_slate.h)
+H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h
+ssdt_tpm.h ssdt_tpm2.h ssdt_laptop_slate.h)
MKDSDT_CFLAGS-$(CONFIG_ARM_64) = -DCONFIG_ARM_64
MKDSDT_CFLAGS-$(CONFIG_X86) = -DCONFIG_X86 diff --git
a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h index
2619ba32db..f4eb4d715b 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -121,6 +121,30 @@ struct acpi_20_tcpa { }; #define ACPI_2_0_TCPA_LAML_SIZE
(64*1024)
+/*
+ * TPM2
+ */
+struct acpi_20_tpm2 {
+struct acpi_header header;
+uint16_t platform_class;
+uint16_t reserved;
+uint64_t control_area_address;
+uint32_t start_method;
+uint8_t start_method_params[12];
+uint32_t log_area_minimum_length;
+uint64_t log_area_start_address;
+};
+#define TPM2_ACPI_CLASS_CLIENT 0
+#define TPM2_START_METHOD_CRB 7
+
+#define TPM_CRB_ADDR_BASE 0xFED4
+#define TPM_CRB_ADDR_CTRL (TPM_CRB_ADDR_BASE + 0x40)
+
+#define TPM_LOG_AREA_ADDRESS0xFED5
+
+#define TPM_LOG_AREA_MINIMUM_SIZE (64 << 10)
+#define TPM_LOG_SIZE(64 << 10)
+
/*
* Fixed ACPI Description Table Structure (FADT) in ACPI 1.0.
*/
@@ -431,6 +455,7 @@ struct acpi_20_slit { #define ACPI_2_0_RSDT_SIGNATURE
ASCII32('R','S','D','T') #define ACPI_2_0_XSDT_SIGNATURE
ASCII32('X','S','D','T') #define ACPI_2_0_TCPA_SIGNATURE
ASCII32('T','C','P','A')
+#define ACPI_2_0_TPM2_SIGNATURE ASCII32('T','P','M','2')
#define ACPI_2_0_HPET_SIGNATURE ASCII32('H','P','E','T') #define
ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T') #define
ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T') @@ -444,6 +469,7 @@ struct
acpi_20_slit { #define ACPI_2_0_RSDT_REVISION 0x01 #define
ACPI_2_0_XSDT_REVISION 0x01 #define ACPI_2_0_TCPA_REVISION 0x02
+#define ACPI_2_0_TPM2_REVISION 0x04
#define ACPI_2_0_HPET_REVISION 0x01
#define ACPI_2_0_WAET_REVISION 0x01
#define ACPI_1_0_FADT_REVISION 0x01
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c index
d313ccd8cf..d4f25a68d2 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -19,6 +19,7 @@
#include "ssdt_s3.h"
#include "ssdt_s4.h"
#include "ssdt_tpm.h"
+#include "ssdt_tpm2.h"
#include "ssdt_pm.h"
#include
Re: [PATCH V7 2/2] xen/gnttab: Store frame GFN in struct page_info on Arm
On 11.10.2022 15:33, Julien Grall wrote: > Hi Jan, > > On 11/10/2022 14:28, Jan Beulich wrote: >> On 11.10.2022 15:01, Julien Grall wrote: >>> Hi Jan, >>> >>> On 11/10/2022 12:59, Jan Beulich wrote: On 16.07.2022 16:56, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Rework Arm implementation to store grant table frame GFN > in struct page_info directly instead of keeping it in > standalone status/shared arrays. This patch is based on > the assumption that a grant table page is a xenheap page. > > To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space > to hold 52-bit/28-bit + extra bit value respectively. In order > to not grow the size of struct page_info borrow the required > amount of bits from type_info's count portion which current > context won't suffer (currently only 1 bit is used on Arm). I'm afraid this isn't true: There's no requirement for a guest to pass all different GFNs to VCPUOP_register_vcpu_info, yet map_vcpu_info() tries to obtain a reference for every vCPU. >>> >>> AFAIU, this would be a reference of the **count_info** not **type_info** >>> (which BTW will never be incremented on Arm because we have no type >>> support). >> >> I should have said "obtain a writable type reference". > > Thanks for the clarification. > >> >>> The commit message is only referring to the 'type_info's count'. So... >>> With my adding of GFN (really gaddr) based registration of the runstate area (already looking towards 4.18) the maximum possible count is to further grow. >>> >>> ... I am not sure which problem you are referring too. >> >> Wow - a mere stub (but not inline) function to make the build happy. >> Then why is the description talking about one bit that's needed on >> Arm? > > Because share_xen_page_with_guest() will always set the type info's > count to 1. > > TBH I don't exactly know why we set it. I always assumed this was a > requirement for the common code but never checked. I don't think there is any such requirement. In fact there are only very few uses of type_info in common code. By also setting PGT_count_mask to zero you could actually have the compiler eliminate some dead code ... Jan
Re: [PATCH V7 2/2] xen/gnttab: Store frame GFN in struct page_info on Arm
Hi Jan, On 11/10/2022 14:28, Jan Beulich wrote: On 11.10.2022 15:01, Julien Grall wrote: Hi Jan, On 11/10/2022 12:59, Jan Beulich wrote: On 16.07.2022 16:56, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Rework Arm implementation to store grant table frame GFN in struct page_info directly instead of keeping it in standalone status/shared arrays. This patch is based on the assumption that a grant table page is a xenheap page. To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space to hold 52-bit/28-bit + extra bit value respectively. In order to not grow the size of struct page_info borrow the required amount of bits from type_info's count portion which current context won't suffer (currently only 1 bit is used on Arm). I'm afraid this isn't true: There's no requirement for a guest to pass all different GFNs to VCPUOP_register_vcpu_info, yet map_vcpu_info() tries to obtain a reference for every vCPU. AFAIU, this would be a reference of the **count_info** not **type_info** (which BTW will never be incremented on Arm because we have no type support). I should have said "obtain a writable type reference". Thanks for the clarification. The commit message is only referring to the 'type_info's count'. So... With my adding of GFN (really gaddr) based registration of the runstate area (already looking towards 4.18) the maximum possible count is to further grow. ... I am not sure which problem you are referring too. Wow - a mere stub (but not inline) function to make the build happy. Then why is the description talking about one bit that's needed on Arm? Because share_xen_page_with_guest() will always set the type info's count to 1. TBH I don't exactly know why we set it. I always assumed this was a requirement for the common code but never checked. Cheers, -- Julien Grall
Re: [PATCH V7 2/2] xen/gnttab: Store frame GFN in struct page_info on Arm
On 11.10.2022 15:01, Julien Grall wrote: > Hi Jan, > > On 11/10/2022 12:59, Jan Beulich wrote: >> On 16.07.2022 16:56, Oleksandr Tyshchenko wrote: >>> From: Oleksandr Tyshchenko >>> >>> Rework Arm implementation to store grant table frame GFN >>> in struct page_info directly instead of keeping it in >>> standalone status/shared arrays. This patch is based on >>> the assumption that a grant table page is a xenheap page. >>> >>> To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space >>> to hold 52-bit/28-bit + extra bit value respectively. In order >>> to not grow the size of struct page_info borrow the required >>> amount of bits from type_info's count portion which current >>> context won't suffer (currently only 1 bit is used on Arm). >> >> I'm afraid this isn't true: There's no requirement for a guest to pass >> all different GFNs to VCPUOP_register_vcpu_info, yet map_vcpu_info() >> tries to obtain a reference for every vCPU. > > AFAIU, this would be a reference of the **count_info** not **type_info** > (which BTW will never be incremented on Arm because we have no type > support). I should have said "obtain a writable type reference". > The commit message is only referring to the 'type_info's count'. So... > >> With my adding of GFN >> (really gaddr) based registration of the runstate area (already >> looking towards 4.18) the maximum possible count is to further grow. > > ... I am not sure which problem you are referring too. Wow - a mere stub (but not inline) function to make the build happy. Then why is the description talking about one bit that's needed on Arm? Jan
preparations for 4.15.4
All, the release is due around the end of the month. Since 4.15's general support period has ended earlier this month, this is going to be the final XenProject-coordinated release from this branch. Please point out backports you find missing from the respective staging branch, but which you consider relevant. Jan
Re: [PATCH V7 2/2] xen/gnttab: Store frame GFN in struct page_info on Arm
Hi Jan, On 11/10/2022 12:59, Jan Beulich wrote: On 16.07.2022 16:56, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Rework Arm implementation to store grant table frame GFN in struct page_info directly instead of keeping it in standalone status/shared arrays. This patch is based on the assumption that a grant table page is a xenheap page. To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space to hold 52-bit/28-bit + extra bit value respectively. In order to not grow the size of struct page_info borrow the required amount of bits from type_info's count portion which current context won't suffer (currently only 1 bit is used on Arm). I'm afraid this isn't true: There's no requirement for a guest to pass all different GFNs to VCPUOP_register_vcpu_info, yet map_vcpu_info() tries to obtain a reference for every vCPU. AFAIU, this would be a reference of the **count_info** not **type_info** (which BTW will never be incremented on Arm because we have no type support). The commit message is only referring to the 'type_info's count'. So... With my adding of GFN (really gaddr) based registration of the runstate area (already looking towards 4.18) the maximum possible count is to further grow. ... I am not sure which problem you are referring too. Cheers, -- Julien Grall
Re: [PATCH v1 0/4] Yocto Gitlab CI
Hi Stefano, > On 8 Oct 2022, at 00:36, Stefano Stabellini wrote: > > On Wed, 24 Aug 2022, Bertrand Marquis wrote: >> This patch series is a first attempt to check if we could use Yocto in >> gitlab ci to build and run xen on qemu for arm, arm64 and x86. >> >> The first patch is making sure build-yocto.sh is not catched by >> gitignore. >> >> The second patch is creating a container with all elements required to >> build Yocto, a checkout of the yocto layers required and an helper >> script to build and run xen on qemu with yocto. >> >> The third patch is creating containers with a first build of yocto done >> so that susbsequent build with those containers would only rebuild what >> was changed and take the rest from the cache. >> >> The fourth patch is adding a way to easily clean locally created >> containers. >> >> This is is mainly for discussion and sharing as there are still some >> issues/problem to solve: >> - building the qemu* containers can take several hours depending on the >> network bandwith and computing power of the machine where those are >> created >> - produced containers containing the cache have a size between 8 and >> 12GB depending on the architecture. We might need to store the build >> cache somewhere else to reduce the size. If we choose to have one >> single image, the needed size is around 20GB and we need up to 40GB >> during the build, which is why I splitted them. >> - during the build and run, we use a bit more then 20GB of disk which is >> over the allowed size in gitlab >> > > So I tried to build one of the build containers on my x86 workstation > with the following: > > make yocto/kirkstone-qemuarm64 > > but I get an error from the build: > > 21:30:20 build qemuarm64: Error > 22:00:38 run qemuarm64: Error > 22:00:41 Build Complete (2 errors) > The command '/bin/sh -c /home/$USER_NAME/bin/build-yocto.sh $target' > returned a non-zero code: 2 > > Anyone else is having a better luck than me? > I did a new run and everything went ok on my side. I will push a v2 of the serie to dump more logs when an error is happening. Cheers Bertrand > > I don't think it is a problem if it takes a long time to build the build > containers because they are not built often and they are not built as > part of the gitlab-ci runs. > > The issue could be the resulting container size. I wasn't aware of a > limit in gitlab -- I would like to try if there is a way around the > limit (either by changing a setting, or potentially switching to a > premium account.) However I need to be able to complete a container > build first :-) > > How did you find out about the 20 GB limit? I couldn't find it in the > docs. The only info I could find states that there is no hard limit on > registry.gitlab.com. > > Cheers, > > Stefano
RE: [4.17?] Re: [PATCH] x86emul: respect NSCB
Hi Andrew, > -Original Message- > From: Andrew Cooper > > (If it will not cause too much time of digging, would you mind adding a > > "Fixes:" tag pointing to the original commit that missing this > > ` vcpu_has_nscb()` check when you do the committing? I think this would > > help to identify this patch as a bugfix so it is more reasonable to commit > > this patch in current phase. But if too much trouble or you think this is > > not really a fix then just ignore my comment...) > > There isn't really an appropriate Fixes tag. > > This CPUID bit is one I managed to get AMD to retroactively add to fix > an enumeration problem they had no anticipated when making a change in > Zen2. > > i.e. the CPUID bit did not exist at the point at which the code, > modified in this patch, was written. Oh, thanks for the clarification! Then please just ignore my comments, sorry for the noise. Kind regards, Henry > > ~Andrew
Re: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE
On Fri, Oct 7, 2022 at 9:12 PM Henry Wang wrote: > > Hi Andrew and Jason, > > > -Original Message- > > From: Andrew Cooper > > Subject: Re: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE > > > > On 07/10/2022 20:31, Jason Andryuk wrote: > > > I observed this ASSERT_UNREACHABLE in partner_rings_remove > > consistently > > > trip. It was in OpenXT with the viptables patch applied. > > > > > > dom10 shuts down. > > > dom7 is REJECTED sending to dom10. > > > dom7 shuts down and this ASSERT trips for dom10. dom7 used a wildcard ring, and dom10 connected to it with a (driver level) stream socket. > > > The argo_send_info has a domid, but there is no refcount taken on > > > the domain. Therefore it's not appropriate to ASSERT that the domain > > > can be looked up via domid. Replace with a debug message. > > > > > > Signed-off-by: Jason Andryuk > > > > We're into the 4.17 release process now. A bugfix like this obviously > > should be considered, but will need approval from the release manager. > > CC Henry. Thanks, Andrew. > Andrew: Thanks for the information! > > Jason: Would you mind adding a "Fixes:" tag following the rule described > in [1]? Thanks very much! With this tag and proper review/ack from > maintainers: Of course. It would be: Fixes: 82a817307c5b "argo: init, destroy and soft-reset, with enable command line opt" > Release-acked-by: Henry Wang Thanks, Henry. We'll see what feedback Christopher provides. Regards, Jason
Xen Security Advisory 413 v2 (CVE-2022-33749) - XAPI open file limit DoS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33749 / XSA-413 version 2 XAPI open file limit DoS UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = It is possible for an unauthenticated client on the network to cause XAPI to hit its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted) clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors. IMPACT == An attacker is capable of blocking connections to the XAPI HTTP interface, and also interrupt ongoing operations, causing a XAPI toolstack Denial of Service. Such DoS would also affect any guests that require toolstack actions. VULNERABLE SYSTEMS == All versions of XAPI are vulnerable. Systems which are not using the XAPI toolstack are not vulnerable. MITIGATION == Not exposing to untrusted clients the network interface XAPI is listening on will prevent the issue. RESOLUTION == Applying the attached patches resolves this issue. xsa413/xsa413-*.patch Xapi master $ sha256sum xsa413*/* 63f72af7a92944700318add5cc200160ff7f834b6d304dd22441fa2de74c7b83 xsa413/xsa413-1.patch 6fbcbfb1915ebc4a726374d94e050406d8f1d52c3cb9afc06bcf7cec9e5a19c8 xsa413/xsa413-2.patch c41de04ff2b63756e693c6c75ec4d7206a88db06c1da0b263c9d0644da90ef8b xsa413/xsa413-3.patch 6ee2dc09f6c5f64ce9627e9b4e314237817f7c0c2eebe30a2c83709d1faf0050 xsa413/xsa413-4.patch 360a5099ece45118488706acd76b6da3ca8e6f107cee24586dbf6ec7f5858aeb xsa413/xsa413-5.patch cc79e086affcfd784ab8cd38e1d0acd6adb241c24141f3409161e417cc314b28 xsa413/xsa413-6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNFTAEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZmIMH/RBAGOrAi8NI7BBeGHwMW7WqyMfT6mTVUFkb2z9z ZFtvPFvim5AobCUpAKFtUAWpSQoUEEPyTO83C2VDe9jQC37mRo/qAduX7wj8oaJv Dq+QFECP95bsfmu0SwKYL7ZW+3lLxDVwtp88z4P/H/U0VYqG+bNrR569znBbn0wL p7EKQG5A4PS0nLg8ehnxjwuKCn0dCgUIZibh3AIMOUDTFY/apVeDFbX7bKIoQgLV /0B18MevryxqSRe3QpL2WW/kRGLLKF7i5SA7nAbOPMzPWHOLNDZb+b+Hq7/eYwzI a2+6yUcBkWAqyi9M3fXkhslySA/WqLdPXBIkd47zZS9rIuU= =Ih6z -END PGP SIGNATURE- xsa413/xsa413-1.patch Description: Binary data xsa413/xsa413-2.patch Description: Binary data xsa413/xsa413-3.patch Description: Binary data xsa413/xsa413-4.patch Description: Binary data xsa413/xsa413-5.patch Description: Binary data xsa413/xsa413-6.patch Description: Binary data
Xen Security Advisory 411 v3 (CVE-2022-33748) - lock order inversion in transitive grant copy handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2022-33748 / XSA-411 version 3 lock order inversion in transitive grant copy handling UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = As part of XSA-226 a missing cleanup call was inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a result two cooperating guests granting each other transitive grants can cause locks to be acquired nested within one another, but in respectively opposite order. With suitable timing between the involved grant copy operations this may result in the locking up of a CPU. IMPACT == Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS == Xen versions 4.0 and newer are vulnerable. Xen versions 3.4 and older are not vulnerable. Only guests with access to transitive grants can exploit the vulnerability. In particular, this means that: * ARM systems which have taken the XSA-268 fix are not vulnerable, as Grant Table v2 was disabled for other security reasons. * All systems with the XSA-226 fixes, and booted with `gnttab=max-ver:1` or `gnttab=no-transitive` are not vulnerable. * From Xen 4.16, the maximum grant table version can be controlled on a per-domain basis. For the xl toolstack, the vulnerability does not manifest if either: 1) Every guest has `max_grant_version=1` in their configuration file, or 2) The global xl.conf has `max_grant_version=1`, and no guests have the default overridden by selecting `max_grant_version=2`. Only multiple cooperating guests can exploit the vulnerability. MITIGATION == Disallowing the use of transitive grants either via the `gnttab=no-transitive` Xen command line option, or by disabling grant interface version 2 altogether via the `gnttab=max-ver:1` Xen command line option or the xl controls as mentioned above will avoid the vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa411.patch xen-unstable - Xen 4.15.x xsa411-4.14.patch Xen 4.14.x - 4.13.x $ sha256sum xsa411* 0802e2e4e9d03c82429a710bbb783cee2fded52d29b1d969b97c680d30c3ac57 xsa411.patch 8473f2ee34562298c5174f0a5b3c64c561a945333aab675845093ad23250d1cf xsa411-4.14.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. HOWEVER, deployment of the mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because it is a guest visible change which will draw attention to the issue. -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNFTAAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZPsQH/1JCqscbx49QygGVEnq43C97HQpcoZcUNJGwGjBJ Li0SXejxd3iWsYsFlMAgmacHIjevEGv318JJLSM21hBULGe85cc6QatpWS0VWrBc tQVbDIgqNRv42gJCtf1dLF0TnlTZ6p3wiqfsxEYBn1zlEhe2ZEMpY8an4707O32d nQ90JFh44QJXx6HMZD3pEw2g1+4pMDu9yDUp/Yc3YmxYnXmPW6KE7iMmGkLLGigI GfiTI4FA/BDVIZkjPErwG7pyXmp2sdtVkv5o/cg7YTOrLzeBmegdyUvzuXkizJ2F PQnc1rgS/vXPkC62cy6fmLkeAf0dQhq6KBuxW3N8s2fXRXk= =/bRo -END PGP SIGNATURE- xsa411.patch Description: Binary data xsa411-4.14.patch Description: Binary data
Re: Issue: Networking performance in Xen VM on Arm64
Hi Stefano, On Mon, Oct 10, 2022 at 04:50:46PM -0700, Stefano Stabellini wrote: > +Xen/Linux maintainers Thanks for reviewing. [...] > > Throughput result: > > > > Profile netperf (Mbits/sec)ddsperf (Mbits/sec) > > Xen-Dom0939.41 > 620 > > Xen-DomU107.73 4~12 > > > > Latency result: > > > > Profile ddsperf's max ping/pong latency (us) > > Xen-Dom0200 ~ 1400 > > Xen-DomU> 60,000 > > > > ## Analysis > > > > The critical thing for the performance is low level network driver if > > it uses synchronous or asynchronous mode for skb transferring. > > > > When we transfer data from my x86 machine to Xen DomU, the data flow is: > > > > bridge -> xenif (Xen network backend driver) => Dom0 > > `> xennet driver (Xen net forend driver) => DomU > > > > In this flow, Xen network backend driver (in Dom0) copies skb into the > > mediate buffer (gnttab_batch_copy()) and notify Xen VM by sending rx > > irq, the key point is the backend driver doesn't wait for Xen VM to > > process the skb and directly return to user space, therefore, Xen Dom0 > > and DomU work in asynchronous mode in this case (Dom0 doesn't need to > > wait for DomU), the duration for handling a skb is 30+ us. > > > > Conversely, if transmit data from Xen DomU, the flow is: > > > >DomU| Dom0 > > -+ > > xennet driver receives skb | > > `> send tx interrupt to Dom0 | > >| xenif respond tx interrupt > >| Copy skb into mediate buffer > >| Notify DomU (send tx irq) > > xennet driver handle tx irq | > > free skb | > > > > So we can see when DomU sends out packets, it needs to wait for Dom0 to > > process the packets, until Dom0 notifies DomU that packet has been > > processed the net forend driver in DomU releases skb. > > > > This means it's a long way to process skbs: Xen DomU and Dom0 work > > in synchronous mode, the forend driver in DomU sends out skb and > > notifies Dom0, Dom0 handles skb and notifies back to DomU, finally DomU > > knows the skb has been processed and releases it. The duration between > > sendind and releasing a skb is about 180+ us. > > 180us is not great but above you wrote > 60,000 us. In what ways the two > measurements differ? 108us is measured by using ftrace events 'net_dev_queue' and 'kfree_skb'. 60,000us is the measured maximum latency via ddsperf ping & pong [1], the latency is not only caused by low level driver and hypervisor, it also contains the latency caused by the test program itself. AFAIK, ddsperf monitors traffic from userspace and throttle data transferring when it detects tx rate is low, I think this is one main reason for the huge latency (60ms+) from ddsperf. [1] https://cyclonedds.io/docs/cyclonedds/latest/getting_started.html#measuring-latency > > ## Questions > > > > Given Xen network driver has been merged in Linux kernel 2.6 (back in > > 2007), it's very unlikely I am the first person to observe this issue. > > > > I think this is a common issue and not specific to Arm64 arch, the > > reason is the long latency is mainly caused by Xen networking driver > > and I did't see the Xen context switching on Arm64 is abnormal (I saw > > it takes ~10us for context switching between Xen domains). > > Context switching between domains shouldn't come into the picture. For a > latency measurement like that I would make sure to: > > - use the null scheduler, sched=null > - use vwfi=native > > This way, we can be sure both domains are running and there are no > context switches. It should lead to the best latency measurements. Also > this is the configuration we use by default at Xilinx. Okay, will try these two options at my side and share back the testing result. > > Could anyone confirm if this is a known issue? > > This is not something that was discussed recently as far as I know. It is a bit worried me if I am the first one to report this issue. Either it's because this is a specific issue for Arm64 since Xen is much less deployed on Arm64 than x86 platforms; or I must miss something for causing the poor network performance. > > The second question is how to mitigate the long latency when send data > > from DomU. A possible solution is the Xen network forend driver copies > > skb into mediate (bounce) buffer, just like what does in Xen net > > backend driver with gnttab_batch_copy(), in this way the forend driver > > doesn't need to wait for backend driver response and directly return > > back. > > About this, I am not super familiar with drivers/net/xen-netfront.c but > I take you are referring to xennet_tx_buf_gc? Is that the function that > is causing xennet_start_xmit to wait? No. We can take
Re: [PATCH V7 2/2] xen/gnttab: Store frame GFN in struct page_info on Arm
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Rework Arm implementation to store grant table frame GFN > in struct page_info directly instead of keeping it in > standalone status/shared arrays. This patch is based on > the assumption that a grant table page is a xenheap page. > > To cover 64-bit/40-bit IPA on Arm64/Arm32 we need the space > to hold 52-bit/28-bit + extra bit value respectively. In order > to not grow the size of struct page_info borrow the required > amount of bits from type_info's count portion which current > context won't suffer (currently only 1 bit is used on Arm). I'm afraid this isn't true: There's no requirement for a guest to pass all different GFNs to VCPUOP_register_vcpu_info, yet map_vcpu_info() tries to obtain a reference for every vCPU. With my adding of GFN (really gaddr) based registration of the runstate area (already looking towards 4.18) the maximum possible count is to further grow. I guess this went unnoticed because Linux presumably uses different GFNs for every vCPU, so the issue doesn't surface. But I'm afraid this is a regression (unless I'm overlooking something, perhaps a mitigating factor) which wants fixing for 4.17. Jan
Re: [PATCH AUTOSEL 4.19 5/6] x86/entry: Work around Clang __bdos() bug
Hi!
> From: Kees Cook
>
> [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
>
> Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
> and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
> offset. Work around this by using a direct assignment of an empty
> instance. Avoids this warning:
>
> ../include/linux/fortify-string.h:309:4: warning: call to
> __write_overflow_field declared with 'warn
> ing' attribute: detected write beyond size of field (1st parameter); maybe
> use struct_group()? [-Wat
> tribute-warning]
> __write_overflow_field(p_size_field, size);
> ^
>
> which was isolated to the memset() call in xen_load_idt().
>
> Note that this looks very much like another bug that was worked around:
> https://github.com/ClangBuiltLinux/linux/issues/1592
At least in 4.19, there's no UBSAN_BOUNDS. Sounds like we don't need
it in old kernels?
Best regards,
Pavel
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -752,6 +752,7 @@ static void xen_load_idt(const struct desc_ptr *desc)
> {
> static DEFINE_SPINLOCK(lock);
> static struct trap_info traps[257];
> + static const struct trap_info zero = { };
> unsigned out;
>
> trace_xen_cpu_load_idt(desc);
> @@ -761,7 +762,7 @@ static void xen_load_idt(const struct desc_ptr *desc)
> memcpy(this_cpu_ptr(_desc), desc, sizeof(idt_desc));
>
> out = xen_convert_trap_info(desc, traps, false);
> - memset([out], 0, sizeof(traps[0]));
> + traps[out] = zero;
>
> xen_mc_flush();
> if (HYPERVISOR_set_trap_table(traps))
> --
> 2.35.1
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
signature.asc
Description: PGP signature
[PATCH v6 1/6] xen/x86: Provide helpers for common code to access acpi_numa
acpi_numa is a specific NUMA switch for ACPI NUMA implementation.
Other NUMA implementation may not need this switch. But this switch is
not only used by ACPI code, it is also used directly in some general
NUMA logic code. So far this hasn't caused any problem because Xen only
has x86 implementing ACPI NUMA, but now Arm is implementing device tree
based NUMA. Accesssing acpi_numa directly in some functions will be a
block of reusing NUMA common code. It is also difficult for us to replace
it with a new generic switch, because it is hard to prove that the new
switch states can guarantee the original code will work correctly.
So in this patch, we provide two helpers for common code to update and
get states of acpi_numa. And other new NUMA implementations just need
to provide the same helpers for common code. In this case, the generic
NUMA logic code can be reused by all NUMA implementations.
Signed-off-by: Wei Chen
---
v5 -> v6:
1. Revert arch_numa_broken to arch_numa_disabled, as acpi_numa
can be set to -1 by users. So acpi_numa < 0 does not mean
a broken firmware.
v4 -> v5:
1. Use arch_numa_broken instead of arch_numa_disabled for
acpi_numa < 0 check. Because arch_numa_disabled might
include acpi_numa < 0 (init failed) and acpi_numa == 0
(no data or data no init) cases.
v3 -> v4:
1. Drop parameter from arch_numa_disabled, the parameter will be
introduced in later patch where use it.
2. Drop unnecessary "else" from arch_numa_setup, and fix its
indentation.
v2 -> v3:
1. Drop enumeration of numa status.
2. Use helpers to get/update acpi_numa.
3. Insert spaces among parameters of strncmp in numa_setup.
v1 -> v2:
1. Remove fw_numa.
2. Use enumeration to replace numa_off and acpi_numa.
3. Correct return value of srat_disabled.
4. Introduce numa_enabled_with_firmware.
---
xen/arch/x86/include/asm/numa.h | 5 +++--
xen/arch/x86/numa.c | 38 ++---
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index c32ccffde3..237f2c6dbf 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -32,8 +32,9 @@ extern void numa_add_cpu(int cpu);
extern void numa_init_array(void);
extern bool numa_off;
-
-extern int srat_disabled(void);
+extern int arch_numa_setup(const char *opt);
+extern bool arch_numa_disabled(void);
+extern bool srat_disabled(void);
extern void numa_set_node(int cpu, nodeid_t node);
extern nodeid_t setup_node(unsigned int pxm);
extern void srat_detect_node(int cpu);
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 322157fab7..1c3198445d 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -50,9 +50,28 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
bool numa_off;
s8 acpi_numa = 0;
-int srat_disabled(void)
+int __init arch_numa_setup(const char *opt)
{
-return numa_off || acpi_numa < 0;
+#ifdef CONFIG_ACPI_NUMA
+if ( !strncmp(opt, "noacpi", 6) )
+{
+numa_off = false;
+acpi_numa = -1;
+return 0;
+}
+#endif
+
+return -EINVAL;
+}
+
+bool arch_numa_disabled(void)
+{
+return acpi_numa < 0;
+}
+
+bool srat_disabled(void)
+{
+return numa_off || arch_numa_disabled();
}
/*
@@ -294,28 +313,21 @@ void numa_set_node(int cpu, nodeid_t node)
/* [numa=off] */
static int __init cf_check numa_setup(const char *opt)
{
-if ( !strncmp(opt,"off",3) )
+if ( !strncmp(opt, "off", 3) )
numa_off = true;
-else if ( !strncmp(opt,"on",2) )
+else if ( !strncmp(opt, "on", 2) )
numa_off = false;
#ifdef CONFIG_NUMA_EMU
else if ( !strncmp(opt, "fake=", 5) )
{
numa_off = false;
-numa_fake = simple_strtoul(opt+5,NULL,0);
+numa_fake = simple_strtoul(opt + 5, NULL, 0);
if ( numa_fake >= MAX_NUMNODES )
numa_fake = MAX_NUMNODES;
}
-#endif
-#ifdef CONFIG_ACPI_NUMA
-else if ( !strncmp(opt,"noacpi",6) )
-{
-numa_off = false;
-acpi_numa = -1;
-}
#endif
else
-return -EINVAL;
+return arch_numa_setup(opt);
return 0;
}
--
2.25.1
[linux-linus test] 173489: regressions - FAIL
flight 173489 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/173489/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-vhd 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-qcow2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 173462 test-armhf-armhf-examine 8 reboot fail REGR. vs. 173462 test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt-raw 8 xen-boot fail REGR. vs. 173462 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 173462 test-armhf-armhf-xl-arndale 8 xen-boot fail REGR. vs. 173462 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 173462 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173462 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173462 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173462 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173462 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-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-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-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 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 version targeted for testing: linux27bc50fc90647bbf7b734c3fc306a5e61350da53 baseline version: linux9d84bb40bcb30a7fa16f33baa967aeb9953dda78 Last test of basis 173462 2022-10-07 18:41:45 Z3 days Failing since173470 2022-10-08 06:21:34 Z3 days 11 attempts Testing same since 173489 2022-10-11 02:42:09 Z0 days1 attempts 900 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xlpass test-arm64-arm64-xl fail test-armhf-armhf-xl fail
Re: [Xen-devel] Xen crash after S3 suspend - Xen 4.13 and newer
On Tue, Sep 20, 2022 at 04:30:41PM +0200, Jan Beulich wrote: > On 20.09.2022 12:22, Marek Marczykowski-Górecki wrote: > > On Mon, Aug 22, 2022 at 12:00:27PM +0200, Marek Marczykowski-Górecki wrote: > >> On Mon, Aug 22, 2022 at 11:53:50AM +0200, Jan Beulich wrote: > >>> On 21.08.2022 18:14, Marek Marczykowski-Górecki wrote: > On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki > wrote: > > On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki > > wrote: > >> I'm resurrecting this thread as it was recently mentioned elsewhere. I > >> can still reproduce the issue on the recent staging branch > >> (9dc687f155). > >> > >> It fails after the first resume (not always, but frequent enough to > >> debug it). At least one guest needs to be running - with just (PV) dom0 > >> the crash doesn't happen (at least for the ~8 times in a row I tried). > >> If the first resume works, the second (almost?) always will fail but > >> with a different symptoms - dom0 kernel lockups (at least some of its > >> vcpus). I haven't debugged this one yet at all. > >> > >> Any help will be appreciated, I can apply some debug patches, change > >> configuration etc. > > > > This still happens on 4.14.3. Maybe it is related to freeing percpu > > areas, as it caused other issues with suspend too? Just a thought... > > I have reproduced this on current staging(*). And I can reproduce it > reliably. And also, I got (I believe) closely related crash with credit1 > scheduler. > > (*) It isn't plain staging, it's one with my xhci console patches on > top, including attempt to make it survive S3. I believe the only > relevant part there is sticking set_timer() into console resume path (or > just having a timer with rather short delay registered). The actual tree > at https://github.com/marmarek/xen/tree/master-xue2-debug, including > quite a lot of debug prints and debug hacks. > > Specific crash with credit2: > >> > >> (XEN) Assertion 'c2rqd(sched_unit_master(unit)) == svc->rqd' failed at > >> common/sched/credit2.c:2274 > >> (XEN) [ Xen-4.17-unstable x86_64 debug=y Tainted: C] > >> (XEN) CPU:10 > >> (XEN) RIP:e008:[] > >> credit2.c#csched2_unit_wake+0x152/0x154 > >> (XEN) RFLAGS: 00010083 CONTEXT: hypervisor (d0v0) > >> (XEN) rax: 830251778230 rbx: 830251768cb0 rcx: 0032111d6000 > >> (XEN) rdx: 8302515c1eb0 rsi: 0006 rdi: 830251769000 > >> (XEN) rbp: 8302515cfd90 rsp: 8302515cfd70 r8: 830251769000 > >> (XEN) r9: r10: r11: > >> (XEN) r12: 830251768dd0 r13: 8302515c1d00 r14: 0006 > >> (XEN) r15: 82d0405ddb40 cr0: 80050033 cr4: 00372660 > >> (XEN) cr3: 00022f2a1000 cr2: 8881012738e0 > >> (XEN) fsb: 744bf6a0db80 gsb: 88825560 gss: > >> (XEN) ds: es: fs: gs: ss: e010 cs: e008 > >> (XEN) Xen code around > >> (credit2.c#csched2_unit_wake+0x152/0x154): > >> (XEN) df e8 6f bf ff ff eb ad <0f> 0b f3 0f 1e fa 55 48 89 e5 41 57 41 56 > >> 41 55 > >> (XEN) Xen stack trace from rsp=8302515cfd70: > >> (XEN)83025174b000 830251768cb0 830251778270 > >> 82d0405c4298 > >> (XEN)8302515cfdd8 82d04024fcb8 0202 > >> 830251778270 > >> (XEN)83025174b000 0001 830251769018 > >> > >> (XEN) 8302515cfe48 82d04020a8c9 > >> 8882556aedc0 > >> (XEN)0003 1910537e623e 000b988f78a6 > >> 59d4a716 > >> (XEN)1901f30fa41e 000217f96af6 > >> 83025174b000 > >> (XEN)830251756000 0002 0001 > >> 8302515cfe70 > >> (XEN)82d0402f7968 830251756000 8302515cfef8 > >> 0018 > >> (XEN)8302515cfee8 82d0402ec6de > >> 82f157e0 > >> (XEN) 8302515cfef8 > >> > >> (XEN) 8302515c 830251756000 > >> > >> (XEN) > >> 7cfdaea300e7 > >> (XEN)82d0402012bd 82c51120 > >> 88810036cf00 > >> (XEN)0002 0001e120 0002 > >> 0246 > >> (XEN)82f157e0 0001 > >> 0018 > >> (XEN)81e4a30a 0002 > >> 0001 > >> (XEN)0100 81e4a30a e033 > >> 0246 > >> (XEN)c9004aef7c18 e02b fb5ee398d214b10c > >> eb5ef398c214a10c > >> (XEN)eb56f390c21ca104 ebd6f310c29ca184
[PATCH v6 5/6] xen/x86: move NUMA process nodes nodes code from x86 to common
x86 has implemented a set of codes to process NUMA nodes. These
codes will parse NUMA memory and processor information from
ACPI SRAT table. But except some ACPI specific codes, most
of the process code like memory blocks validation, node memory
range updates and some sanity check can be reused by other
NUMA implementation.
So in this patch, we move some variables and related functions
for NUMA memory and processor to common as library. At the
same time, numa_set_processor_nodes_parsed has been introduced
for ACPI specific code to update processor parsing results.
With this helper, we can reuse most of NUMA memory affinity init
code from ACPI. As bad_srat and node_to_pxm functions have been
used in common code to do architectural fallback and node to
architectural node info translation. But it doesn't make sense
to reuse the functions names in common code, we have rename them
to neutral names as well.
PXM is an ACPI specific item, we can't use it in common code
directly. As an alternative, we extend the parameters of
numa_update_node_memblks. The caller can pass the PXM as print
messages' prefix or as architectural node id. And we introduced
an numa_fw_nid_name for each NUMA implementation to set their
specific firmware NUMA node name. In this case, we do not need
to retain a lot of per-arch code but still can print architectural
log messages for different NUMA implementations. A default value
"NONAME" will be set to indicate an unset numa_fw_nid_name.
mem_hotplug is accessed by common code if memory hotplug is
activated. Even if this is only supported by x86, export the
variable so that other architectures could support it in the future.
As asm/acpi.h has been removed from common/numa.c, we have to
move NR_NODE_MEMBLKS from asm/acpi.h to xen/numa.h in this patch
as well.
Signed-off-by: Wei Chen
---
v5 -> v6:
1. Fix code-style.
2. Use arch_numa_unavailable to replace arch_numa_disabled for
acpi_numa <= 0.
3. Remove Kconfig for HAS_NUMA_NODE_FWID.
4. Use numa_fw_nid_name for NUMA implementation to set their fw
NUMA node name for print messages.
v4 -> v5:
1. Introduce arch_numa_disabled for acpi_numa <= 0 in this patch.
2. Remove the paramter init_as_disable of arch_numa_disabled.
3. Fix typo "expandsion".
4. Add const to proper varibales.
5. Fix Indentation for l1tf_safe_maddr.
6. Remove double blank lines.
7. Add a space between for_each_node_mask and '('.
Add a space page_list_for_each and '('.
8. Use bool for nodes_cover_memory return value.
9. Use a plain "int ret" to record compute_hash_shift return value.
10. Add a blank line before the function's main "return".
11. Add new Kconfig option HAS_NUMA_NODE_FWID to common/Kconfig.
v3 -> v4:
1. Use bool as return value for functions that only return
0/1 or 0/-EINVAL.
2. Move mem_hotplug to a proper place in mm.h
3. Remove useless "size" in numa_scan_nodes.
4. Use unsigned int or const for proper variables.
5. Fix code-style.
6. Add init_as_disable as arch_numa_disabled parameter.
7. Add CONFIG_HAS_NUMA_NODE_FWID to gate print the mapping
between node id and architectural node id (fw node id).
v2 -> v3:
1. Add __ro_after_init to proper variables.
2. Rename bad_srat to numa_fw_bad.
3. Rename node_to_pxm to numa_node_to_arch_nid.
4. Merge patch#7 and #8 into this patch.
5. Correct int to unsigned int in proper places.
6. Move NR_NODE_MEMBLKS from x86/acpi.h to common/numa.h
7. Drop helpers to access mem_hotplug, we export mem_hotplug
from x86/mm.c to common/page_alloc.c
v1 -> v2:
1. Add code comment for numa_update_node_memblks to explain:
Assumes all memory regions belonging to a single node
are in one chunk. Holes between them will be included
in the node.
2. Merge this single patch instead of serval patches to move
x86 SRAT code to common.
3. Export node_to_pxm to keep pxm information in NUMA scan
nodes error messages.
4. Change the code style to target file's Xen code-style.
5. Adjust some __init and __initdata for some functions and
variables.
6. Merge two patches into this patch:
1. replace CONFIG_ACPI_NUMA by CONFIG_NUMA.
2. replace "SRAT" texts.
7. Turn numa_scan_nodes to static.
---
xen/arch/x86/include/asm/acpi.h | 1 -
xen/arch/x86/include/asm/mm.h | 2 -
xen/arch/x86/include/asm/numa.h | 3 +-
xen/arch/x86/mm.c | 2 -
xen/arch/x86/numa.c | 5 +
xen/arch/x86/srat.c | 335 +++
xen/common/numa.c | 340 +++-
xen/common/page_alloc.c | 2 +
xen/include/xen/mm.h| 2 +
xen/include/xen/numa.h | 10 +-
10 files changed, 381 insertions(+), 321 deletions(-)
diff --git a/xen/arch/x86/include/asm/acpi.h b/xen/arch/x86/include/asm/acpi.h
index 5c2dd5da2d..c453450a74 100644
--- a/xen/arch/x86/include/asm/acpi.h
+++ b/xen/arch/x86/include/asm/acpi.h
@@ -102,7 +102,6 @@ extern unsigned long acpi_wakeup_address;
#define ARCH_HAS_POWER_INIT1
[PATCH v6 6/6] xen: introduce a Kconfig option to configure NUMA nodes number
Currently the maximum number of NUMA nodes is a hardcoded value. This provides little flexibility unless changing the code. Introduce a new Kconfig option to change the maximum number of NUMA nodes conveniently. Also considering that not all architectures support NUMA, this Kconfig option is only visible on NUMA enabled architectures. Architectures not supporting NUMA still use 1 for MAX_NUMNODES. As NODES_SHIFT is currently unused, we're taking this opportunity to remove it. Signed-off-by: Wei Chen Acked-by: Jan Beulich --- v5 -> v6: 1. No change. v4 -> v5: 1. No change. v3 -> v4: 1. Update the commit log to follow Jan's suggestion. 2. Add Ack-by. v2 -> v3: 1. Fix indent. 2. Use 2-64 for node range. v1 -> v2: 1. Add NODES_SHIFT remove message in commit log 2. Change NR_NUMA_NODES upper bound from 4095 to 255. --- xen/arch/Kconfig| 11 +++ xen/arch/x86/include/asm/numa.h | 2 -- xen/include/xen/numa.h | 11 ++- 3 files changed, 17 insertions(+), 7 deletions(-) diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index f16eb0df43..7028f7b74f 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -17,3 +17,14 @@ config NR_CPUS For CPU cores which support Simultaneous Multi-Threading or similar technologies, this the number of logical threads which Xen will support. + +config NR_NUMA_NODES + int "Maximum number of NUMA nodes supported" + range 2 64 + default "64" + depends on NUMA + help + Controls the build-time size of various arrays and bitmaps + associated with multiple-nodes management. It is the upper bound of + the number of NUMA nodes that the scheduler, memory allocation and + other NUMA-aware components can handle. diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h index 2ca3475271..7866afa408 100644 --- a/xen/arch/x86/include/asm/numa.h +++ b/xen/arch/x86/include/asm/numa.h @@ -3,8 +3,6 @@ #include -#define NODES_SHIFT 6 - typedef u8 nodeid_t; extern int srat_rev; diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h index 04ecaf7769..71a5f837b3 100644 --- a/xen/include/xen/numa.h +++ b/xen/include/xen/numa.h @@ -3,14 +3,15 @@ #include -#ifndef NODES_SHIFT -#define NODES_SHIFT 0 -#endif - #define NUMA_NO_NODE 0xFF #define NUMA_NO_DISTANCE 0xFF -#define MAX_NUMNODES(1 << NODES_SHIFT) +#ifdef CONFIG_NR_NUMA_NODES +#define MAX_NUMNODES CONFIG_NR_NUMA_NODES +#else +#define MAX_NUMNODES 1 +#endif + #define NR_NODE_MEMBLKS (MAX_NUMNODES * 2) #define vcpu_to_node(v) (cpu_to_node((v)->processor)) -- 2.25.1
[PATCH v6 2/6] xen/x86: move generically usable NUMA code from x86 to common
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
and use the CONFIG_NUMA to gate them for non-NUMA supported
architectures. As the target header file is Xen-style, so
we trim some spaces and replace tabs for the codes that has
been moved to xen/numa.h at the same time.
As acpi_scan_nodes has been used in a common function, it
doesn't make sense to use acpi_xxx in common code, so we
rename it to numa_process_nodes in this patch too. After that
if we still use CONFIG_ACPI_NUMA in to gate numa_process_nodes
in numa_initmem_init, that doesn't make sense. As CONFIG_NUMA
will be selected by CONFIG_ACPI_NUMA for x86. So, we replace
CONFIG_ACPI_NUMA by CONFIG_NUMA to gate numa_process_nodes.
As arch_numa_disabled has been implememnted for ACPI NUMA,
we can rename srat_disabled to numa_disabled and move it
to common code as well.
The macro node_to_first_cpu(node) hasn't been used anywhere,
so we drop it in this patch too.
Signed-off-by: Wei Chen
---
v5 -> v6:
1. Replace numa_scan_node to numa_process_nodes in commit log.
2. Limit the scope of page_num_node, vnuma and page of numa_setup
function.
3. Use memset to init page_num_node instead of for_each_online_node.
4. Use %u instead of %d for nodeid_t and j in numa_setup print
messages.
5. Use min(PADDR_BITS, BITS_PER_LONG - 1) to calculate the shift
when only one node is in the system.
6. Drop the marco: node_to_first_cpu(node)
v4 -> v5:
1. Use nodeid_t instead of uint8_t for memnodemap.
2. Restore to use typeof(*memnodemap) for _memnodemap, this will avoid the
further adjustments for _memnodemap's type.
3. Use __ro_after_init for numa_off.
4. Use pointer-to-const for proper function parameters.
5. Use unsigned int for variables that are not realy used for node ID.
6. Fix code comments code-style and adjust the length.
7. Fix code-styles.
8. Rename numa_scan_nodes to numa_process_nodes.
9. Use a plain "int ret" to record compute_hash_shift return value.
v3 -> v4:
1. Restore compute_hash_shift's return value to int.
2. Remove unnecessary parentheses for macros.
3. Use unsigned int for proper variables.
4. Fix some code-style.
v2 -> v3:
1. Remove acpi.h from common/numa.c.
2. Rename acpi_scan_nodes to numa_scan_nodes.
3. Replace u8 by uint8_t for memnodemap.
4. Use unsigned int for memnode_shift and adjust related functions
(compute_hash_shift, populate_memnodemap) to use correct types for
return values or parameters.
5. Use nodeid_t for nodeid and node numbers.
6. Use __read_mostly and __ro_after_init for appropriate variables.
7. Adjust the __read_mostly and __initdata location for some variables.
8. convert from plain int to unsigned for cpuid and other proper variables.
9. Use __attribute_pure__ instead of __attribute__((pure)).
10. Replace CONFIG_ACPI_NUMA by CONFIG_NUMA in numa_initmem_init.
11. Add const for some functions' parameters.
12. Move srat_disabled to common code with new name numa_disabled.
13. Fix some spaces code-style for numa_emulation.
14. Change from int to unsigned int for numa_fake.
v1 -> v2:
1. New patch in v2.
---
xen/arch/x86/include/asm/acpi.h | 1 -
xen/arch/x86/include/asm/numa.h | 57 +---
xen/arch/x86/include/asm/setup.h | 1 -
xen/arch/x86/numa.c | 433 +---
xen/arch/x86/smpboot.c | 2 +-
xen/arch/x86/srat.c | 10 +-
xen/common/Makefile | 1 +
xen/common/numa.c| 464 +++
xen/include/xen/numa.h | 66 +
9 files changed, 539 insertions(+), 496 deletions(-)
create mode 100644 xen/common/numa.c
diff --git a/xen/arch/x86/include/asm/acpi.h b/xen/arch/x86/include/asm/acpi.h
index 9a9cc4c240..5c2dd5da2d 100644
--- a/xen/arch/x86/include/asm/acpi.h
+++ b/xen/arch/x86/include/asm/acpi.h
@@ -102,7 +102,6 @@ extern unsigned long acpi_wakeup_address;
#define ARCH_HAS_POWER_INIT1
extern s8 acpi_numa;
-extern int acpi_scan_nodes(u64 start, u64 end);
#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
extern struct acpi_sleep_info acpi_sinfo;
diff --git a/xen/arch/x86/include/asm/numa.h b/xen/arch/x86/include/asm/numa.h
index 237f2c6dbf..6c87942d43 100644
--- a/xen/arch/x86/include/asm/numa.h
+++ b/xen/arch/x86/include/asm/numa.h
@@ -9,72 +9,17 @@ typedef u8 nodeid_t;
extern int srat_rev;
-extern nodeid_t cpu_to_node[NR_CPUS];
-extern cpumask_t node_to_cpumask[];
-
-#define cpu_to_node(cpu) (cpu_to_node[cpu])
-#define parent_node(node) (node)
-#define node_to_first_cpu(node) (__ffs(node_to_cpumask[node]))
-#define node_to_cpumask(node)(node_to_cpumask[node])
-
-struct node {
- paddr_t start, end;
-};
-
-extern int compute_hash_shift(struct node *nodes,
[PATCH v6 4/6] xen/x86: use arch_get_ram_range to get information from E820 map
The sanity check of nodes_cover_memory is also a requirement of
other architectures that support NUMA. But now, the code of
nodes_cover_memory is tied to the x86 E820. In this case, we
introduce arch_get_ram_range to decouple architecture specific
memory map from this function. This means, other architectures
like Arm can also use it to check its node and memory coverage
from bootmem info.
Depends arch_get_ram_range, we make nodes_cover_memory become
architecture independent. We also use neutral words to replace
SRAT and E820 in the print message of this function. This will
to make the massage seems more common.
As arch_get_ram_range use unsigned int for index, we also adjust
the index in nodes_cover_memory from int to unsigned int.
Signed-off-by: Wei Chen
Reviewed-by: Jan Beulich
---
v5 -> v6:
1. No Change.
v4 -> v5:
1. Add Rb.
2. Adjust the code comments.
v3 -> v4:
1. Move function comment to header file.
2. Use bool for found, and add a new "err" for the return
value of arch_get_ram_range.
3. Use -ENODATA instead of -EINVAL for non-RAM type ranges.
v2 -> v3:
1. Rename arch_get_memory_map to arch_get_ram_range.
2. Use -ENOENT instead of -ENODEV to indicate end of memory map.
3. Add description to code comment that arch_get_ram_range returns
RAM range in [start, end) format.
v1 -> v2:
1. Use arch_get_memory_map to replace arch_get_memory_bank_range
and arch_get_memory_bank_number.
2. Remove the !start || !end check, because caller guarantee
these two pointers will not be NULL.
---
xen/arch/x86/numa.c| 15 +++
xen/arch/x86/srat.c| 30 ++
xen/include/xen/numa.h | 13 +
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 90b2a22591..fa8caaa084 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#ifndef Dprintk
#define Dprintk(x...)
@@ -93,3 +94,17 @@ unsigned int __init arch_get_dma_bitsize(void)
flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 1)
+ PAGE_SHIFT, 32);
}
+
+int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)
+{
+if ( idx >= e820.nr_map )
+return -ENOENT;
+
+if ( e820.map[idx].type != E820_RAM )
+return -ENODATA;
+
+*start = e820.map[idx].addr;
+*end = *start + e820.map[idx].size;
+
+return 0;
+}
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index ce507dac9e..1a108a34c6 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -452,37 +452,43 @@ acpi_numa_memory_affinity_init(const struct
acpi_srat_mem_affinity *ma)
Make sure the PXMs cover all memory. */
static int __init nodes_cover_memory(void)
{
- int i;
+ unsigned int i;
- for (i = 0; i < e820.nr_map; i++) {
- int j, found;
+ for (i = 0; ; i++) {
+ int err;
+ unsigned int j;
+ bool found;
paddr_t start, end;
- if (e820.map[i].type != E820_RAM) {
- continue;
- }
+ /* Try to loop memory map from index 0 to end to get RAM
ranges. */
+ err = arch_get_ram_range(i, , );
- start = e820.map[i].addr;
- end = e820.map[i].addr + e820.map[i].size;
+ /* Reached the end of the memory map? */
+ if (err == -ENOENT)
+ break;
+
+ /* Skip non-RAM entries. */
+ if (err)
+ continue;
do {
- found = 0;
+ found = false;
for_each_node_mask(j, memory_nodes_parsed)
if (start < nodes[j].end
&& end > nodes[j].start) {
if (start >= nodes[j].start) {
start = nodes[j].end;
- found = 1;
+ found = true;
}
if (end <= nodes[j].end) {
end = nodes[j].start;
- found = 1;
+ found = true;
}
}
} while (found && start < end);
if (start < end) {
- printk(KERN_ERR "SRAT: No PXM for e820 range: "
+ printk(KERN_ERR "NUMA: No NODE for RAM range: "
"[%"PRIpaddr", %"PRIpaddr"]\n", start, end - 1);
return 0;
}
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index
[PATCH v6 3/6] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX_NUMNODES" is
defined after the common header file includes the ARCH header
file, where phys_to_nid has attempted to use "MAX_NUMNODES".
This error was resolved after we moved the phys_to_nid from
x86 ARCH header file to common header file.
2. error: wrong type argument to unary exclamation mark.
This is because, the error-checking code contains !node_data[nid].
But node_data is a data structure variable, it's not a pointer.
So, in this patch, we use ASSERT instead of VIRTUAL_BUG_ON to
enable the two lines of error-checking code. And fix the left
compilation errors by replacing !node_data[nid] to
!node_data[nid].node_spanned_pages. Although NUMA allows one node
can only have CPUs but without any memory. And node with 0 bytes
of memory might have an entry in memnodemap[] theoretically. But
that doesn't mean phys_to_nid can find any valid address from a
node with 0 bytes memory.
Signed-off-by: Wei Chen
Tested-by: Jiamei Xie
Acked-by: Jan Beulich
---
v5 -> v6:
1. No Change.
v4 -> v5:
1. No change.
v3 -> v4:
1. No change.
v2 -> v3:
1. Remove unnecessary change items in history.
2. Add Acked-by.
v1 -> v2:
1. Use ASSERT to replace VIRTUAL_BUG_ON in phys_to_nid.
2. Adjust the conditional express for ASSERT.
3. Refine the justification of using !node_data[nid].node_spanned_pages.
---
xen/include/xen/numa.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 5b3877344b..04556f3a6f 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -35,8 +35,6 @@ struct node {
extern int compute_hash_shift(const struct node *nodes,
unsigned int numnodes, const nodeid_t *nodeids);
-#define VIRTUAL_BUG_ON(x)
-
extern bool numa_off;
extern void numa_add_cpu(unsigned int cpu);
@@ -69,9 +67,9 @@ extern struct node_data node_data[];
static inline nodeid_t __attribute_pure__ phys_to_nid(paddr_t addr)
{
nodeid_t nid;
-VIRTUAL_BUG_ON((paddr_to_pdx(addr) >> memnode_shift) >= memnodemapsize);
+ASSERT((paddr_to_pdx(addr) >> memnode_shift) < memnodemapsize);
nid = memnodemap[paddr_to_pdx(addr) >> memnode_shift];
-VIRTUAL_BUG_ON(nid >= MAX_NUMNODES || !node_data[nid]);
+ASSERT(nid < MAX_NUMNODES && node_data[nid].node_spanned_pages);
return nid;
}
--
2.25.1
[PATCH v6 0/6] Device tree based NUMA support for Arm - Part#2
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series - merged in [1]
2. Move generically usable code from x86 to common - this series.
3. Add new code to support Arm.
This series only contains the second part patches. As the whole NUMA
series has been reviewed for 1 round in [2], so this series would
be v6)
Xen memory allocation and scheduler modules are NUMA aware.
But actually, on x86 has implemented the architecture APIs
to support NUMA. Arm was providing a set of fake architecture
APIs to make it compatible with NUMA awared memory allocation
and scheduler.
Arm system was working well as a single node NUMA system with
these fake APIs, because we didn't have multiple nodes NUMA
system on Arm. But in recent years, more and more Arm devices
support multiple nodes NUMA system.
So now we have a new problem. When Xen is running on these Arm
devices, Xen still treat them as single node SMP systems. The
NUMA affinity capability of Xen memory allocation and scheduler
becomes meaningless. Because they rely on input data that does
not reflect real NUMA layout.
Xen still think the access time for all of the memory is the
same for all CPUs. However, Xen may allocate memory to a VM
from different NUMA nodes with different access speeds. This
difference can be amplified in workloads inside VM, causing
performance instability and timeouts.
So in this patch series, we implement a set of NUMA API to use
device tree to describe the NUMA layout. We reuse most of the
code of x86 NUMA to create and maintain the mapping between
memory and CPU, create the matrix between any two NUMA nodes.
Except ACPI and some x86 specified code, we have moved other
code to common. In next stage, when we implement ACPI based
NUMA for Arm64, we may move the ACPI NUMA code to common too,
but in current stage, we keep it as x86 only.
This patch serires has been tested and booted well on one
Arm64 NUMA machine and one HPE x86 NUMA machine.
[1] https://lists.xenproject.org/archives/html/xen-devel/2022-06/msg00499.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg01903.html
---
v5 -> v6:
1. Revert arch_numa_broken to arch_numa_disabled, as acpi_numa
can be set to -1 by users. So acpi_numa < 0 does not mean
a broken firmware.
2. Replace numa_scan_node to numa_process_nodes in commit log.
3. Limit the scope of page_num_node, vnuma and page of numa_setup
function.
4. Use memset to init page_num_node instead of for_each_online_node.
5. Use %u instead of %d for nodeid_t and j in numa_setup print
messages.
6. Use min(PADDR_BITS, BITS_PER_LONG - 1) to calculate the shift
when only one node is in the system.
7. Drop the marco: node_to_first_cpu(node)
8. Use arch_numa_unavailable to replace arch_numa_disabled for
acpi_numa <= 0.
9. Remove Kconfig for HAS_NUMA_NODE_FWID.
10. Use numa_fw_nid_name for NUMA implementation to set their fw
NUMA node name for print messages.
v4 -> v5:
1. Use arch_numa_broken instead of arch_numa_disabled for
acpi_numa < 0 check. Because arch_numa_disabled might
include acpi_numa < 0 (init failed) and acpi_numa == 0
(no data or data no init) cases.
2. Use nodeid_t instead of uint8_t for memnodemap.
3. Restore to use typeof(*memnodemap) for _memnodemap, this will avoid the
further adjustments for _memnodemap's type.
4. Use __ro_after_init for numa_off.
5. Use pointer-to-const for proper function parameters.
6. Use unsigned int for variables that are not realy used for node ID.
7. Fix code comments code-style and adjust the length.
8. Fix code-styles.
9. Rename numa_scan_nodes to numa_process_nodes.
10. Defer introduce arch_numa_disabled for acpi_numa <= 0. And remove
the paramter init_as_disable of arch_numa_disabled.
11. Fix typo "expandsion".
12. Fix Indentation for l1tf_safe_maddr.
13. Remove double blank lines.
14. Add a space between for_each_node_mask and '('.
Add a space page_list_for_each and '('.
15. Use bool for nodes_cover_memory return value.
16. Use a plain "int ret" to record compute_hash_shift return value.
17. Add a blank line before the function's main "return".
18. Add new Kconfig option HAS_NUMA_NODE_FWID to common/Kconfig.
v3 -> v4:
1. Add init_as_disable as arch_numa_disabled parameter in the patche
where use it.
2. Drop unnecessary "else" from arch_numa_setup, and fix its
indentation.
3. Restore compute_hash_shift's return value to int.
4. Remove unnecessary parentheses for macros.
5. Use unsigned int for proper variables.
6. Fix some code-style.
7. Move arch_get_ram_range function comment to header file.
8. Use bool for found, and add a new "err" for the return
value of arch_get_ram_range.
9. Use -ENODATA instead of -EINVAL for non-RAM type ranges.
10. Use bool as return value for functions
Re: [4.17?] Re: [PATCH] x86emul: respect NSCB
On 11/10/2022 11:44, Henry Wang wrote: > Hi Jan, > >> -Original Message- >> From: Jan Beulich >> Subject: [4.17?] Re: [PATCH] x86emul: respect NSCB >> >> On 10.10.2022 18:44, Andrew Cooper wrote: >>> On 15/09/2022 08:22, Jan Beulich wrote: protmode_load_seg() would better adhere to that "feature" of clearing base (and limit) during NULL selector loads. Signed-off-by: Jan Beulich >>> Reviewed-by: Andrew Cooper >> Thanks. >> >> Henry - this was submitted before the code freeze, so you weren't Cc-ed. >> May I ask to consider giving this a release ack? > Since this patch is simple and to my best knowledge this patch is trying to > improve the code so: > > Release-acked-by: Henry Wang > > (If it will not cause too much time of digging, would you mind adding a > "Fixes:" tag pointing to the original commit that missing this > ` vcpu_has_nscb()` check when you do the committing? I think this would > help to identify this patch as a bugfix so it is more reasonable to commit > this patch in current phase. But if too much trouble or you think this is > not really a fix then just ignore my comment...) There isn't really an appropriate Fixes tag. This CPUID bit is one I managed to get AMD to retroactively add to fix an enumeration problem they had no anticipated when making a change in Zen2. i.e. the CPUID bit did not exist at the point at which the code, modified in this patch, was written. ~Andrew
Re: [PATCH v3 4/4] Remove extra copies of licenses and license headers
Hi Stefano, On 11/10/2022 01:26, Stefano Stabellini wrote: On Sun, 9 Oct 2022, Julien Grall wrote: When creating new components, new files, or importing code please follow the conventions outlined below. As a general rule, whenever code using a license other than GPLv2 is introduced, attention must be drawn to the @@ -32,20 +28,22 @@ deviation. Any new code must be GPLv2 compatible. New components -- -When creating new components and directories that contain a -significant amount of files that are licensed under licenses other -than GPLv2 or the license specified in the COPYING file, please -create a new COPYING file in that directory containing a copy of the -license text and a rationale for using a different license. This helps -ensure that the license of this new component/directory is maintained -consistently with the original intention. +When creating new components and directories that contain a significant +amount of files that are licensed under licenses other than GPLv2, +please create a new COPYING file in that directory with the rationale +for using a different license. This helps ensure that the license of +this new component/directory is maintained consistently with the +original intention. I don't understand why the wording "or the license specified in the COPYING file" is dropped. To me, the sentence was indicating that it is not necessary to create a COPYING file in every sub-directory if the license is not GPLv2 and it matches the license of a parent directory. Do you plan to remove COPYING completely? No, I don't plan to remove COPYING completely. COPYING is useful to tell the user what license to choose. I only meant to clarify that COPYING doesn't need to have a full copy of the license again. An SPDX tag would be enough. I can change it to: --- When creating new components and directories that contain a significant amount of files that are licensed under licenses other than GPLv2 or the license specified in the COPYING file, please create a new COPYING file in that directory containing the SPDX tag and a rationale for using a different license. This helps ensure that the license of this new component/directory is maintained consistently with the original intention. --- Sounds good to me. Cheers, -- Julien Grall
RE: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP INS/OUTS
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP
> INS/OUTS
>
> On 10.10.2022 20:08, Andrew Cooper wrote:
> > On 06/10/2022 14:11, Jan Beulich wrote:
> >> Based on observations on a fair range of hardware from both primary
> >> vendors even zero-iteration-count instances of these insns perform the
> >> port related permission checking first.
> >>
> >> Fixes: fe300600464c ("x86: Fix emulation of REP prefix")
> >> Signed-off-by: Jan Beulich
> > Reviewed-by: Andrew Cooper , preferably
> with
> > some of ^ discussed in the commit message.
>
> Thanks, I'll apply this provisionally as I'll need to wait for an ack
> from Henry anyway.
Sorry I was actually waiting for the review/ack in the Patch#1 of this series
so that I can ack them together after they are properly reviewed...
> In the meantime you might clarify whether my
> responses above (which mean no further discussion in the description
> for there being nothing to refer to) don't find your agreement.
...Since IIUC this patch is also trying to harden the code, so as long as you
and Andrew reach the agreement of this patch, you can have my:
Release-acked-by: Henry Wang
Kind regards,
Henry
RE: [4.17?] Re: [PATCH] x86emul: respect NSCB
Hi Jan, > -Original Message- > From: Jan Beulich > Subject: [4.17?] Re: [PATCH] x86emul: respect NSCB > > On 10.10.2022 18:44, Andrew Cooper wrote: > > On 15/09/2022 08:22, Jan Beulich wrote: > >> protmode_load_seg() would better adhere to that "feature" of clearing > >> base (and limit) during NULL selector loads. > >> > >> Signed-off-by: Jan Beulich > > > > Reviewed-by: Andrew Cooper > > Thanks. > > Henry - this was submitted before the code freeze, so you weren't Cc-ed. > May I ask to consider giving this a release ack? Since this patch is simple and to my best knowledge this patch is trying to improve the code so: Release-acked-by: Henry Wang (If it will not cause too much time of digging, would you mind adding a "Fixes:" tag pointing to the original commit that missing this ` vcpu_has_nscb()` check when you do the committing? I think this would help to identify this patch as a bugfix so it is more reasonable to commit this patch in current phase. But if too much trouble or you think this is not really a fix then just ignore my comment...) Kind regards, Henry > > Thanks, Jan
Re: [PATCH 1/2][4.17] x86emul: further correct 64-bit mode zero count repeated string insn handling
On 10.10.2022 20:56, Andrew Cooper wrote:
> On 06/10/2022 14:11, Jan Beulich wrote:
>> In an entirely different context I came across Linux commit 428e3d08574b
>> ("KVM: x86: Fix zero iterations REP-string"), which points out that
>> we're still doing things wrong: For one, there's no zero-extension at
>> all on AMD. And then while RCX is zero-extended from 32 bits uniformly
>> for all string instructions on newer hardware, RSI/RDI are only for MOVS
>> and STOS on the systems I have access to. (On an old family 0xf system
>> I've further found that for REP LODS even RCX is not zero-extended.)
>>
>> Fixes: 79e996a89f69 ("x86emul: correct 64-bit mode repeated string insn
>> handling with zero count")
>> Signed-off-by: Jan Beulich
>> ---
>> Partly RFC for none of this being documented anywhere (and it partly
>> being model specific); inquiry pending.
>
> None of this surprises me. The rep instructions have always been
> microcoded, and 0 reps is a special case which has been largely ignored
> until recently.
>
> I wouldn't be surprised if the behaviour changes with
> MISC_ENABLE.FAST_STRINGS (given the KVM commit message) and I also
> wouldn't be surprised if it's different between Core and Atom too (given
> the Fam 0xf observation).
>
> It's almost worth executing a zero-length rep stub, except that may
> potentially go very wrong in certain ecx/rcx cases.
>
> I'm not sure how important these cases are to cover. Given that they do
> differ between vendors and generation, and that their use in compiled
> code is not going to consider the registers live after use, is the
> complexity really worth it?
By "complexity", what do you mean? The patch doesn't add new complexity,
it only converts "true" to "false" in several places, plus it updates a
comment. I don't think we can legitimately simplify things (by removing
logic), so the only thing I can think of is your thought towards
executing a zero-length REP stub (which you say may be problematic in
certain cases). Patch 2 makes clear why this wouldn't be a good idea
for INS and OUTS. It also cannot possibly be got right when emulating
16-bit code (without switching to a 16-bit code segment), and it's
uncertain whether a 32-bit address size override would actually yield
the same behavior as a native address size operation in 32-bit code.
Of course, if limiting this (the way we currently do) to just 32-bit
addressing in 64-bit mode, then this ought to be representative (with
the INS/OUTS caveat remaining), but - as you say - adding complexity
for likely little gain.
Jan
[libvirt test] 173490: tolerable all pass - PUSHED
flight 173490 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/173490/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 173468 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173468 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 173468 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail 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-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: libvirt 68bf64778846baade8ffcc40cc17b0e9d1d78545 baseline version: libvirt 8ef8d9e21b10f62cad0c36a6ac2b57ac61acd0ec Last test of basis 173468 2022-10-08 04:18:50 Z3 days Testing same since 173490 2022-10-11 04:20:15 Z0 days1 attempts People who touched revisions under test: Jiri Denemark Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of
Re: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP INS/OUTS
On 10.10.2022 20:08, Andrew Cooper wrote:
> On 06/10/2022 14:11, Jan Beulich wrote:
>> Based on observations on a fair range of hardware from both primary
>> vendors even zero-iteration-count instances of these insns perform the
>> port related permission checking first.
>>
>> Fixes: fe300600464c ("x86: Fix emulation of REP prefix")
>> Signed-off-by: Jan Beulich
>> ---
>> Partly RFC for this not being documented anywhere; inquiry pending.
>
> Intel do actually document this in two roundabout ways.
>
> 1) The order of checks in the pseudocode. Multiple times in the past,
> Intel have said that the order of checks in pseudocode is authoritative.
Which pseudo code are you referring to here? There's none I could find
for REP, and the INS and OUTS pages doesn't describe this specific
behavior for REP INS / REP OUTS. Instead, if the description of REP
was authoritative, then
WHILE CountReg ≠ 0
DO
...
OD;
would mean the entire INS/OUTS operation is contained in the body of
that loop, leading to no possible exceptions when the count is zero.
> 2) This paragraph I've just found at the end of the INS description.
>
> "These instructions may read from the I/O port without writing to the
> memory location if an exception or VM exit occurs due to the write (e.g.
> #PF). If this would be problematic, for example because the I/O port
> read has side-effects, software should ensure the write to the memory
> location does not cause an exception or VM exit."
>
> This makes it clear that the IO port is read before the memory operand
> is interpreted. (As a tangent, while the SDM statement is all true,
> it's entirely useless advice for e.g. a migrating VM.)
I, too, had noticed that paragraph. But as above it adds no clarity
whatsoever for the count == 0 case.
> Reviewed-by: Andrew Cooper , preferably with
> some of ^ discussed in the commit message.
Thanks, I'll apply this provisionally as I'll need to wait for an ack
from Henry anyway. In the meantime you might clarify whether my
responses above (which mean no further discussion in the description
for there being nothing to refer to) don't find your agreement.
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -4248,14 +4248,15 @@ x86_emulate(
>> goto imul;
>>
>> case 0x6c ... 0x6d: /* ins %dx,%es:%edi */ {
>> -unsigned long nr_reps = get_rep_prefix(false, false);
>> +unsigned long nr_reps;
>> unsigned int port = _regs.dx;
>>
>> dst.bytes = !(b & 1) ? 1 : (op_bytes == 8) ? 4 : op_bytes;
>> -dst.mem.seg = x86_seg_es;
>> -dst.mem.off = truncate_ea_and_reps(_regs.r(di), nr_reps, dst.bytes);
>> if ( (rc = ioport_access_check(port, dst.bytes, ctxt, ops)) != 0 )
>> goto done;
>> +nr_reps = get_rep_prefix(false, false);
>> +dst.mem.off = truncate_ea_and_reps(_regs.r(di), nr_reps, dst.bytes);
>> +dst.mem.seg = x86_seg_es;
>
> As a further observation, both the Intel and AMD manuals elude to the
> use of unsegmented memory space for the 64bit forms of these.
>
> However, as both %ds (outs) and %es (ins) ignore their bases in 64bit
> mode, I can't think of any practical consequences of conditionally not
> using x86_seg_none here.
I find "not using" irritating, but perhaps I'm simply not reading this
the way it was meant. I'm convinced the memory accesses by these insns
are normal ones, so using ES: means linear address unconditionally (for
INS) in 64-bit mode. For OUTS, however, I don't think an FS: or GS:
override would be ignored. The SDM text also doesn't read as if it
would, to me at least. What is it that you have derived your reply
from? "In 64-bit mode, ..., and 64-bit address is specified using RSI
by default" (for OUTS) doesn't say anything about the segment override
being ignored, and earlier text actually talks about the possibility of
an override, without restricting that to any subset of modes.
Jan
[4.17?] Re: [PATCH] x86emul: respect NSCB
On 10.10.2022 18:44, Andrew Cooper wrote: > On 15/09/2022 08:22, Jan Beulich wrote: >> protmode_load_seg() would better adhere to that "feature" of clearing >> base (and limit) during NULL selector loads. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Andrew Cooper Thanks. Henry - this was submitted before the code freeze, so you weren't Cc-ed. May I ask to consider giving this a release ack? Thanks, Jan
Re: [PATCH v2] Use EfiACPIReclaimMemory for ESRT
On 11.10.2022 05:42, Demi Marie Obenour wrote: > A previous patch tried to get Linux to use the ESRT under Xen if it is > in memory of type EfiRuntimeServicesData. However, this turns out to be > a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory > winds up fragmenting both the EFI page tables and the direct map, Can this statement please be made describe Xen, not Linux? Aiui at least the directmap aspect doesn't apply to Xen. > and > that EfiACPIReclaimMemory is a much better choice for this purpose. I think the "better" wants explaining here, without requiring people to follow ... > Link: > https://lists.xenproject.org/archives/html/xen-devel/2022-09/msg01365.html ... this link. Since the code change looks okay to me, I'd be okay to replace the description with an adjusted one while committing. However, if you expect the change to go into 4.17, you will want to resubmit with Henry on Cc:, so he can consider giving the now necessary release- ack. Jan
[PATCH v3][4.17] EFI: don't convert memory marked for runtime use to ordinary RAM
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
higher priority than the type of the range. To avoid accessing memory at
runtime which was re-used for other purposes, make
efi_arch_process_memory_map() follow suit. While in theory the same would
apply to EfiACPIReclaimMemory, we don't actually "reclaim" or clobber
that memory (converted to E820_ACPI on x86) there (and it would be a bug
if the Dom0 kernel tried to reclaim the range, bypassing Xen's memory
management, plus it would be at least bogus if it clobbered that space),
hence that type's handling can be left alone.
Fixes: bf6501a62e80 ("x86-64: EFI boot code")
Fixes: facac0af87ef ("x86-64: EFI runtime code")
Fixes: 6d70ea10d49f ("Add ARM EFI boot support")
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Release-acked-by: Henry Wang
---
v3: Alter Arm change to leave EfiACPIReclaimMemory handling alone.
v2: Amend description.
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -183,7 +183,8 @@ static EFI_STATUS __init efi_process_mem
for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
{
-if ( desc_ptr->Attribute & EFI_MEMORY_WB &&
+if ( !(desc_ptr->Attribute & EFI_MEMORY_RUNTIME) &&
+ (desc_ptr->Attribute & EFI_MEMORY_WB) &&
(desc_ptr->Type == EfiConventionalMemory ||
desc_ptr->Type == EfiLoaderCode ||
desc_ptr->Type == EfiLoaderData ||
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -185,7 +185,9 @@ static void __init efi_arch_process_memo
/* fall through */
case EfiLoaderCode:
case EfiLoaderData:
-if ( desc->Attribute & EFI_MEMORY_WB )
+if ( desc->Attribute & EFI_MEMORY_RUNTIME )
+type = E820_RESERVED;
+else if ( desc->Attribute & EFI_MEMORY_WB )
type = E820_RAM;
else
case EfiUnusableMemory:
[PATCH] Argo: don't obtain excess page references
find_ring_mfn() already holds a page reference when trying to obtain a writable type reference. We shouldn't make assumptions on the general reference count limit being effectively "infinity". Obtain merely a type ref, re-using the general ref by only dropping the previously acquired one in the case of an error. Signed-off-by: Jan Beulich --- I further question the log-dirty check there: The present P2M type of a page doesn't really matter for writing to the page (plus it's stale by the time it is looked at). Instead I think every write to such a page needs to be accompanied by a call to paging_mark_dirty(). --- a/xen/common/argo.c +++ b/xen/common/argo.c @@ -1429,10 +1429,11 @@ find_ring_mfn(struct domain *d, gfn_t gf ret = -EAGAIN; #endif else if ( (p2mt != p2m_ram_rw) || - !get_page_and_type(page, d, PGT_writable_page) ) + !get_page_type(page, PGT_writable_page) ) ret = -EINVAL; -put_page(page); +if ( unlikely(ret) ) +put_page(page); return ret; }
[PATCH] common: map_vcpu_info() wants to unshare the underlying page
Not passing P2M_UNSHARE to get_page_from_gfn() means there won't even be an attempt to unshare the referenced page, without any indication to the caller (e.g. -EAGAIN). Note that guests have no direct control over which of their pages are shared (or paged out), and hence they have no way to make sure all on their own that the subsequent obtaining of a writable type reference can actually succeed. Signed-off-by: Jan Beulich --- Really I wonder whether the function wouldn't better use check_get_page_from_gfn() _and_ permit p2m_ram_rw only. Otoh the P2M type is stale by the time it is being looked at, so all depends on the subsequent obtaining of a writable type reference anyway ... A similar issue then apparently exists in guest_wrmsr_xen() when writing the hypercall page. Interestingly there p2m_is_paging() is being checked for (but shared pages aren't). --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -1484,7 +1484,7 @@ int map_vcpu_info(struct vcpu *v, unsign if ( (v != current) && !(v->pause_flags & VPF_down) ) return -EINVAL; -page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC); +page = get_page_from_gfn(d, gfn, NULL, P2M_UNSHARE); if ( !page ) return -EINVAL;
[xen-unstable test] 173488: tolerable FAIL
flight 173488 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/173488/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-seattle 13 debian-fixup fail in 173482 pass in 173488 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail in 173482 pass in 173488 test-arm64-arm64-xl 8 xen-boot fail pass in 173482 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat fail pass in 173482 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 15 migrate-support-check fail in 173482 never pass test-arm64-arm64-xl 16 saverestore-support-check fail in 173482 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173482 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 173482 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 173482 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 173482 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 173482 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 173482 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 173482 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 173482 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 173482 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173482 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 173482 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 173482 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 173482 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-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-check
Re: [PATCH][4.17] EFI: don't convert memory marked for runtime use to ordinary RAM
Hi, > On 11 Oct 2022, at 00:58, Stefano Stabellini wrote: > > On Mon, 10 Oct 2022, Jan Beulich wrote: >> On 08.10.2022 21:08, Julien Grall wrote: >>> On 06/10/2022 15:11, Jan Beulich wrote: > ... the space cannot become ordinary RAM, then such a precaution > wouldn't be necessary. After all hiding EfiACPIReclaimMemory from > Dom0 just because it can't be mapped WB wouldn't be very nice > either. I guess I'll submit v2 with this part of the change left > as it was. And while already in the process of committing the patch I came to realize that if the WB conditional isn't supposed to move, isn't the change done for Arm then wrong as well? Shouldn't it then be if ( !(desc_ptr->Attribute & EFI_MEMORY_RUNTIME) && (desc_ptr->Attribute & EFI_MEMORY_WB) && (desc_ptr->Type == EfiConventionalMemory || ... leaving the EfiACPIReclaimMemory case entirely unaffected by the change? >>> >>> IIUC, the concern is the region EfiACPIReclaimMemory could have the >>> attribute EFI_MEMORY_RUNTIME. Is that correct? >> >> Yes, ... >> >>> Given that the memory is reclaimable, I am not sure why it can also have >>> this atribute set (to me it means the opposite). >> >> ... at least on x86 all sorts of strange/bogus type/attribute combinations >> have been observed. > > Yeah... it is a good idea to be able to cope with strange and bogus > firmware tables as it is known to happen I agree with that but if we make an assumption that something is bogus, we should at least warn the user if possible. Bertrand
