[Xen-devel] [linux-linus test] 128312: regressions - FAIL
flight 128312 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/128312/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-credit1 7 xen-bootfail baseline untested test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13
[Xen-devel] [xen-unstable test] 128314: regressions - FAIL
flight 128314 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/128314/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 128084 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail REGR. vs. 128084 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128084 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128084 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128084 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128084 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128084 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 128084 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128084 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 0bc6a68da585cb5d781f27404943a1dbd393e95f baseline version: xen 940185b2f6f343251c2b83bd96e599398cea51ec Last test of basis 128084 2018-09-26 01:51:53 Z7 days Failing since128118 2018-09-27 00:37:03 Z6 days6 attempts Testing same since 128314 2018-10-02 12:35:49 Z0 days1 attempts People who
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-debianhvm-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 17b57b1883c1285f3d0dc2266e8f79286a7bef38 Bug not present: f0dc7f9c6dd99891611fca5849cbc4c6965b690e Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/128327/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemut-debianhvm-amd64.xen-boot --summary-out=tmp/128327.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-xl-qemut-debianhvm-amd64 xen-boot Searching for failure / basis pass: 128278 fail [host=chardonnay1] / 125898 [host=rimava1] 125702 [host=pinot0] 125676 [host=baroque1] 125657 [host=baroque0] 125648 [host=debina0] 125639 [host=elbling1] 125585 [host=rimava1] 125551 [host=joubertin1] 125520 [host=joubertin0] 125501 [host=albana0] 125401 [host=albana1] 125285 [host=debina1] 125129 [host=fiano1] 125069 [host=joubertin1] 125041 [host=debina0] 124994 [host=albana0] 124938 [host=chardonnay0] 124151 [host=debina0] 124092 [host=italia0] 124066 ok. Failure / basis pass flights: 128278 / 124066 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 17b57b1883c1285f3d0dc2266e8f79286a7bef38 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 940185b2f6f343251c2b83bd96e599398cea51ec Basis pass f0dc7f9c6dd99891611fca5849cbc4c6965b690e c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 11535cdbc0ae5925a55b3e735447c30faaa6f63b Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#f0dc7f9c6dd99891611fca5849cbc4c6965b690e-17b57b1883c1285f3d0dc2266e8f79286a7bef38 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#11535cdbc0ae5925a55b3e735447c30faaa6f63b-940185b2f6f343251c2b83bd96e599398cea51ec adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen From git://cache:9419/git://xenbits.xen.org/xen d677097dc1..54ec59f6b0 smoke -> origin/smoke Loaded 2006 nodes in revision graph Searching for test results: 124013 [host=joubertin0] 124047 [host=baroque0] 124066 pass f0dc7f9c6dd99891611fca5849cbc4c6965b690e c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 11535cdbc0ae5925a55b3e735447c30faaa6f63b 124092 [host=italia0] 124151 [host=debina0] 124938 [host=chardonnay0] 124994 [host=albana0] 125041 [host=debina0] 125069 [host=joubertin1] 125167 [host=debina1] 125129 [host=fiano1] 125264 [host=debina1] 125265 [host=debina1] 125244 [host=debina1] 125266 [host=debina1] 125248 [host=debina1] 125249 [host=debina1] 125267 [host=debina1] 125250 [host=debina1] 125251 [host=debina1] 125242 [host=debina1] 125252 [host=debina1] 125254 [host=debina1] 125256 [host=debina1] 125257 [host=debina1] 125258 [host=debina1] 125261 [host=debina1] 125263 [host=debina1] 125285 [host=debina1] 125401 [host=albana1] 125501 [host=albana0] 125551 [host=joubertin1] 125520 [host=joubertin0] 125585 [host=rimava1] 125648 [host=debina0] 125639 [host=elbling1] 125657 [host=baroque0] 125676 [host=baroque1] 125702 [host=pinot0] 125898 [host=rimava1] 125921 fail irrelevant 126069 fail irrelevant 126202 fail irrelevant 126310 fail irrelevant 126412 fail irrelevant 126550 fail irrelevant 126682
[Xen-devel] [xen-unstable-smoke test] 128323: tolerable all pass - PUSHED
flight 128323 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128323/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 54ec59f6b0b363c34cf1864d5214a05e35ea75ee baseline version: xen d677097dc12c15785db8d988253837d0ee7347f4 Last test of basis 128318 2018-10-02 16:00:47 Z0 days Testing same since 128323 2018-10-02 19:07:13 Z0 days1 attempts People who touched revisions under test: Julien Grall Shameer Kolothum jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git d677097dc1..54ec59f6b0 54ec59f6b0b363c34cf1864d5214a05e35ea75ee -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 128311: regressions - FAIL
flight 128311 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/128311/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 128291 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128291 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128291 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128291 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128291 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128291 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu8f09da690f843e2a886f400afc6314aecfdcf9a0 baseline version: qemuua2ef4d9e95400cd387ab4ae19a317741e458fb07 Last test of basis 128291 2018-10-01 18:07:26 Z1 days Testing same since 128311 2018-10-02 10:40:33 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Fam Zheng Kevin Wolf Leonid Bloch Max Filippov Max Reitz Peter Maydell 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
Re: [Xen-devel] Xen 4.12 Development Update
On Wed, Sep 12, 2018 at 02:20:46AM -0600, Jan Beulich wrote: > >>> On 12.09.18 at 08:54, wrote: > > === x86 === > > > > * guest resource mapping (v18) > > - Paul Durrant > > That's all gone in by now? Paul? > > > * hypervisor x86 instruction emulator additions (v4) > > - Jan Beulich > > Where's this "v4" coming from? The presently relevant series is > at v2 right now, with (much bigger) v3 around the corner. > > > * PV-only hypervisor (v1) > > - Wei Liu > > This surely has progressed past v1. There will be further patches to maybe make things nicer, but at this stage PV-only hypervisor is hopefully fully functional. Wei. > > Jan > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128318: tolerable all pass - PUSHED
flight 128318 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128318/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen d677097dc12c15785db8d988253837d0ee7347f4 baseline version: xen 0bc6a68da585cb5d781f27404943a1dbd393e95f Last test of basis 128296 2018-10-01 22:00:33 Z0 days Testing same since 128318 2018-10-02 16:00:47 Z0 days1 attempts People who touched revisions under test: Roger Pau Monné Suravee Suthikulpanit jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 0bc6a68da5..d677097dc1 d677097dc12c15785db8d988253837d0ee7347f4 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Weird altp2m behaviour when switching early to a new view
On 10/2/18 7:29 PM, Сергей wrote: > Hello Razvan. > > Have Your patch been accepted in Xen hypervisor? > > Searching through git I have found commit > "61bdddb82151fbf51c58f6ebc1b4a687942c45a8" on "Thu Jun 28 10:54:01 2018 > +0300". Is that commit deals with the error? No yet, we're working on it. The commit you mention deals with something else. Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask: Add check for io{port, mem}con sorting
> From: Jan Beulich > >>> On 28.09.18 at 21:13, wrote: > > These entries are not always sorted by checkpolicy. Enforce the sorting > > (which can be done manually if using an unpatched checkpolicy) when > > loading the policy so that later uses by the security server do not > > incorrectly use the initial sid. > > "Enforce the sorting" could mean two things - sorting what's unsorted, > or (as you do) raise an error. Isn't raising an error here possibly going > to impact systems which currently work? > > Jan A system whose iomemcon entries are unsorted is currently not enforcing the intended security policy. It normally ends up enforcing a more restrictive policy, but not always (it depends on what you allow access to the default label). My guess is that anyone impacted by this problem would have noticed when they added the rule and it had no effect. However, I do agree this could cause an error on currently-working systems that do things like add iomemcon entries that they don't use. Are you suggesting an update to the commit message to make this breakage clear, or does the problem need to be fixed in the hypervisor? It would be possible to sort the entries as they're added, but that's not as easy as just detecting the mis-sort (since they're a linked list), and the policy creation process should have already sorted them (except that that part was missing). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] xen/arm: vgic-v3: Don't create empty re-distributor regions
Hi, On 01/10/2018 21:55, Stefano Stabellini wrote: On Mon, 1 Oct 2018, Julien Grall wrote: > Reviewed-by: Stefano Stabellini Thank you! I have committed both patches. Can you queue them for backport? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v13 0/9] paravirtual IOMMU pre-requisites and clean-up
So far I have had zero review from AMD maintainers of this series. Can I please get acks or otherwise on the relevant patches? Paul > -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 02 October 2018 18:00 > To: xen-devel@lists.xenproject.org > Cc: Paul Durrant ; Andrew Cooper > ; Brian Woods ; George > Dunlap ; Ian Jackson ; > Jan Beulich ; Julien Grall ; Jun > Nakajima ; Kevin Tian ; > Konrad Rzeszutek Wilk ; Stefano Stabellini > ; Suravee Suthikulpanit > ; Tamas K Lengyel ; > Tim (Xen.org) ; Wei Liu > Subject: [PATCH v13 0/9] paravirtual IOMMU pre-requisites and clean-up > > This series contains pre-requisites and clean-up needed for paravirtual > IOMMU support. > > I have separated these patches to avoid further delaying their application > whilst I re-work the implementation of paravirtual IOMMU after review of > v6 of the series. Several of them already have all necessary acks. > > v11: > - Pull in two more patches from v6. > > Paul Durrant (9): > iommu: introduce the concept of DFN... > iommu: make use of type-safe DFN and MFN in exported functions > iommu: push use of type-safe DFN and MFN into iommu_ops > iommu: don't domain_crash() inside iommu_map/unmap_page() > memory: add check_get_page_from_gfn() as a wrapper... > vtd: add missing check for shared EPT... > vtd: add lookup_page method to iommu_ops > mm / iommu: include need_iommu() test in iommu_use_hap_pt() > mm / iommu: split need_iommu() into has_iommu_pt() and > need_iommu_pt_sync() > > xen/arch/arm/p2m.c| 9 ++- > xen/arch/x86/hvm/emulate.c| 25 > xen/arch/x86/hvm/hvm.c| 14 +--- > xen/arch/x86/hvm/mtrr.c | 4 +- > xen/arch/x86/mm.c | 15 +++-- > xen/arch/x86/mm/mem_sharing.c | 2 +- > xen/arch/x86/mm/p2m-ept.c | 19 -- > xen/arch/x86/mm/p2m-pt.c | 52 +-- > xen/arch/x86/mm/p2m.c | 42 > xen/arch/x86/mm/paging.c | 2 +- > xen/arch/x86/x86_64/mm.c | 15 +++-- > xen/common/grant_table.c | 48 +++--- > xen/common/memory.c | 66 +-- > xen/common/vm_event.c | 2 +- > xen/drivers/passthrough/amd/iommu_cmd.c | 18 +++--- > xen/drivers/passthrough/amd/iommu_map.c | 88 +- > --- > xen/drivers/passthrough/amd/pci_amd_iommu.c | 6 +- > xen/drivers/passthrough/arm/smmu.c| 20 +++--- > xen/drivers/passthrough/device_tree.c | 21 +++--- > xen/drivers/passthrough/iommu.c | 92 -- > - > xen/drivers/passthrough/pci.c | 11 ++-- > xen/drivers/passthrough/vtd/iommu.c | 88 +++--- > --- > xen/drivers/passthrough/vtd/iommu.h | 3 + > xen/drivers/passthrough/vtd/x86/vtd.c | 1 - > xen/drivers/passthrough/x86/iommu.c | 11 ++-- > xen/include/asm-arm/grant_table.h | 2 +- > xen/include/asm-arm/iommu.h | 2 +- > xen/include/asm-arm/p2m.h | 4 +- > xen/include/asm-x86/grant_table.h | 2 +- > xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 8 +-- > xen/include/asm-x86/iommu.h | 17 - > xen/include/asm-x86/p2m.h | 5 +- > xen/include/xen/iommu.h | 68 +--- > xen/include/xen/mm.h | 5 ++ > xen/include/xen/p2m-common.h | 6 ++ > xen/include/xen/sched.h | 14 ++-- > 36 files changed, 514 insertions(+), 293 deletions(-) > --- > Cc: Andrew Cooper > Cc: Brian Woods > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Julien Grall > Cc: Jun Nakajima > Cc: Kevin Tian > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Suravee Suthikulpanit > Cc: Tamas K Lengyel > Cc: Tim Deegan > Cc: Wei Liu > -- > 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v13 3/9] iommu: push use of type-safe DFN and MFN into iommu_ops
This patch modifies the methods in struct iommu_ops to use type-safe DFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Jan Beulich
---
Cc: Suravee Suthikulpanit
Cc: Andrew Cooper
Cc: George Dunlap
v9:
- Re-base.
v7:
- Re-base and re-name BFN -> DFN.
- Added Jan's A-b since re-naming was purely mechanical.
v6:
- Re-base.
v3:
- Remove some use of intermediate 'frame' variables.
v2:
- Addressed comments from Jan.
- Extend use of intermediate 'frame' variable to avoid directly
encapsulating gfn values as bfns (now dfns) or vice versa.
---
xen/drivers/passthrough/amd/iommu_map.c | 46 ---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/arm/smmu.c| 16 +-
xen/drivers/passthrough/iommu.c | 9 +++---
xen/drivers/passthrough/vtd/iommu.c | 26 +++
xen/drivers/passthrough/x86/iommu.c | 2 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 8 ++---
xen/include/xen/iommu.h | 13 +---
8 files changed, 67 insertions(+), 55 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_map.c
b/xen/drivers/passthrough/amd/iommu_map.c
index 61ade71850..c89c54fdb6 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -631,7 +631,7 @@ static int update_paging_mode(struct domain *d, unsigned
long dfn)
return 0;
}
-int amd_iommu_map_page(struct domain *d, unsigned long dfn, unsigned long mfn,
+int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
unsigned int flags)
{
bool_t need_flush = 0;
@@ -651,7 +651,8 @@ int amd_iommu_map_page(struct domain *d, unsigned long dfn,
unsigned long mfn,
if ( rc )
{
spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
domain_crash(d);
return rc;
}
@@ -660,25 +661,27 @@ int amd_iommu_map_page(struct domain *d, unsigned long
dfn, unsigned long mfn,
* we might need a deeper page table for wider dfn now */
if ( is_hvm_domain(d) )
{
-if ( update_paging_mode(d, dfn) )
+if ( update_paging_mode(d, dfn_x(dfn)) )
{
spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Update page mode failed dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
domain_crash(d);
return -EFAULT;
}
}
-if ( iommu_pde_from_dfn(d, dfn, pt_mfn) || (pt_mfn[1] == 0) )
+if ( iommu_pde_from_dfn(d, dfn_x(dfn), pt_mfn) || (pt_mfn[1] == 0) )
{
spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
domain_crash(d);
return -EFAULT;
}
/* Install 4k mapping first */
-need_flush = set_iommu_pte_present(pt_mfn[1], dfn, mfn,
+need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn), mfn_x(mfn),
IOMMU_PAGING_MODE_LEVEL_1,
!!(flags & IOMMUF_writable),
!!(flags & IOMMUF_readable));
@@ -690,7 +693,7 @@ int amd_iommu_map_page(struct domain *d, unsigned long dfn,
unsigned long mfn,
/* 4K mapping for PV guests never changes,
* no need to flush if we trust non-present bits */
if ( is_hvm_domain(d) )
-amd_iommu_flush_pages(d, dfn, 0);
+amd_iommu_flush_pages(d, dfn_x(dfn), 0);
for ( merge_level = IOMMU_PAGING_MODE_LEVEL_2;
merge_level <= hd->arch.paging_mode; merge_level++ )
@@ -698,15 +701,16 @@ int amd_iommu_map_page(struct domain *d, unsigned long
dfn, unsigned long mfn,
if ( pt_mfn[merge_level] == 0 )
break;
if ( !iommu_update_pde_count(d, pt_mfn[merge_level],
- dfn, mfn, merge_level) )
+ dfn_x(dfn), mfn_x(mfn), merge_level) )
break;
-if ( iommu_merge_pages(d, pt_mfn[merge_level], dfn,
+if ( iommu_merge_pages(d, pt_mfn[merge_level], dfn_x(dfn),
flags, merge_level) )
{
spin_unlock(>arch.mapping_lock);
AMD_IOMMU_DEBUG("Merge iommu page failed at level %d, "
-"dfn = %lx mfn = %lx\n", merge_level, dfn, mfn);
+"dfn = %"PRI_dfn" mfn = %"PRI_mfn"\n",
+merge_level,
[Xen-devel] [PATCH v13 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()
The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have
been fully set up'.
Two different meanings are also inferred from the macro it in various
places in the code:
- Some callers want to test whether a domain has IOMMU mappings at all
- Some callers want to test whether they need to synchronize the domain's
P2M and IOMMU mappings
This patch replaces the 'need_iommu' tri-state value with a defined
enumeration and adds a boolean flag 'need_sync' to separate these meanings,
and places both of these in struct domain_iommu, rather than directly in
struct domain.
This patch also creates two new boolean macros:
- 'has_iommu_pt()' evaluates to true if a domain has IOMMU mappings, even
if they are still under construction.
- 'need_iommu_pt_sync()' evaluates to true if a domain requires explicit
synchronization of the P2M and IOMMU mappings.
All callers of need_iommu() are then modified to use the macro appropriate
to what they are trying to test, except for the instance in
xen/drivers/passthrough/pci.c:assign_device() which has simply been
removed since it appears to be unnecessary.
NOTE: There are some callers of need_iommu() that strictly operate on
the hardware domain. In some of these case a more global flag is
used instead.
Signed-off-by: Paul Durrant
Acked-by: Razvan Cojocaru
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Cc: Tamas K Lengyel
Cc: George Dunlap
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Suravee Suthikulpanit
Cc: Brian Woods
v13:
- Re-work checks in memory_add().
- Extend commit comment to note removal of need_iommu() check in
assign_device().
v12:
- Fix two mis-uses of iommu_hap_pt_share().
- Remove one use has_iommu_pt() check in passthrough/pci.c
v11:
- Pulled in from v6 of the full PV-IOMMU series.
_ Changed the condition being tested in memory_add() to be more self-
explanatory but also added a comment to explain the circumstances
under which iommu_map_page() needs to be called.
- Get rid of #ifdef CONFIG_HAS_PASSTHROUGH in memory.c since the if
clauses within will never be executed unless the option is defined
(since has_iommu_pt() will always be false otherwise). Also flushing
should be done regardless of whether the IOMMU is sharing page tables
or not.
v6:
- Deal with need_iommu being tri-state.
- Change the name of 'sync_iommu_pt' to 'need_iommu_pt_sync' and make
sure it is set as soon as the mappings are under construction.
- Not adding Razvan's A-b because of change.
v4:
- New in v4.
---
xen/arch/arm/p2m.c | 2 +-
xen/arch/x86/hvm/mtrr.c | 4 ++--
xen/arch/x86/mm.c | 2 +-
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/p2m-ept.c | 2 +-
xen/arch/x86/mm/p2m-pt.c| 2 +-
xen/arch/x86/mm/p2m.c | 8 +++
xen/arch/x86/mm/paging.c| 2 +-
xen/arch/x86/x86_64/mm.c| 10 ++--
xen/common/memory.c | 10 +++-
xen/common/vm_event.c | 2 +-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/device_tree.c | 21
xen/drivers/passthrough/iommu.c | 37 ++---
xen/drivers/passthrough/pci.c | 11 -
xen/drivers/passthrough/x86/iommu.c | 2 --
xen/include/asm-arm/grant_table.h | 2 +-
xen/include/asm-arm/iommu.h | 2 +-
xen/include/asm-x86/grant_table.h | 2 +-
xen/include/asm-x86/iommu.h | 2 +-
xen/include/xen/iommu.h | 17 +
xen/include/xen/sched.h | 9 ---
22 files changed, 93 insertions(+), 60 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1c79ff7ade..a0bec7c95c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -955,7 +955,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
if ( lpae_is_valid(orig_pte) && entry->p2m.base != orig_pte.p2m.base )
p2m_free_entry(p2m, orig_pte, level);
-if ( need_iommu(p2m->domain) &&
+if ( need_iommu_pt_sync(p2m->domain) &&
(lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
{
rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 4f2f195f7d..b8fa340d5a 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -783,7 +783,7 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr,
hvm_load_mtrr_msr, 1,
void
[Xen-devel] [PATCH v13 5/9] memory: add check_get_page_from_gfn() as a wrapper...
...for some uses of get_page_from_gfn().
There are many occurrences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, , q);
if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);
p2m_mem_paging_populate(d, gfn);
return <-EAGAIN or equivalent>;
}
if ( (q & P2M_UNSHARE) && p2m_is_shared(p2mt) )
{
if ( page )
put_page(page);
return <-EAGAIN or equivalent>;
}
if ( !page )
return <-EINVAL or equivalent>;
There are some small differences between the exact way the occurrences
are coded but the desired semantic is the same.
This patch introduces a new common implementation of this code in
check_get_page_from_gfn() and then converts the various open-coded patterns
into calls to this new function.
NOTE: A forward declaration of p2m_type_t enum has been introduced in
p2m-common.h so that it is possible to declare
check_get_page_from_gfn() there rather than having to add
duplicate declarations in the per-architecture p2m headers.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monne
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v11:
- Forward declare p2m_type_t in p2m-common.h to allow the duplicate
declarations of check_get_page_from_gfn() to be removed, and hence add
Jan's R-b.
v10:
- Expand commit comment to point out the reason for the duplicate
declarations of check_get_page_from_gfn().
v9:
- Defer P2M type checks (beyond shared or paging) to the caller.
v7:
- Fix ARM build by introducing p2m_is_readonly() predicate.
- Re-name get_paged_frame() -> check_get_page_from_gfn().
- Adjust default cases of callers switch-ing on return value.
v3:
- Addressed comments from George.
v2:
- New in v2.
---
xen/arch/x86/hvm/emulate.c | 25 +++---
xen/arch/x86/hvm/hvm.c | 14 +
xen/common/grant_table.c | 32 ++---
xen/common/memory.c | 49 +++-
xen/include/asm-arm/p2m.h| 4 ++--
xen/include/asm-x86/p2m.h| 5 ++---
xen/include/xen/p2m-common.h | 6 ++
7 files changed, 77 insertions(+), 58 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index eab66eab77..cd1d9a7c57 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -356,22 +356,21 @@ static int hvmemul_acquire_page(unsigned long gmfn,
struct page_info **page)
struct domain *curr_d = current->domain;
p2m_type_t p2mt;
-*page = get_page_from_gfn(curr_d, gmfn, , P2M_UNSHARE);
-
-if ( *page == NULL )
-return X86EMUL_UNHANDLEABLE;
-
-if ( p2m_is_paging(p2mt) )
+switch ( check_get_page_from_gfn(curr_d, _gfn(gmfn), false, ,
+ page) )
{
-put_page(*page);
-p2m_mem_paging_populate(curr_d, gmfn);
-return X86EMUL_RETRY;
-}
+case 0:
+break;
-if ( p2m_is_shared(p2mt) )
-{
-put_page(*page);
+case -EAGAIN:
return X86EMUL_RETRY;
+
+default:
+ASSERT_UNREACHABLE();
+/* Fallthrough */
+
+case -EINVAL:
+return X86EMUL_UNHANDLEABLE;
}
/* This code should not be reached if the gmfn is not RAM */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51fc3ec07f..fa994a36a4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2536,20 +2536,8 @@ static void *_hvm_map_guest_frame(unsigned long gfn,
bool_t permanent,
struct page_info *page;
struct domain *d = current->domain;
-page = get_page_from_gfn(d, gfn, ,
- writable ? P2M_UNSHARE : P2M_ALLOC);
-if ( (p2m_is_shared(p2mt) && writable) || !page )
-{
-if ( page )
-put_page(page);
-return NULL;
-}
-if ( p2m_is_paging(p2mt) )
-{
-put_page(page);
-p2m_mem_paging_populate(d, gfn);
+if ( check_get_page_from_gfn(d, _gfn(gfn), !writable, , ) )
return NULL;
-}
if ( writable )
{
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0f0b7b1a49..3604a8812c 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -374,25 +374,23 @@ static int get_paged_frame(unsigned long gfn, mfn_t *mfn,
struct page_info **page, bool readonly,
struct domain *rd)
{
-int rc = GNTST_okay;
p2m_type_t p2mt;
+int rc;
-*mfn = INVALID_MFN;
-*page = get_page_from_gfn(rd, gfn, ,
- readonly ? P2M_ALLOC : P2M_UNSHARE);
-if ( !*page )
+rc = check_get_page_from_gfn(rd, _gfn(gfn), readonly, , page);
+switch ( rc )
{
-#ifdef P2M_SHARED_TYPES
-
[Xen-devel] [PATCH v13 2/9] iommu: make use of type-safe DFN and MFN in exported functions
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Jun Nakajima
Cc: George Dunlap
v9:
- Re-base.
v7:
- Re-base and re-name BFN -> DFN.
- Added Jan's A-b since re-naming was purely mechanical.
v6:
- Re-base.
v3:
- Removed most of the uses of an intermediate 'frame' variable.
v2:
- Addressed comments from Jan.
- Use intermediate 'frame' variable to avoid directly encapsulating
mfn or gfn values as dfns.
---
xen/arch/arm/p2m.c| 3 ++-
xen/arch/x86/mm.c | 10
xen/arch/x86/mm/p2m-ept.c | 10 +---
xen/arch/x86/mm/p2m-pt.c | 45 ---
xen/arch/x86/mm/p2m.c | 16 -
xen/arch/x86/x86_64/mm.c | 5 ++--
xen/common/grant_table.c | 12 +-
xen/common/memory.c | 4 ++--
xen/drivers/passthrough/iommu.c | 25 ++-
xen/drivers/passthrough/vtd/x86/vtd.c | 1 -
xen/drivers/passthrough/x86/iommu.c | 3 ++-
xen/include/xen/iommu.h | 14 +++
12 files changed, 85 insertions(+), 63 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1364e5960a..0db12b01f1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -957,7 +957,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
if ( need_iommu(p2m->domain) &&
(lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
-rc = iommu_iotlb_flush(p2m->domain, gfn_x(sgfn), 1UL << page_order);
+rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
+ 1UL << page_order);
else
rc = 0;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 02abd061be..546d98c864 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2789,14 +2789,14 @@ static int _get_page_type(struct page_info *page,
unsigned long type,
struct domain *d = page_get_owner(page);
if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
{
-gfn_t gfn = _gfn(mfn_to_gmfn(d, mfn_x(page_to_mfn(page;
+mfn_t mfn = page_to_mfn(page);
if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_ret = iommu_unmap_page(d, gfn_x(gfn));
+iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
else if ( type == PGT_writable_page )
-iommu_ret = iommu_map_page(d, gfn_x(gfn),
- mfn_x(page_to_mfn(page)),
- IOMMUF_readable|IOMMUF_writable);
+iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
+ IOMMUF_readable |
+ IOMMUF_writable);
}
}
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index d376966560..e0eb85bc3d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -881,15 +881,19 @@ out:
rc = iommu_pte_flush(d, gfn, _entry->epte, order,
vtd_pte_present);
else
{
+dfn_t dfn = _dfn(gfn);
+
if ( iommu_flags )
for ( i = 0; i < (1 << order); i++ )
{
-rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
iommu_flags);
+rc = iommu_map_page(d, dfn_add(dfn, i),
+mfn_add(mfn, i), iommu_flags);
if ( unlikely(rc) )
{
while ( i-- )
/* If statement to satisfy __must_check. */
-if ( iommu_unmap_page(p2m->domain, gfn + i) )
+if ( iommu_unmap_page(p2m->domain,
+ dfn_add(dfn, i)) )
continue;
break;
@@ -898,7 +902,7 @@ out:
else
for ( i = 0; i < (1 << order); i++ )
{
-ret = iommu_unmap_page(d, gfn + i);
+ret = iommu_unmap_page(d, dfn_add(dfn, i));
if ( !rc )
rc = ret;
}
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 33dd12969c..0569f1de80 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -688,29 +688,36 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
mfn_t mfn,
if ( iommu_old_flags )
[Xen-devel] [PATCH v13 0/9] paravirtual IOMMU pre-requisites and clean-up
This series contains pre-requisites and clean-up needed for paravirtual IOMMU support. I have separated these patches to avoid further delaying their application whilst I re-work the implementation of paravirtual IOMMU after review of v6 of the series. Several of them already have all necessary acks. v11: - Pull in two more patches from v6. Paul Durrant (9): iommu: introduce the concept of DFN... iommu: make use of type-safe DFN and MFN in exported functions iommu: push use of type-safe DFN and MFN into iommu_ops iommu: don't domain_crash() inside iommu_map/unmap_page() memory: add check_get_page_from_gfn() as a wrapper... vtd: add missing check for shared EPT... vtd: add lookup_page method to iommu_ops mm / iommu: include need_iommu() test in iommu_use_hap_pt() mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync() xen/arch/arm/p2m.c| 9 ++- xen/arch/x86/hvm/emulate.c| 25 xen/arch/x86/hvm/hvm.c| 14 +--- xen/arch/x86/hvm/mtrr.c | 4 +- xen/arch/x86/mm.c | 15 +++-- xen/arch/x86/mm/mem_sharing.c | 2 +- xen/arch/x86/mm/p2m-ept.c | 19 -- xen/arch/x86/mm/p2m-pt.c | 52 +-- xen/arch/x86/mm/p2m.c | 42 xen/arch/x86/mm/paging.c | 2 +- xen/arch/x86/x86_64/mm.c | 15 +++-- xen/common/grant_table.c | 48 +++--- xen/common/memory.c | 66 +-- xen/common/vm_event.c | 2 +- xen/drivers/passthrough/amd/iommu_cmd.c | 18 +++--- xen/drivers/passthrough/amd/iommu_map.c | 88 + xen/drivers/passthrough/amd/pci_amd_iommu.c | 6 +- xen/drivers/passthrough/arm/smmu.c| 20 +++--- xen/drivers/passthrough/device_tree.c | 21 +++--- xen/drivers/passthrough/iommu.c | 92 --- xen/drivers/passthrough/pci.c | 11 ++-- xen/drivers/passthrough/vtd/iommu.c | 88 +++-- xen/drivers/passthrough/vtd/iommu.h | 3 + xen/drivers/passthrough/vtd/x86/vtd.c | 1 - xen/drivers/passthrough/x86/iommu.c | 11 ++-- xen/include/asm-arm/grant_table.h | 2 +- xen/include/asm-arm/iommu.h | 2 +- xen/include/asm-arm/p2m.h | 4 +- xen/include/asm-x86/grant_table.h | 2 +- xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 8 +-- xen/include/asm-x86/iommu.h | 17 - xen/include/asm-x86/p2m.h | 5 +- xen/include/xen/iommu.h | 68 +--- xen/include/xen/mm.h | 5 ++ xen/include/xen/p2m-common.h | 6 ++ xen/include/xen/sched.h | 14 ++-- 36 files changed, 514 insertions(+), 293 deletions(-) --- Cc: Andrew Cooper Cc: Brian Woods Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Jun Nakajima Cc: Kevin Tian Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Suravee Suthikulpanit Cc: Tamas K Lengyel Cc: Tim Deegan Cc: Wei Liu -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v13 6/9] vtd: add missing check for shared EPT...
...in intel_iommu_unmap_page().
This patch also includes some non-functional modifications in
intel_iommu_map_page().
Signed-off-by: Paul Durrant
Acked-by: Kevin Tian
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: George Dunlap
v8:
- New in v8. (Split from the next patch in the series as requested by
Kevin).
---
xen/drivers/passthrough/vtd/iommu.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 80264c6cc0..5b66ede599 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1773,7 +1773,7 @@ static int __must_check intel_iommu_map_page(struct
domain *d,
unsigned int flags)
{
struct domain_iommu *hd = dom_iommu(d);
-struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
+struct dma_pte *page, *pte, old, new = {};
u64 pg_maddr;
int rc = 0;
@@ -1788,14 +1788,16 @@ static int __must_check intel_iommu_map_page(struct
domain *d,
spin_lock(>arch.mapping_lock);
pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), 1);
-if ( pg_maddr == 0 )
+if ( !pg_maddr )
{
spin_unlock(>arch.mapping_lock);
return -ENOMEM;
}
+
page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
-pte = page + (dfn_x(dfn) & LEVEL_MASK);
+pte = [dfn_x(dfn) & LEVEL_MASK];
old = *pte;
+
dma_set_pte_addr(new, mfn_to_maddr(mfn));
dma_set_pte_prot(new,
((flags & IOMMUF_readable) ? DMA_PTE_READ : 0) |
@@ -1811,6 +1813,7 @@ static int __must_check intel_iommu_map_page(struct
domain *d,
unmap_vtd_domain_page(page);
return 0;
}
+
*pte = new;
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
@@ -1826,6 +1829,10 @@ static int __must_check intel_iommu_map_page(struct
domain *d,
static int __must_check intel_iommu_unmap_page(struct domain *d,
dfn_t dfn)
{
+/* Do nothing if VT-d shares EPT page table */
+if ( iommu_use_hap_pt(d) )
+return 0;
+
/* Do nothing if hardware domain and iommu supports pass thru. */
if ( iommu_hwdom_passthrough && is_hardware_domain(d) )
return 0;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v13 1/9] iommu: introduce the concept of DFN...
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number
or address relate to a device rather than the CPU.
The parts that are not purely cosmetic are:
- the introduction of a type-safe declaration of dfn_t and definition of
INVALID_DFN to make the substitution of gfn_x(INVALID_GFN) mechanical.
- the introduction of __dfn_to_daddr and __daddr_to_dfn (and type-safe
variants without the leading __) with some use of the former.
Subsequent patches will convert code to make use of type-safe DFNs.
Signed-off-by: Paul Durrant
Acked-by: Jan Beulich
Reviewed-by: Kevin Tian
Acked-by: Julien Grall
---
Cc: Wei Liu
Cc: Suravee Suthikulpanit
Cc: Stefano Stabellini
v9:
- Re-word comment in mm.h.
- Move definitions relating to daddr into asm-x86/iommu.h since these are
not used by any ARM IOMMU implementation.
- Fix __daddr_to_dfn() to properly parenthesize and remove cast.
v8:
- Correct definition of INVALID_DFN.
- Don't use _AC in definition of IOMMU_PAGE_SIZE.
v7:
- Re-name BFN -> DFN as requested by Jan.
- Dropped Wei's R-b because of name change.
v6:
- Dropped changes to 'mfn' section in xen/mm.h as suggested by Kevin.
v3:
- Get rid of intermediate 'frame' variables again.
v2:
- Addressed comments from Jan.
---
xen/drivers/passthrough/amd/iommu_cmd.c | 18 +++
xen/drivers/passthrough/amd/iommu_map.c | 78 ++---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/arm/smmu.c | 16 +++---
xen/drivers/passthrough/iommu.c | 28 +--
xen/drivers/passthrough/vtd/iommu.c | 30 +--
xen/include/asm-x86/iommu.h | 12 +
xen/include/xen/iommu.h | 26 +++---
xen/include/xen/mm.h| 5 ++
9 files changed, 123 insertions(+), 92 deletions(-)
diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c
b/xen/drivers/passthrough/amd/iommu_cmd.c
index 08247fa354..d4d071e53e 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -284,7 +284,7 @@ void invalidate_iommu_all(struct amd_iommu *iommu)
}
void amd_iommu_flush_iotlb(u8 devfn, const struct pci_dev *pdev,
- uint64_t gaddr, unsigned int order)
+ daddr_t daddr, unsigned int order)
{
unsigned long flags;
struct amd_iommu *iommu;
@@ -315,12 +315,12 @@ void amd_iommu_flush_iotlb(u8 devfn, const struct pci_dev
*pdev,
/* send INVALIDATE_IOTLB_PAGES command */
spin_lock_irqsave(>lock, flags);
-invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
+invalidate_iotlb_pages(iommu, maxpend, 0, queueid, daddr, req_id, order);
flush_command_buffer(iommu);
spin_unlock_irqrestore(>lock, flags);
}
-static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
+static void amd_iommu_flush_all_iotlbs(struct domain *d, daddr_t daddr,
unsigned int order)
{
struct pci_dev *pdev;
@@ -333,7 +333,7 @@ static void amd_iommu_flush_all_iotlbs(struct domain *d,
uint64_t gaddr,
u8 devfn = pdev->devfn;
do {
-amd_iommu_flush_iotlb(devfn, pdev, gaddr, order);
+amd_iommu_flush_iotlb(devfn, pdev, daddr, order);
devfn += pdev->phantom_stride;
} while ( devfn != pdev->devfn &&
PCI_SLOT(devfn) == PCI_SLOT(pdev->devfn) );
@@ -342,7 +342,7 @@ static void amd_iommu_flush_all_iotlbs(struct domain *d,
uint64_t gaddr,
/* Flush iommu cache after p2m changes. */
static void _amd_iommu_flush_pages(struct domain *d,
- uint64_t gaddr, unsigned int order)
+ daddr_t daddr, unsigned int order)
{
unsigned long flags;
struct amd_iommu *iommu;
@@ -352,13 +352,13 @@ static void _amd_iommu_flush_pages(struct domain *d,
for_each_amd_iommu ( iommu )
{
spin_lock_irqsave(>lock, flags);
-invalidate_iommu_pages(iommu, gaddr, dom_id, order);
+invalidate_iommu_pages(iommu, daddr, dom_id, order);
flush_command_buffer(iommu);
spin_unlock_irqrestore(>lock, flags);
}
if ( ats_enabled )
-amd_iommu_flush_all_iotlbs(d, gaddr, order);
+amd_iommu_flush_all_iotlbs(d, daddr, order);
}
void amd_iommu_flush_all_pages(struct domain *d)
@@ -367,9 +367,9 @@ void amd_iommu_flush_all_pages(struct domain *d)
}
void amd_iommu_flush_pages(struct domain *d,
- unsigned long gfn, unsigned int order)
+ unsigned long dfn, unsigned int order)
{
-_amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
+
[Xen-devel] [PATCH v13 4/9] iommu: don't domain_crash() inside iommu_map/unmap_page()
This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable by PV IOMMU code to be delivered in
future patches.
This patch adds a helper macro, domu_crash(), that will only invoke
domain_crash() if the domain is not the hardware domain and modifies
callers of iommu_map(), unmap_page() and iommu_iotlb_flush() to use this
should an operation fail.
NOTE: This patch includes one bit of clean-up in set_identity_p2m_entry()
replacing use of p2m->domain with the domain pointer passed into the
function.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monne
Acked-by: Julien Grall
---
Cc: Wei Liu
Cc: Stefano Stabellini
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Jun Nakajima
Cc: George Dunlap
v7:
- Re-base and re-name BFN -> DFN.
- Move domu_crash() outside double locked region in grant_table.c.
- Added Jan's R-b.
v6:
- Introduce domu_crash() (idea suggested by Kevin, name suggested by Jan)
to crash non-hardware domains.
- Dropped Wei's and George's R-b because of change.
v2:
- New in v2.
---
xen/arch/arm/p2m.c | 4
xen/arch/x86/mm.c | 3 +++
xen/arch/x86/mm/p2m-ept.c | 3 +++
xen/arch/x86/mm/p2m-pt.c| 3 +++
xen/arch/x86/mm/p2m.c | 22 ++
xen/common/grant_table.c| 4
xen/common/memory.c | 3 +++
xen/drivers/passthrough/iommu.c | 12
xen/drivers/passthrough/x86/iommu.c | 4
xen/include/xen/sched.h | 5 +
10 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 0db12b01f1..1c79ff7ade 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -957,8 +957,12 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
if ( need_iommu(p2m->domain) &&
(lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
+{
rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
1UL << page_order);
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
+}
else
rc = 0;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 546d98c864..5a7c5335a2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2797,6 +2797,9 @@ static int _get_page_type(struct page_info *page,
unsigned long type,
iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
IOMMUF_readable |
IOMMUF_writable);
+
+if ( unlikely(iommu_ret) )
+domu_crash(d);
}
}
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index e0eb85bc3d..cd4cb5752a 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -906,6 +906,9 @@ out:
if ( !rc )
rc = ret;
}
+
+if ( unlikely(rc) )
+domu_crash(d);
}
}
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 0569f1de80..4735934492 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -718,6 +718,9 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t
mfn,
rc = ret;
}
}
+
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
}
/*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e5c06e22c7..3108fb2b27 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -732,6 +732,9 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned long
gfn_l, unsigned long mfn,
if ( !rc )
rc = ret;
}
+
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
}
return rc;
@@ -797,6 +800,7 @@ guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t
mfn,
if ( iommu_unmap_page(d, dfn_add(dfn, i)) )
continue;
+domu_crash(d);
return rc;
}
}
@@ -1169,12 +1173,17 @@ int set_identity_p2m_entry(struct domain *d, unsigned
long gfn_l,
struct p2m_domain *p2m = p2m_get_hostp2m(d);
int ret;
-if ( !paging_mode_translate(p2m->domain) )
+if ( !paging_mode_translate(d) )
{
if ( !need_iommu(d) )
return 0;
-return iommu_map_page(d, _dfn(gfn_l), _mfn(gfn_l),
- IOMMUF_readable | IOMMUF_writable);
+
+ret = iommu_map_page(d, _dfn(gfn_l), _mfn(gfn_l),
+ IOMMUF_readable | IOMMUF_writable);
+if ( unlikely(ret) )
+
[Xen-devel] [PATCH v13 7/9] vtd: add lookup_page method to iommu_ops
This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified DFN along with a wrapper function
in generic IOMMU code to call the implementation if it exists.
NOTE: This patch only adds a Xen-internal interface. This will be used by
a subsequent patch.
Another subsequent patch will add similar functionality for AMD
IOMMUs.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
---
Cc: Wei Liu
Cc: George Dunlap
v11:
- Fold in patch to change failure semantics (already ack-ed by Kevin).
v10:
- Adjust the locking comment.
v9:
- Add comment about locking in xen/iommu.h.
v8:
- Remove clean-up as this is now done by a prior patch.
- Make intel_iommu_lookup_page() return dfn value if using shared EPT
or iommu_passthrough is set, as requested by Kevin.
v7:
- Re-base and re-name BFN -> DFN.
- Add missing checks for shared EPT and iommu_passthrough.
- Remove unnecessary initializers and use array-style dereference.
- Drop Wei's R-b because of code churn.
v3:
- Addressed comments from George.
v2:
- Addressed some comments from Jan.
---
xen/drivers/passthrough/iommu.c | 11 ++
xen/drivers/passthrough/vtd/iommu.c | 41 +
xen/drivers/passthrough/vtd/iommu.h | 3 +++
xen/include/xen/iommu.h | 10 +
4 files changed, 65 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4486b16109..9cb1793144 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -327,6 +327,17 @@ int iommu_unmap_page(struct domain *d, dfn_t dfn)
return rc;
}
+int iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
+ unsigned int *flags)
+{
+const struct domain_iommu *hd = dom_iommu(d);
+
+if ( !iommu_enabled || !hd->platform_ops )
+return -EOPNOTSUPP;
+
+return hd->platform_ops->lookup_page(d, dfn, mfn, flags);
+}
+
static void iommu_free_pagetables(unsigned long unused)
{
do {
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 5b66ede599..1e861b696d 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1840,6 +1840,46 @@ static int __must_check intel_iommu_unmap_page(struct
domain *d,
return dma_pte_clear_one(d, dfn_to_daddr(dfn));
}
+static int intel_iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
+ unsigned int *flags)
+{
+struct domain_iommu *hd = dom_iommu(d);
+struct dma_pte *page, val;
+u64 pg_maddr;
+
+/*
+ * If VT-d shares EPT page table or if the domain is the hardware
+ * domain and iommu_passthrough is set then pass back the dfn.
+ */
+if ( iommu_use_hap_pt(d) ||
+ (iommu_hwdom_passthrough && is_hardware_domain(d)) )
+return -EOPNOTSUPP;
+
+spin_lock(>arch.mapping_lock);
+
+pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), 0);
+if ( !pg_maddr )
+{
+spin_unlock(>arch.mapping_lock);
+return -ENOMEM;
+}
+
+page = map_vtd_domain_page(pg_maddr);
+val = page[dfn_x(dfn) & LEVEL_MASK];
+
+unmap_vtd_domain_page(page);
+spin_unlock(>arch.mapping_lock);
+
+if ( !dma_pte_present(val) )
+return -ENOENT;
+
+*mfn = maddr_to_mfn(dma_pte_addr(val));
+*flags = dma_pte_read(val) ? IOMMUF_readable : 0;
+*flags |= dma_pte_write(val) ? IOMMUF_writable : 0;
+
+return 0;
+}
+
int iommu_pte_flush(struct domain *d, uint64_t dfn, uint64_t *pte,
int order, int present)
{
@@ -2665,6 +2705,7 @@ const struct iommu_ops intel_iommu_ops = {
.teardown = iommu_domain_teardown,
.map_page = intel_iommu_map_page,
.unmap_page = intel_iommu_unmap_page,
+.lookup_page = intel_iommu_lookup_page,
.free_page_table = iommu_free_page_table,
.reassign_device = reassign_device_ownership,
.get_device_group_id = intel_iommu_group_id,
diff --git a/xen/drivers/passthrough/vtd/iommu.h
b/xen/drivers/passthrough/vtd/iommu.h
index 72c1a2e3cd..47bdfcb5ea 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -272,6 +272,9 @@ struct dma_pte {
#define dma_set_pte_prot(p, prot) do { \
(p).val = ((p).val & ~DMA_PTE_PROT) | ((prot) & DMA_PTE_PROT); \
} while (0)
+#define dma_pte_prot(p) ((p).val & DMA_PTE_PROT)
+#define dma_pte_read(p) (dma_pte_prot(p) & DMA_PTE_READ)
+#define dma_pte_write(p) (dma_pte_prot(p) & DMA_PTE_WRITE)
#define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
#define dma_set_pte_addr(p, addr) do {\
(p).val |= ((addr) & PAGE_MASK_4K); } while (0)
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 7313957c81..9ae8321bb4 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -92,6 +92,8 @@ void iommu_teardown(struct domain *d);
[Xen-devel] [PATCH v13 8/9] mm / iommu: include need_iommu() test in iommu_use_hap_pt()
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Signed-off-by: Paul Durrant
Reviewed-by: Kevin Tian
Acked-by: Julien Grall
---
Cc: Jun Nakajima
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Stefano Stabellini
v11:
- Pulled in from v6 of the full PV-IOMMU series.
v4:
- New in v4.
---
xen/arch/x86/mm/p2m-ept.c | 6 +++---
xen/arch/x86/mm/p2m-pt.c| 6 +++---
xen/arch/x86/mm/p2m.c | 2 +-
xen/drivers/passthrough/iommu.c | 2 +-
xen/include/asm-arm/iommu.h | 2 +-
xen/include/asm-x86/iommu.h | 5 +++--
6 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index cd4cb5752a..f32df3eb7a 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -874,12 +874,12 @@ out:
ept_sync_domain(p2m);
/* For host p2m, may need to change VT-d page table.*/
-if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
+if ( rc == 0 && p2m_is_hostp2m(p2m) &&
need_modify_vtd_table )
{
-if ( iommu_hap_pt_share )
+if ( iommu_use_hap_pt(d) )
rc = iommu_pte_flush(d, gfn, _entry->epte, order,
vtd_pte_present);
-else
+else if ( need_iommu(d) )
{
dfn_t dfn = _dfn(gfn);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 4735934492..bf36160993 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -678,8 +678,8 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t
mfn,
&& (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
-if ( iommu_enabled && need_iommu(p2m->domain) &&
- (iommu_old_flags != iommu_pte_flags || old_mfn != mfn_x(mfn)) )
+if ( iommu_enabled && (iommu_old_flags != iommu_pte_flags ||
+ old_mfn != mfn_x(mfn)) )
{
ASSERT(rc == 0);
@@ -688,7 +688,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t
mfn,
if ( iommu_old_flags )
amd_iommu_flush_pages(p2m->domain, gfn, page_order);
}
-else
+else if ( need_iommu(p2m->domain) )
{
dfn_t dfn = _dfn(gfn);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3108fb2b27..4a98198004 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2101,7 +2101,7 @@ static unsigned int mmio_order(const struct domain *d,
* - exclude PV guests, should execution reach this code for such.
* So be careful when altering this.
*/
-if ( !need_iommu(d) || !iommu_use_hap_pt(d) ||
+if ( !iommu_use_hap_pt(d) ||
(start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >> PAGE_ORDER_2M) )
return PAGE_ORDER_4K;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9cb1793144..ea7ccbace7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -475,7 +475,7 @@ int iommu_do_domctl(
void iommu_share_p2m_table(struct domain* d)
{
-if ( iommu_enabled && iommu_use_hap_pt(d) )
+if ( iommu_use_hap_pt(d) )
iommu_get_ops()->share_p2m(d);
}
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 57d9b1e14a..8d1506c6f7 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -21,7 +21,7 @@ struct arch_iommu
};
/* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) (1)
+#define iommu_use_hap_pt(d) (need_iommu(d))
const struct iommu_ops *iommu_get_ops(void);
void __init iommu_set_ops(const struct iommu_ops *ops);
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 0ed4a9e86d..7c3187c8ec 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -89,8 +89,9 @@ static inline int iommu_hardware_setup(void)
return -ENODEV;
}
-/* Does this domain have a P2M table we can use as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
+/* Are we using the domain P2M table as its IOMMU pagetable? */
+#define iommu_use_hap_pt(d) \
+(hap_enabled(d) && need_iommu(d) && iommu_hap_pt_share)
void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg, unsigned
int value);
unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] x86: support "pv-l1tf=default"
On 01/10/18 13:11, Jan Beulich wrote: > Just like the otherwise similar "xpti=" allows for, to revert back to > built-in defaults. > > Signed-off-by: Jan Beulich I've made my opinion on this matter clear on several occasions. This is not a change I'm happy with taking. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/4] x86: fix "xpti=" and "pv-l1tf=" yet again
On 01/10/18 13:10, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothing as to which default
> is to be overridden; "xpti=no-dom0", for example, ought to have no
> effect for DomU-s, as this is distinct from both "xpti=no-dom0,domu"
> and "xpti=no-dom0,no-domu".
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] x86: split opt_pv_l1tf
On 01/10/18 13:09, Jan Beulich wrote: > Use separate tracking variables for the hardware domain and DomU-s. > > No functional change intended, but adjust the comment in > init_speculation_mitigations() to match prior as well as resulting code. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper , but with one suggested deletion. > @@ -889,18 +892,16 @@ void __init init_speculation_mitigations > > /* > * By default, enable PV domU L1TF mitigations on all L1TF-vulnerable > - * hardware, except when running in shim mode. > + * hardware, except when running in shim mode, and - at least for the > + * time being - also excepting the hardware domain. I'm not sure this addition is helpful. We already state PV domU above. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/pvh: set coherent MTRR state for all vCPUs
Instead of just doing it for the BSP. This requires storing the
maximum number of possible vCPUs in xc_dom_image.
This has been a latent bug so far because PVH doesn't yet support
pci-passthrough, so the effective memory cache attribute is forced to
WB by the hypervisor. Note also that even without this in place vCPU#0
is preferred in certain scenarios in order to calculate the memory
cache attributes.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
---
tools/libxc/include/xc_dom.h | 3 ++
tools/libxc/xc_dom_x86.c | 69
tools/libxl/libxl_dom.c | 2 ++
3 files changed, 52 insertions(+), 22 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 0b5a632d3c..bc125dbd3a 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -230,6 +230,9 @@ struct xc_dom_image {
#endif
xen_pfn_t vuart_gfn;
+
+/* Number of vCPUs */
+unsigned int nr_vcpus;
};
/* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index d77f2d6f62..6c543c0479 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -955,12 +955,9 @@ static int vcpu_hvm(struct xc_dom_image *dom)
HVM_SAVE_TYPE(HEADER) header;
struct hvm_save_descriptor cpu_d;
HVM_SAVE_TYPE(CPU) cpu;
-struct hvm_save_descriptor mtrr_d;
-HVM_SAVE_TYPE(MTRR) mtrr;
struct hvm_save_descriptor end_d;
HVM_SAVE_TYPE(END) end;
} bsp_ctx;
-const HVM_SAVE_TYPE(MTRR) *mtrr_record;
uint8_t *full_ctx = NULL;
int rc;
@@ -1034,35 +1031,63 @@ static int vcpu_hvm(struct xc_dom_image *dom)
if ( dom->start_info_seg.pfn )
bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
-/* Set the MTRR. */
-bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
-bsp_ctx.mtrr_d.instance = 0;
-bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
+/* Set the end descriptor. */
+bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
+bsp_ctx.end_d.instance = 0;
+bsp_ctx.end_d.length = HVM_SAVE_LENGTH(END);
-mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
-if ( !mtrr_record )
+/* TODO: maybe this should be a firmware option instead? */
+if ( !dom->device_model )
{
-xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
- "%s: unable to get MTRR save record", __func__);
-goto out;
-}
+struct {
+struct hvm_save_descriptor header_d;
+HVM_SAVE_TYPE(HEADER) header;
+struct hvm_save_descriptor mtrr_d;
+HVM_SAVE_TYPE(MTRR) mtrr;
+struct hvm_save_descriptor end_d;
+HVM_SAVE_TYPE(END) end;
+} mtrr = {
+.header_d = bsp_ctx.header_d,
+.header = bsp_ctx.header,
+.mtrr_d.typecode = HVM_SAVE_CODE(MTRR),
+.mtrr_d.length = HVM_SAVE_LENGTH(MTRR),
+.end_d = bsp_ctx.end_d,
+.end = bsp_ctx.end,
+};
+const HVM_SAVE_TYPE(MTRR) *mtrr_record =
+hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
+unsigned int i;
+
+if ( !mtrr_record )
+{
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: unable to get MTRR save record", __func__);
+goto out;
+}
-memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
+memcpy(, mtrr_record, sizeof(mtrr.mtrr));
-/* TODO: maybe this should be a firmware option instead? */
-if ( !dom->device_model )
/*
* Enable MTRR, set default type to WB.
* TODO: add MMIO areas as UC when passthrough is supported.
*/
-bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
- MTRR_DEF_TYPE_ENABLE;
+mtrr.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK | MTRR_DEF_TYPE_ENABLE;
-/* Set the end descriptor. */
-bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
-bsp_ctx.end_d.instance = 0;
-bsp_ctx.end_d.length = HVM_SAVE_LENGTH(END);
+for ( i = 0; i < dom->nr_vcpus; i++ )
+{
+mtrr.mtrr_d.instance = i;
+rc = xc_domain_hvm_setcontext(dom->xch, dom->guest_domid,
+ (uint8_t *), sizeof(mtrr));
+if ( rc != 0 )
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: SETHVMCONTEXT failed (rc=%d)", __func__, rc);
+}
+}
+/*
+ * Loading the BSP context should be done in the last call to setcontext,
+ * since each setcontext call will put all vCPUs down.
+ */
rc = xc_domain_hvm_setcontext(dom->xch, dom->guest_domid,
(uint8_t *)_ctx, sizeof(bsp_ctx));
if ( rc != 0 )
diff --git
Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view
Hello Razvan. Have Your patch been accepted in Xen hypervisor? Searching through git I have found commit "61bdddb82151fbf51c58f6ebc1b4a687942c45a8" on "Thu Jun 28 10:54:01 2018 +0300". Is that commit deals with the error? With best regards Sergey Kovalev. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask: Add check for io{port, mem}con sorting
> To: xen-devel@lists.xenproject.org
> From: Daniel De Graaf
> Sent by: "Xen-devel"
> Date: 09/28/2018 09:13PM
> Cc: George Dunlap , Daniel De Graaf
> Subject: [Xen-devel] [PATCH] flask: Add check for io{port,mem}con sorting
>
> These entries are not always sorted by checkpolicy. Enforce the sorting
> (which can be done manually if using an unpatched checkpolicy) when
> loading the policy so that later uses by the security server do not
> incorrectly use the initial sid.
>
> Reported-by: Nicolas Poirot
> Signed-off-by: Daniel De Graaf
> ---
> xen/xsm/flask/ss/policydb.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
> index 3a12d96ef9..fcf63693b9 100644
> --- a/xen/xsm/flask/ss/policydb.c
> +++ b/xen/xsm/flask/ss/policydb.c
> @@ -2007,7 +2007,6 @@ int policydb_read(struct policydb *p, void *fp)
> l->next = c;
> else
> p->ocontexts[i] = c;
> - l = c;
> rc = -EINVAL;
> switch ( i )
> {
> @@ -2050,6 +2049,12 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> + if ( l && l->u.ioport.high_ioport > c->u.ioport.low_ioport )
> + {
> + printk(KERN_ERR
> + "Flask: Invalid policy, ioportcon not sorted\n");
> + goto bad;
> + }
> break;
> case OCON_IOMEM:
> if ( p->target_type != TARGET_XEN )
> @@ -2078,6 +2083,12 @@ int policydb_read(struct policydb *p, void *fp)
> rc = context_read_and_validate(>context, p, fp);
> if ( rc )
> goto bad;
> + if ( l && l->u.iomem.high_iomem > c->u.iomem.low_iomem )
> + {
> + printk(KERN_ERR
> + "Flask: Invalid policy, iomemcon not sorted\n");
> + goto bad;
> + }
> break;
> case OCON_DEVICE:
> if ( p->target_type != TARGET_XEN )
> @@ -2123,6 +2134,7 @@ int policydb_read(struct policydb *p, void *fp)
> rc = -EINVAL;
> goto bad;
> }
> + l = c;
> }
> }
>
> --
> 2.14.4
Looks good to me.
Tested on RELEASE-4.11.0 on a juno-r2 platform, with checkpolicy 2.5.
Thank you.
Tested-by: Nicolas Poirot
Reviewed-by: Nicolas Poirot
.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 02.10.18 at 17:40, wrote: > On 02/10/18 15:43, Jan Beulich wrote: > On 02.10.18 at 16:23, wrote: >>> On 02/10/18 15:06, Jan Beulich wrote: >>> On 02.10.18 at 15:21, wrote: > On 02/10/18 11:12, Jan Beulich wrote: >> --- a/xen/include/xen/lib.h >> +++ b/xen/include/xen/lib.h >> @@ -66,6 +66,10 @@ >> >> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) >> >> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x >> +#define count_va_arg(args...) \ >> +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) > This particular bit of review split out for obvious reasons. > > We already have __count_args() in the ARM SMCCC infrastructure. Please > can we dedup that (broken out into a separate patch) rather than > introducing a competing version. > > The ARM version is buggy. It is off-by-two in the base case, and > doesn't compile if fewer than two parameters are passed. If you had followed earlier discussion, you'd have known up front Julien's reaction. It is for that reason that I'm not trying to fiddle with the ARM code in this regard, despite agreeing with you that at the very least it _looks_ buggy. > This version functions correctly, but should be named with a plural. Why plural? Nothing in stdarg.h uses plural (including the header file name itself). >>> What has stdarg.h got to do with anything here? (Irrespective, the name >>> of the header file alone is the only thing which is grammatically >>> questionable.) >> And the identifier va_arg as well as the __builtin_va_arg it resolves >> to are fine? It is precisely their naming that I've used to decide how >> to name the macro here. > > Yes, because that helper has the purpose of giving you one single argument. > >> >>> count_va_args() should be plural for exactly the same reason that you >>> named its parameter as 'args'. >> That's your personal opinion. > > It is plain grammar. "count_arg" is only correct when the answer is 1. > >> I very much think that the naming >> here should not in any way block the series (and even less so when >> the series has been out for review for almost 3 months, and through >> a couple of iterations), as imo it is well within the bounds of what is >> reasonable to let the submitter decide. (All of this is not to say that >> I wouldn't make the change, if that's the only way to get the series >> in, but it would be very reluctantly.) > > Do you realise how hypocritical this statement is? You frequently > insist on naming changes and hold up series because of it. Perhaps the > best example recently is bfn/dfn, where bfn is a term which has been > used for 3 years at conferences and on xen-devel without objection so far. I know I did bring up this ambiguity of the term "bus" long before. Also note the (significant imo) difference between a singular / plural controversy, and one over possible ambiguities (which may make already hard to understand code even harder to understand). > You cannot expect reviews of your code to be held to a different > standard than you hold others to. And I don't, or at least I try not to. > As for 3 months, I'm sorry that this series hasn't yet reached the top > of my priority list, but you, better than most, know exactly what has > been taking up all of our time during that period. I'm getting through > my review backlog as fast as I can, but it doesn't preempt higher > priority tasks. (As for today, review is happing while one of my slow > servers reboots...) This is all understood, but this particular series (and at least one other one), at least large parts of it, has been reviewed by others, so you _could_ (but of course you don't have to) rely on those other reviews. I hope, however, that you also understand that this almost-no-progress situation is frustrating here. For patches submitted by others, I can stand in for you when you're buried in higher priority tasks, but this does not work for my own patches. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Question, How to share interrupt between Doms
On 02/10/2018 09:32, Peng Fan wrote: Hi Julien, Stefano, Hi Peng, Do you have any suggestions on how to share one interrupt between Doms? Sharing interrupts are usually a pain. You would need to forward the interrupts to all the domains using that interrupt and wait for them to EOI. This has security implications because you don't want DomA to prevent DomB receiving another interrupt because the previous one has not been EOIed correctly. The issue is that a gpio controller has 32 in/out port, however it only has one binded interrupt. The interrupt handler needs to check the status bits to check which port has interrupt coming. In my case, there are different devices using gpio interrupt that needs to be assigned to different doms. From what you wrote, it looks like you expect the GPIO controller to be shared with multiple domains. I don't think it is safe to do that. You need one domain (or Xen) to fully manage the controller. All the other domain will have to access either a virtual GPIO controller or PV one. In the former, interrupt would be virtual, while the latter the interrupt would be through even channel. So sharing interrupt should not be necessary. Did I miss anything? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxl: Restore scheduling parameters after migrate in best-effort fashion
On 10/02/2018 04:49 PM, George Dunlap wrote:
> Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> output of xl list -l") added scheduling parameters to the set of
> information collected by libxl_retrieve_domain_configuration(), in
> order to report that information in `xl list -l`.
>
> Unfortunately, libxl_retrieve_domain_configuration() is also called by
> the migration / save code, and the results passed to the restore /
> receive code. This meant scheduler parameters were inadvertently
> added to the migration stream, without proper consideration for how to
> handle corner cases. The result was that if migrating from a host
> running one scheduler to a host running a different scheduler, the
> migration would fail with an error like the following:
>
> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
> domain sched credit: Invalid argument
> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
> (re-)build domain: -3
>
> Luckily there's a fairly straightforward way to set parameters in a
> "best-effort" fashion. libxl provides a single struct containing the
> parameters of all schedulers, as well as a parameter specifying which
> scheduler. Parameters not used by a given scheduler are ignored.
> Additionally, the struct contains a parameter to specify the
> scheduler. If you specify a specific scheduler,
> libxl_domain_sched_params_set() will fail if there's a different
> scheduler. However, if you pass LIBXL_SCHEDULER_UNKNOWN, it will use
> the value of the current scheduler for that domain.
>
> In domcreate_stream_done(), before calling libxl__build_post(), set
> the scheduler to LIBXL_SCHEDULER_UNKNOWN. This will propagate
> scheduler parameters from the previous instantiation on a best-effort
> basis.
>
> Signed-off-by: George Dunlap
Sorry, forgot to mention this should be considered 'RFC' until I can
arrange to test it.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxl: Restore scheduling parameters after migrate in best-effort fashion
Commit 3b4adba ("tools/libxl: include scheduler parameters in the
output of xl list -l") added scheduling parameters to the set of
information collected by libxl_retrieve_domain_configuration(), in
order to report that information in `xl list -l`.
Unfortunately, libxl_retrieve_domain_configuration() is also called by
the migration / save code, and the results passed to the restore /
receive code. This meant scheduler parameters were inadvertently
added to the migration stream, without proper consideration for how to
handle corner cases. The result was that if migrating from a host
running one scheduler to a host running a different scheduler, the
migration would fail with an error like the following:
libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
domain sched credit: Invalid argument
libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
(re-)build domain: -3
Luckily there's a fairly straightforward way to set parameters in a
"best-effort" fashion. libxl provides a single struct containing the
parameters of all schedulers, as well as a parameter specifying which
scheduler. Parameters not used by a given scheduler are ignored.
Additionally, the struct contains a parameter to specify the
scheduler. If you specify a specific scheduler,
libxl_domain_sched_params_set() will fail if there's a different
scheduler. However, if you pass LIBXL_SCHEDULER_UNKNOWN, it will use
the value of the current scheduler for that domain.
In domcreate_stream_done(), before calling libxl__build_post(), set
the scheduler to LIBXL_SCHEDULER_UNKNOWN. This will propagate
scheduler parameters from the previous instantiation on a best-effort
basis.
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Dario Faggioli
CC: Juergen Gross
---
tools/libxl/libxl_create.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index dcfde7787e..caf79d4620 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1237,6 +1237,15 @@ static void domcreate_stream_done(libxl__egc *egc,
ret = ERROR_INVAL;
goto out;
}
+
+/*
+ * The scheduler on the sending domain may be different than the
+ * scheduler running here. Setting the scheduler to UNKNOWN will
+ * cause the code to take to take whatever parameters are
+ * available in that scheduler, while discarding the rest.
+ */
+info->sched_params.sched = LIBXL_SCHEDULER_UNKNOWN;
+
ret = libxl__build_post(gc, domid, info, state, vments, localents);
if (ret)
goto out;
--
2.19.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 02/10/18 15:43, Jan Beulich wrote: On 02.10.18 at 16:23, wrote: >> On 02/10/18 15:06, Jan Beulich wrote: >> On 02.10.18 at 15:21, wrote: On 02/10/18 11:12, Jan Beulich wrote: > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -66,6 +66,10 @@ > > #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) > > +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x > +#define count_va_arg(args...) \ > +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) This particular bit of review split out for obvious reasons. We already have __count_args() in the ARM SMCCC infrastructure. Please can we dedup that (broken out into a separate patch) rather than introducing a competing version. The ARM version is buggy. It is off-by-two in the base case, and doesn't compile if fewer than two parameters are passed. >>> If you had followed earlier discussion, you'd have known up front >>> Julien's reaction. It is for that reason that I'm not trying to fiddle >>> with the ARM code in this regard, despite agreeing with you that >>> at the very least it _looks_ buggy. >>> This version functions correctly, but should be named with a plural. >>> Why plural? Nothing in stdarg.h uses plural (including the header >>> file name itself). >> What has stdarg.h got to do with anything here? (Irrespective, the name >> of the header file alone is the only thing which is grammatically >> questionable.) > And the identifier va_arg as well as the __builtin_va_arg it resolves > to are fine? It is precisely their naming that I've used to decide how > to name the macro here. Yes, because that helper has the purpose of giving you one single argument. > >> count_va_args() should be plural for exactly the same reason that you >> named its parameter as 'args'. > That's your personal opinion. It is plain grammar. "count_arg" is only correct when the answer is 1. > I very much think that the naming > here should not in any way block the series (and even less so when > the series has been out for review for almost 3 months, and through > a couple of iterations), as imo it is well within the bounds of what is > reasonable to let the submitter decide. (All of this is not to say that > I wouldn't make the change, if that's the only way to get the series > in, but it would be very reluctantly.) Do you realise how hypocritical this statement is? You frequently insist on naming changes and hold up series because of it. Perhaps the best example recently is bfn/dfn, where bfn is a term which has been used for 3 years at conferences and on xen-devel without objection so far. You cannot expect reviews of your code to be held to a different standard than you hold others to. As for 3 months, I'm sorry that this series hasn't yet reached the top of my priority list, but you, better than most, know exactly what has been taking up all of our time during that period. I'm getting through my review backlog as fast as I can, but it doesn't preempt higher priority tasks. (As for today, review is happing while one of my slow servers reboots...) ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 75338: trouble: blocked/broken
This run is configured for baseline tests only. flight 75338 qemu-mainline real [real] http://osstest.xensource.com/osstest/logs/75338/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 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-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1
Re: [Xen-devel] [PATCH RFC] mm/memory_hotplug: Introduce memory block types
On 02/10/2018 15:47, Michal Hocko wrote:
> On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
>> On 01/10/2018 10:40, Michal Hocko wrote:
>>> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
>>> [...]
>>>
>>> I haven't read the patch itself but I just wanted to note one thing
>>> about this part
>>>
For paravirtualized devices it is relevant that memory is onlined as
quickly as possible after adding - and that it is added to the NORMAL
zone. Otherwise, it could happen that too much memory in a row is added
(but not onlined), resulting in out-of-memory conditions due to the
additional memory for "struct pages" and friends. MOVABLE zone as well
as delays might be very problematic and lead to crashes (e.g. zone
imbalance).
>>>
>>> I have proposed (but haven't finished this due to other stuff) a
>>> solution for this. Newly added memory can host memmaps itself and then
>>> you do not have the problem in the first place. For vmemmap it would
>>> have an advantage that you do not really have to beg for 2MB pages to
>>> back the whole section but you would get it for free because the initial
>>> part of the section is by definition properly aligned and unused.
>>
>> So the plan is to "host metadata for new memory on the memory itself".
>> Just want to note that this is basically impossible for s390x with the
>> current mechanisms. (added memory is dead, until onlining notifies the
>> hypervisor and memory is allocated). It will also be problematic for
>> paravirtualized memory devices (e.g. XEN's "not backed by the
>> hypervisor" hacks).
>
> OK, I understand that not all usecases can use self memmap hosting
> others do not have much choice left though. You have to allocate from
> somewhere. Well and alternative would be to have no memmap until
> onlining but I am not sure how much work that would be.
>
>> This would only be possible for memory DIMMs, memory that is completely
>> accessible as far as I can see. Or at least, some specified "first part"
>> is accessible.
>>
>> Other problems are other metadata like extended struct pages and friends.
>
> I wouldn't really worry about extended struct pages. Those should be
> used for debugging purposes mostly. Ot at least that was the case last
> time I've checked.
Yes, I guess that is true. Being able to add and online memory without
the need for additional (external) memory would be the ultimate goal,
but highly complicated. But steps into that direction is a good idea.
>
>> (I really like the idea of adding memory without allocating memory in
>> the hypervisor in the first place, please keep me tuned).
>>
>> And please note: This solves some problematic part ("adding too much
>> memory to the movable zone or not onlining it"), but not the issue of
>> zone imbalance in the first place. And not one issue I try to tackle
>> here: don't add paravirtualized memory to the movable zone.
>
> Zone imbalance is an inherent problem of the highmem zone. It is
> essentially the highmem zone we all loved so much back in 32b days.
> Yes the movable zone doesn't have any addressing limitations so it is a
> bit more relaxed but considering the hotplug scenarios I have seen so
> far people just want to have full NUMA nodes movable to allow replacing
> DIMMs. And then we are back to square one and the zone imbalance issue.
> You have those regardless where memmaps are allocated from.
Unfortunately yes. And things get more complicated as you are adding a
whole DIMMs and get notifications in the granularity of memory blocks.
Usually you are not interested in onlining any memory block of that DIMM
as MOVABLE as soon as you would have to online one memory block of that
DIMM as NORMAL - because that can already block the whole DIMM.
>
>>> I yet have to think about the whole proposal but I am missing the most
>>> important part. _Who_ is going to use the new exported information and
>>> for what purpose. You said that distributions have hard time to
>>> distinguish different types of onlinining policies but isn't this
>>> something that is inherently usecase specific?
>>>
>>
>> Let's think about a distribution. We have a clash of use cases here
>> (just what you describe). What I propose solves one part of it ("handle
>> what you know how to handle right in the kernel").
>>
>> 1. Users of DIMMs usually expect that they can be unplugged again. That
>> is why you want to control how to online memory in user space (== add it
>> to the movable zone).
>
> Which is only true if you really want to hotremove them. I am not going
> to tell how much I believe in this usecase but movable policy is not
> generally applicable here.
Customers expect this to work and the both of us know that we can't make
any guarantees. At least MOVABLE makes it more likely to work. NORMAL is
basically impossible.
>
>> 2. Users of standby memory (s390) expect that memory will never be
>> onlined automatically. It will be onlined manually.
>
> yeah
>
>> 3. Users of
[Xen-devel] [PATCH V3] x86/altp2m: propagate ept.ad changes to all active altp2ms
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
ept.ad value. ept_set_ad_sync() is now also the code
responsible for locking updated p2ms.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
Changes since V2:
- Proper hostp2m locking in ept_{enable,disable}_pml().
- Added two asserts in ept_set_ad_sync(), checking that the
passed p2m is the hostp2m, and that it has been locked.
---
xen/arch/x86/mm/p2m-ept.c | 64 +--
xen/arch/x86/mm/p2m.c | 8 --
2 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index d376966..3d228c2 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1218,34 +1219,79 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
}
+static void ept_set_ad_sync(struct p2m_domain *hostp2m, bool value)
+{
+struct domain *d = hostp2m->domain;
+
+ASSERT(p2m_is_hostp2m(hostp2m));
+ASSERT(p2m_locked_by_me(hostp2m));
+
+hostp2m->ept.ad = value;
+
+if ( unlikely(altp2m_active(d)) )
+{
+unsigned int i;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+struct p2m_domain *p2m;
+
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+
+p2m_lock(p2m);
+p2m->ept.ad = value;
+p2m_unlock(p2m);
+}
+}
+}
+
static void ept_enable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
+
+p2m_lock(hostp2m);
+
/* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
/*
* No need to return whether vmx_domain_enable_pml has succeeded, as
* ept_p2m_type_to_flags will do the check, and write protection will be
* used if PML is not enabled.
*/
-if ( vmx_domain_enable_pml(p2m->domain) )
+if ( vmx_domain_enable_pml(d) )
return;
/* Enable EPT A/D bit for PML */
-p2m->ept.ad = 1;
-vmx_domain_update_eptp(p2m->domain);
+ept_set_ad_sync(hostp2m, true);
+
+vmx_domain_update_eptp(d);
+
+p2m_unlock(hostp2m);
}
static void ept_disable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
+
+p2m_lock(hostp2m);
+
/* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
-vmx_domain_disable_pml(p2m->domain);
+vmx_domain_disable_pml(d);
/* Disable EPT A/D bit */
-p2m->ept.ad = 0;
-vmx_domain_update_eptp(p2m->domain);
+ept_set_ad_sync(hostp2m, false);
+
+vmx_domain_update_eptp(d);
+
+p2m_unlock(hostp2m);
}
static void ept_flush_pml_buffers(struct p2m_domain *p2m)
@@ -1386,8 +1432,10 @@ void setup_ept_dump(void)
void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
{
struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
struct ept_data *ept;
+p2m->ept.ad = hostp2m->ept.ad;
p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
p2m->max_remapped_gfn = 0;
ept = >ept;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index d6a8810..d90c624 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
struct p2m_domain *p2m = p2m_get_hostp2m(d);
if ( p2m->enable_hardware_log_dirty )
-{
-p2m_lock(p2m);
p2m->enable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
}
void p2m_disable_hardware_log_dirty(struct domain *d)
@@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
struct p2m_domain *p2m = p2m_get_hostp2m(d);
if ( p2m->disable_hardware_log_dirty )
-{
-p2m_lock(p2m);
p2m->disable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
}
void p2m_flush_hardware_cached_dirty(struct domain *d)
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool parameter to xl migrate
On 02/10/2018 16:42, Andrew Cooper wrote: > On 02/10/18 15:19, Juergen Gross wrote: >> Add an option to specify the cpupool on the target machine when doing >> a migration of a domain. Currently a domain is always migrated to the >> cpupool with the same name as on the source machine. >> >> Specifying "-c " will migrate the domain to the specified >> cpupool on the target machine. Specifying an empty string for >> will use the default cpupool (normally "Pool-0") on the target machine. >> >> Signed-off-by: Juergen Gross >> --- >> docs/man/xl.pod.1.in | 5 + >> tools/xl/xl.h | 1 + >> tools/xl/xl_cmdtable.c| 3 +++ >> tools/xl/xl_migrate.c | 15 ++- >> tools/xl/xl_saverestore.c | 10 +- >> 5 files changed, 28 insertions(+), 6 deletions(-) >> >> diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in >> index b74764dcd3..62f7c0f039 100644 >> --- a/docs/man/xl.pod.1.in >> +++ b/docs/man/xl.pod.1.in >> @@ -451,6 +451,11 @@ domain. See the corresponding option of the I >> subcommand. >> Send the specified file instead of the file used on creation of the >> domain. >> >> +=item B<-c> I >> + >> +Migrate the domain to the specified on the target host. Specifying >> +an empty string for will use the default cpupool on . >> + > > Is this the wisest way to extend the interface? We already have -C to > specify new configuration, and only have 26*2 short options to use. > > What if the user could supply a xl.cfg snippet on the command line to be > merged over the existing configuration? That would allow any parameter > to be changed, rather than just the cpupool. I'm not opposed to that suggestion, but I believe the cpupool is rather special: it is more like a migration target specification than a domain parameter. In case you are mostly concerned by burning another short option letter I can switch to using --cpupool= syntax. And TBH: I consider the -C option being quite dangerous. While I can understand why it is present it is still a rather hacky approach for a general problem. Same applies to the capability to modify random settings of the domain config. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool parameter to xl migrate
On 02/10/18 15:19, Juergen Gross wrote: > Add an option to specify the cpupool on the target machine when doing > a migration of a domain. Currently a domain is always migrated to the > cpupool with the same name as on the source machine. > > Specifying "-c " will migrate the domain to the specified > cpupool on the target machine. Specifying an empty string for > will use the default cpupool (normally "Pool-0") on the target machine. > > Signed-off-by: Juergen Gross > --- > docs/man/xl.pod.1.in | 5 + > tools/xl/xl.h | 1 + > tools/xl/xl_cmdtable.c| 3 +++ > tools/xl/xl_migrate.c | 15 ++- > tools/xl/xl_saverestore.c | 10 +- > 5 files changed, 28 insertions(+), 6 deletions(-) > > diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in > index b74764dcd3..62f7c0f039 100644 > --- a/docs/man/xl.pod.1.in > +++ b/docs/man/xl.pod.1.in > @@ -451,6 +451,11 @@ domain. See the corresponding option of the I > subcommand. > Send the specified file instead of the file used on creation of the > domain. > > +=item B<-c> I > + > +Migrate the domain to the specified on the target host. Specifying > +an empty string for will use the default cpupool on . > + Is this the wisest way to extend the interface? We already have -C to specify new configuration, and only have 26*2 short options to use. What if the user could supply a xl.cfg snippet on the command line to be merged over the existing configuration? That would allow any parameter to be changed, rather than just the cpupool. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 02.10.18 at 16:23, wrote: > On 02/10/18 15:06, Jan Beulich wrote: > On 02.10.18 at 15:21, wrote: >>> On 02/10/18 11:12, Jan Beulich wrote: --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -66,6 +66,10 @@ #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x +#define count_va_arg(args...) \ +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) >>> This particular bit of review split out for obvious reasons. >>> >>> We already have __count_args() in the ARM SMCCC infrastructure. Please >>> can we dedup that (broken out into a separate patch) rather than >>> introducing a competing version. >>> >>> The ARM version is buggy. It is off-by-two in the base case, and >>> doesn't compile if fewer than two parameters are passed. >> If you had followed earlier discussion, you'd have known up front >> Julien's reaction. It is for that reason that I'm not trying to fiddle >> with the ARM code in this regard, despite agreeing with you that >> at the very least it _looks_ buggy. >> >>> This version functions correctly, but should be named with a plural. >> Why plural? Nothing in stdarg.h uses plural (including the header >> file name itself). > > What has stdarg.h got to do with anything here? (Irrespective, the name > of the header file alone is the only thing which is grammatically > questionable.) And the identifier va_arg as well as the __builtin_va_arg it resolves to are fine? It is precisely their naming that I've used to decide how to name the macro here. > count_va_args() should be plural for exactly the same reason that you > named its parameter as 'args'. That's your personal opinion. I very much think that the naming here should not in any way block the series (and even less so when the series has been out for review for almost 3 months, and through a couple of iterations), as imo it is well within the bounds of what is reasonable to let the submitter decide. (All of this is not to say that I wouldn't make the change, if that's the only way to get the series in, but it would be very reluctantly.) The reason to name the arguments (in their entirety) "args" is, I hope, quite obvious, and unrelated to the macro's name. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool parameter to xl migrate
Andrew Cooper writes ("Re: [Xen-devel] [PATCH 2/2] xl: add target cpupool
parameter to xl migrate"):
> Is this the wisest way to extend the interface? We already have -C to
> specify new configuration, and only have 26*2 short options to use.
Very good question.
> What if the user could supply a xl.cfg snippet on the command line to be
> merged over the existing configuration? That would allow any parameter
> to be changed, rather than just the cpupool.
+1
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 02/10/18 15:06, Jan Beulich wrote: On 02.10.18 at 15:21, wrote: >> On 02/10/18 11:12, Jan Beulich wrote: >>> --- a/xen/include/xen/lib.h >>> +++ b/xen/include/xen/lib.h >>> @@ -66,6 +66,10 @@ >>> >>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) >>> >>> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x >>> +#define count_va_arg(args...) \ >>> +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) >> This particular bit of review split out for obvious reasons. >> >> We already have __count_args() in the ARM SMCCC infrastructure. Please >> can we dedup that (broken out into a separate patch) rather than >> introducing a competing version. >> >> The ARM version is buggy. It is off-by-two in the base case, and >> doesn't compile if fewer than two parameters are passed. > If you had followed earlier discussion, you'd have known up front > Julien's reaction. It is for that reason that I'm not trying to fiddle > with the ARM code in this regard, despite agreeing with you that > at the very least it _looks_ buggy. > >> This version functions correctly, but should be named with a plural. > Why plural? Nothing in stdarg.h uses plural (including the header > file name itself). What has stdarg.h got to do with anything here? (Irrespective, the name of the header file alone is the only thing which is grammatically questionable.) count_va_args() should be plural for exactly the same reason that you named its parameter as 'args'. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] libxl: modify domain config when moving domain to another cpupool
Today the domain config info contains the cpupool name the domain was
started in only if the cpupool was specified at domain creation. Moving
the domain to another cpupool later won't change that information.
Correct that by modifying the domain config accordingly.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl_cpupool.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_cpupool.c b/tools/libxl/libxl_cpupool.c
index 85b06882db..92cf29bc6b 100644
--- a/tools/libxl/libxl_cpupool.c
+++ b/tools/libxl/libxl_cpupool.c
@@ -430,17 +430,39 @@ out:
int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
{
GC_INIT(ctx);
+libxl_domain_config d_config;
+libxl__domain_userdata_lock *lock = NULL;
int rc;
+libxl_domain_config_init(_config);
+
rc = xc_cpupool_movedomain(ctx->xch, poolid, domid);
if (rc) {
LOGEVD(ERROR, rc, domid, "Error moving domain to cpupool");
-GC_FREE;
-return ERROR_FAIL;
+rc = ERROR_FAIL;
+goto out;
+}
+
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
}
+rc = libxl__get_domain_configuration(gc, domid, _config);
+if (rc)
+goto out;
+
+free(d_config.c_info.pool_name);
+d_config.c_info.pool_name = libxl_cpupoolid_to_name(ctx, poolid);
+
+rc = libxl__set_domain_configuration(gc, domid, _config);
+
+out:
+if (lock) libxl__unlock_domain_userdata(lock);
+libxl_domain_config_dispose(_config);
GC_FREE;
-return 0;
+return rc;
}
/*
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] xl: add target cpupool parameter to xl migrate
Add an option to specify the cpupool on the target machine when doing
a migration of a domain. Currently a domain is always migrated to the
cpupool with the same name as on the source machine.
Specifying "-c " will migrate the domain to the specified
cpupool on the target machine. Specifying an empty string for
will use the default cpupool (normally "Pool-0") on the target machine.
Signed-off-by: Juergen Gross
---
docs/man/xl.pod.1.in | 5 +
tools/xl/xl.h | 1 +
tools/xl/xl_cmdtable.c| 3 +++
tools/xl/xl_migrate.c | 15 ++-
tools/xl/xl_saverestore.c | 10 +-
5 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index b74764dcd3..62f7c0f039 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -451,6 +451,11 @@ domain. See the corresponding option of the I
subcommand.
Send the specified file instead of the file used on creation of the
domain.
+=item B<-c> I
+
+Migrate the domain to the specified on the target host. Specifying
+an empty string for will use the default cpupool on .
+
=item B<--debug>
Display huge (!) amount of debug information during the migration process.
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index cf4202bc89..a7d4910f9a 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -100,6 +100,7 @@ struct save_file_header {
void save_domain_core_begin(uint32_t domid,
const char *override_config_file,
+const char *override_cpupool,
uint8_t **config_data_r,
int *config_len_r);
void save_domain_core_writeconfig(int fd, const char *source,
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 89716badcb..93aab5130d 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -161,6 +161,9 @@ struct cmd_spec cmd_table[] = {
"[options] ",
"-h Print this help.\n"
"-C Send instead of config file from creation.\n"
+ "-c Specify the cpupool on the target host the domain
should\n"
+ "be migrated to. Specifying an empty string for
\n"
+ "will use the default cpupool on the target host.\n"
"-s Use instead of ssh. String will be
passed\n"
"to sh. If empty, run instead of ssh xl\n"
"migrate-receive [-d -e]\n"
diff --git a/tools/xl/xl_migrate.c b/tools/xl/xl_migrate.c
index 1f0e87df50..66f0a0958d 100644
--- a/tools/xl/xl_migrate.c
+++ b/tools/xl/xl_migrate.c
@@ -177,7 +177,8 @@ static void migrate_do_preamble(int send_fd, int recv_fd,
pid_t child,
}
static void migrate_domain(uint32_t domid, const char *rune, int debug,
- const char *override_config_file)
+ const char *override_config_file,
+ const char *override_cpupool)
{
pid_t child = -1;
int rc;
@@ -187,7 +188,7 @@ static void migrate_domain(uint32_t domid, const char
*rune, int debug,
uint8_t *config_data;
int config_len, flags = LIBXL_SUSPEND_LIVE;
-save_domain_core_begin(domid, override_config_file,
+save_domain_core_begin(domid, override_config_file, override_cpupool,
_data, _len);
if (!config_len) {
@@ -533,6 +534,7 @@ int main_migrate(int argc, char **argv)
{
uint32_t domid;
const char *config_filename = NULL;
+const char *cpupool = NULL;
const char *ssh_command = "ssh";
char *rune = NULL;
char *host;
@@ -543,10 +545,13 @@ int main_migrate(int argc, char **argv)
COMMON_LONG_OPTS
};
-SWITCH_FOREACH_OPT(opt, "FC:s:ep", opts, "migrate", 2) {
+SWITCH_FOREACH_OPT(opt, "FC:c:s:ep", opts, "migrate", 2) {
case 'C':
config_filename = optarg;
break;
+case 'c':
+cpupool = optarg;
+break;
case 's':
ssh_command = optarg;
break;
@@ -596,7 +601,7 @@ int main_migrate(int argc, char **argv)
pause_after_migration ? " -p" : "");
}
-migrate_domain(domid, rune, debug, config_filename);
+migrate_domain(domid, rune, debug, config_filename, cpupool);
return EXIT_SUCCESS;
}
@@ -716,7 +721,7 @@ int main_remus(int argc, char **argv)
}
}
-save_domain_core_begin(domid, NULL, _data, _len);
+save_domain_core_begin(domid, NULL, NULL, _data, _len);
if (!config_len) {
fprintf(stderr, "No config file stored for running domain and "
diff --git a/tools/xl/xl_saverestore.c b/tools/xl/xl_saverestore.c
index 9afeadeeb2..2583b6c800 100644
--- a/tools/xl/xl_saverestore.c
+++ b/tools/xl/xl_saverestore.c
@@ -33,6 +33,7 @@
void save_domain_core_begin(uint32_t domid,
const char *override_config_file,
+const char *override_cpupool,
[Xen-devel] [PATCH 0/2] tools: correct/enhance cpupool handling
Make handling of cpupool data in domain config more consistent. Patch 1 is updating the cpupool in domain's config when moving the domain to another cpupool. Patch 2 allows to specify a cpupool on the destination host for domain migration. Juergen Gross (2): libxl: modify domain config when moving domain to another cpupool xl: add target cpupool parameter to xl migrate docs/man/xl.pod.1.in| 5 + tools/libxl/libxl_cpupool.c | 28 +--- tools/xl/xl.h | 1 + tools/xl/xl_cmdtable.c | 3 +++ tools/xl/xl_migrate.c | 15 ++- tools/xl/xl_saverestore.c | 10 +- 6 files changed, 53 insertions(+), 9 deletions(-) -- 2.16.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 02.10.18 at 15:55, wrote: > On Tue, Oct 02, 2018 at 04:12:08AM -0600, Jan Beulich wrote: >> In a number of cases the targets of indirect calls get determined once >> at boot time. In such cases we can replace those calls with direct ones >> via our alternative instruction patching mechanism. >> >> Some of the targets (in particular the hvm_funcs ones) get established >> only in pre-SMP initcalls, making necessary a second passs through the >> alternative patching code. Therefore some adjustments beyond the >> recognition of the new special pattern are necessary there. >> >> Note that patching such sites more than once is not supported (and the >> supplied macros also don't provide any means to do so). >> >> Signed-off-by: Jan Beulich >> --- >> v4: Extend / adjust comments. > > Thanks, this makes it much easier to reason about the code. > > I know there are comments about a macro, but they don't really affect > the meat of this patch, so whether the macro is split out to a > prerequisite patch or not: > > Reviewed-by: Wei Liu Thanks, this is much appreciated especially in that context. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> On 02.10.18 at 15:21, wrote: > On 02/10/18 11:12, Jan Beulich wrote: >> --- a/xen/include/xen/lib.h >> +++ b/xen/include/xen/lib.h >> @@ -66,6 +66,10 @@ >> >> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) >> >> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x >> +#define count_va_arg(args...) \ >> +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) > > This particular bit of review split out for obvious reasons. > > We already have __count_args() in the ARM SMCCC infrastructure. Please > can we dedup that (broken out into a separate patch) rather than > introducing a competing version. > > The ARM version is buggy. It is off-by-two in the base case, and > doesn't compile if fewer than two parameters are passed. If you had followed earlier discussion, you'd have known up front Julien's reaction. It is for that reason that I'm not trying to fiddle with the ARM code in this regard, despite agreeing with you that at the very least it _looks_ buggy. > This version functions correctly, but should be named with a plural. Why plural? Nothing in stdarg.h uses plural (including the header file name itself). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On Tue, Oct 02, 2018 at 04:12:08AM -0600, Jan Beulich wrote: > In a number of cases the targets of indirect calls get determined once > at boot time. In such cases we can replace those calls with direct ones > via our alternative instruction patching mechanism. > > Some of the targets (in particular the hvm_funcs ones) get established > only in pre-SMP initcalls, making necessary a second passs through the > alternative patching code. Therefore some adjustments beyond the > recognition of the new special pattern are necessary there. > > Note that patching such sites more than once is not supported (and the > supplied macros also don't provide any means to do so). > > Signed-off-by: Jan Beulich > --- > v4: Extend / adjust comments. Thanks, this makes it much easier to reason about the code. I know there are comments about a macro, but they don't really affect the meat of this patch, so whether the macro is split out to a prerequisite patch or not: Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v3 3/4] x86/HVM: implement memory read caching
On 10/2/18 6:39 AM, Jan Beulich wrote: On 25.09.18 at 16:25, wrote: >> Emulation requiring device model assistance uses a form of instruction >> re-execution, assuming that the second (and any further) pass takes >> exactly the same path. This is a valid assumption as far use of CPU >> registers goes (as those can't change without any other instruction >> executing in between), but is wrong for memory accesses. In particular >> it has been observed that Windows might page out buffers underneath an >> instruction currently under emulation (hitting between two passes). If >> the first pass translated a linear address successfully, any subsequent >> pass needs to do so too, yielding the exact same translation. >> >> Introduce a cache (used by just guest page table accesses for now) to >> make sure above described assumption holds. This is a very simplistic >> implementation for now: Only exact matches are satisfied (no overlaps or >> partial reads or anything). >> >> As to the actual data page in this scenario, there are a couple of >> aspects to take into consideration: >> - We must be talking about an insn accessing two locations (two memory >> ones, one of which is MMIO, or a memory and an I/O one). >> - If the non I/O / MMIO side is being read, the re-read (if it occurs at >> all) is having its result discarded, by taking the shortcut through >> the first switch()'s STATE_IORESP_READY case in hvmemul_do_io(). Note >> how, among all the re-issue sanity checks there, we avoid comparing >> the actual data. >> - If the non I/O / MMIO side is being written, it is the OSes >> responsibility to avoid actually moving page contents to disk while >> there might still be a write access in flight - this is no different >> in behavior from bare hardware. >> - Read-modify-write accesses are, as always, complicated, and while we >> deal with them better nowadays than we did in the past, we're still >> not quite there to guarantee hardware like behavior in all cases >> anyway. Nothing is getting worse by the changes made here, afaict. >> >> Signed-off-by: Jan Beulich >> Acked-by: Tim Deegan >> Reviewed-by: Paul Durrant > SVM and VMX maintainers? Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] mm/memory_hotplug: Introduce memory block types
On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
> On 01/10/2018 10:40, Michal Hocko wrote:
> > On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> > [...]
> >
> > I haven't read the patch itself but I just wanted to note one thing
> > about this part
> >
> >> For paravirtualized devices it is relevant that memory is onlined as
> >> quickly as possible after adding - and that it is added to the NORMAL
> >> zone. Otherwise, it could happen that too much memory in a row is added
> >> (but not onlined), resulting in out-of-memory conditions due to the
> >> additional memory for "struct pages" and friends. MOVABLE zone as well
> >> as delays might be very problematic and lead to crashes (e.g. zone
> >> imbalance).
> >
> > I have proposed (but haven't finished this due to other stuff) a
> > solution for this. Newly added memory can host memmaps itself and then
> > you do not have the problem in the first place. For vmemmap it would
> > have an advantage that you do not really have to beg for 2MB pages to
> > back the whole section but you would get it for free because the initial
> > part of the section is by definition properly aligned and unused.
>
> So the plan is to "host metadata for new memory on the memory itself".
> Just want to note that this is basically impossible for s390x with the
> current mechanisms. (added memory is dead, until onlining notifies the
> hypervisor and memory is allocated). It will also be problematic for
> paravirtualized memory devices (e.g. XEN's "not backed by the
> hypervisor" hacks).
OK, I understand that not all usecases can use self memmap hosting
others do not have much choice left though. You have to allocate from
somewhere. Well and alternative would be to have no memmap until
onlining but I am not sure how much work that would be.
> This would only be possible for memory DIMMs, memory that is completely
> accessible as far as I can see. Or at least, some specified "first part"
> is accessible.
>
> Other problems are other metadata like extended struct pages and friends.
I wouldn't really worry about extended struct pages. Those should be
used for debugging purposes mostly. Ot at least that was the case last
time I've checked.
> (I really like the idea of adding memory without allocating memory in
> the hypervisor in the first place, please keep me tuned).
>
> And please note: This solves some problematic part ("adding too much
> memory to the movable zone or not onlining it"), but not the issue of
> zone imbalance in the first place. And not one issue I try to tackle
> here: don't add paravirtualized memory to the movable zone.
Zone imbalance is an inherent problem of the highmem zone. It is
essentially the highmem zone we all loved so much back in 32b days.
Yes the movable zone doesn't have any addressing limitations so it is a
bit more relaxed but considering the hotplug scenarios I have seen so
far people just want to have full NUMA nodes movable to allow replacing
DIMMs. And then we are back to square one and the zone imbalance issue.
You have those regardless where memmaps are allocated from.
> > I yet have to think about the whole proposal but I am missing the most
> > important part. _Who_ is going to use the new exported information and
> > for what purpose. You said that distributions have hard time to
> > distinguish different types of onlinining policies but isn't this
> > something that is inherently usecase specific?
> >
>
> Let's think about a distribution. We have a clash of use cases here
> (just what you describe). What I propose solves one part of it ("handle
> what you know how to handle right in the kernel").
>
> 1. Users of DIMMs usually expect that they can be unplugged again. That
> is why you want to control how to online memory in user space (== add it
> to the movable zone).
Which is only true if you really want to hotremove them. I am not going
to tell how much I believe in this usecase but movable policy is not
generally applicable here.
> 2. Users of standby memory (s390) expect that memory will never be
> onlined automatically. It will be onlined manually.
yeah
> 3. Users of paravirtualized devices (esp. Hyper-V) don't care about
> memory unplug in the sense of MOVABLE at all. They (or Hyper-V!) will
> add a whole bunch of memory and expect that everything works fine. So
> that memory is onlined immediately and that memory is added to the
> NORMAL zone. Users never want the MOVABLE zone.
Then the immediate question would be why to use memory hotplug for that
at all? Why don't you simply start with a huge pre-allocated physical
address space and balloon memory in an out per demand. Why do you want
to inject new memory during the runtime?
> 1. is a reason why distributions usually don't configure
> "MEMORY_HOTPLUG_DEFAULT_ONLINE", because you really want the option for
> MOVABLE zone. That however implies, that e.g. for x86, you have to
> handle all new memory in user space, especially also HyperV memory.
> There, you
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 02/10/2018 14:35, Andrew Cooper wrote: On 02/10/18 14:28, Julien Grall wrote: Hi Andrew, On 02/10/2018 14:21, Andrew Cooper wrote: On 02/10/18 11:12, Jan Beulich wrote: --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -66,6 +66,10 @@ #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x +#define count_va_arg(args...) \ + count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) This particular bit of review split out for obvious reasons. We already have __count_args() in the ARM SMCCC infrastructure. Please can we dedup that (broken out into a separate patch) rather than introducing a competing version. The ARM version is buggy. It is off-by-two in the base case, and doesn't compile if fewer than two parameters are passed. This version functions correctly, but should be named with a plural. The ARM version is *not* buggy. What the ARM version count is the number of parameters for the SMCCC function, *not* the number of parameter for the call. This matches the SMCCC where the first parameter is always the function ID, the last parameter is always the result structure. The code will end up to be less readable using a generic count. I am planning to Nack anything trying to use a generic count in the SMCCC code. Yes it is buggy, because it doesn't behave as the name suggests. If you mean the infrastructure to have SMCCC specific behaviour, the macros should be named suitably, to avoid interfering with common code. Well the code is coming from Linux. Feel free to send a patch to fix the name in Linux and Xen. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 02/10/18 14:28, Julien Grall wrote: > Hi Andrew, > > On 02/10/2018 14:21, Andrew Cooper wrote: >> On 02/10/18 11:12, Jan Beulich wrote: >>> --- a/xen/include/xen/lib.h >>> +++ b/xen/include/xen/lib.h >>> @@ -66,6 +66,10 @@ >>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) >>> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x >>> +#define count_va_arg(args...) \ >>> + count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) >> >> This particular bit of review split out for obvious reasons. >> >> We already have __count_args() in the ARM SMCCC infrastructure. Please >> can we dedup that (broken out into a separate patch) rather than >> introducing a competing version. >> >> The ARM version is buggy. It is off-by-two in the base case, and >> doesn't compile if fewer than two parameters are passed. This version >> functions correctly, but should be named with a plural. > > The ARM version is *not* buggy. What the ARM version count is the > number of parameters for the SMCCC function, *not* the number of > parameter for the call. > > This matches the SMCCC where the first parameter is always the > function ID, the last parameter is always the result structure. > > The code will end up to be less readable using a generic count. I am > planning to Nack anything trying to use a generic count in the SMCCC > code. Yes it is buggy, because it doesn't behave as the name suggests. If you mean the infrastructure to have SMCCC specific behaviour, the macros should be named suitably, to avoid interfering with common code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
Hi Andrew, On 02/10/2018 14:21, Andrew Cooper wrote: On 02/10/18 11:12, Jan Beulich wrote: --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -66,6 +66,10 @@ #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x +#define count_va_arg(args...) \ +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) This particular bit of review split out for obvious reasons. We already have __count_args() in the ARM SMCCC infrastructure. Please can we dedup that (broken out into a separate patch) rather than introducing a competing version. The ARM version is buggy. It is off-by-two in the base case, and doesn't compile if fewer than two parameters are passed. This version functions correctly, but should be named with a plural. The ARM version is *not* buggy. What the ARM version count is the number of parameters for the SMCCC function, *not* the number of parameter for the call. This matches the SMCCC where the first parameter is always the function ID, the last parameter is always the result structure. The code will end up to be less readable using a generic count. I am planning to Nack anything trying to use a generic count in the SMCCC code. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
On 02/10/18 11:12, Jan Beulich wrote: > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -66,6 +66,10 @@ > > #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) > > +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x > +#define count_va_arg(args...) \ > +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0) This particular bit of review split out for obvious reasons. We already have __count_args() in the ARM SMCCC infrastructure. Please can we dedup that (broken out into a separate patch) rather than introducing a competing version. The ARM version is buggy. It is off-by-two in the base case, and doesn't compile if fewer than two parameters are passed. This version functions correctly, but should be named with a plural. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 02/12] x86/HVM: patch indirect calls through hvm_funcs to direct ones
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 October 2018 11:13
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu
> Subject: [PATCH v4 02/12] x86/HVM: patch indirect calls through hvm_funcs
> to direct ones
>
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
> as well as nested, VM event, and altp2m ones (they can all be done
> later, if so desired). Virtual Interrupt delivery ones will be dealt
> with in a subsequent patch.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
> Reviewed-by: Wei Liu
> ---
> v3: Re-base.
> v2: Drop open-coded numbers from macro invocations. Re-base.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2104,7 +2104,7 @@ static int hvmemul_write_msr(
> static int hvmemul_wbinvd(
> struct x86_emulate_ctxt *ctxt)
> {
> -hvm_funcs.wbinvd_intercept();
> +alternative_vcall(hvm_funcs.wbinvd_intercept);
> return X86EMUL_OKAY;
> }
>
> @@ -2122,7 +2122,7 @@ static int hvmemul_get_fpu(
> struct vcpu *curr = current;
>
> if ( !curr->fpu_dirtied )
> -hvm_funcs.fpu_dirty_intercept();
> +alternative_vcall(hvm_funcs.fpu_dirty_intercept);
> else if ( type == X86EMUL_FPU_fpu )
> {
> const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
> @@ -2239,7 +2239,7 @@ static void hvmemul_put_fpu(
> {
> curr->fpu_dirtied = false;
> stts();
> -hvm_funcs.fpu_leave(curr);
> +alternative_vcall(hvm_funcs.fpu_leave, curr);
> }
> }
> }
> @@ -2401,7 +2401,8 @@ static int _hvm_emulate_one(struct hvm_e
> if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
> {
> hvmemul_ctxt->intr_shadow = new_intr_shadow;
> -hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
> +alternative_vcall(hvm_funcs.set_interrupt_shadow,
> + curr, new_intr_shadow);
> }
>
> if ( hvmemul_ctxt->ctxt.retire.hlt &&
> @@ -2538,7 +2539,8 @@ void hvm_emulate_init_once(
>
> memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
>
> -hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
> +hvmemul_ctxt->intr_shadow =
> +alternative_call(hvm_funcs.get_interrupt_shadow, curr);
> hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
> hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -272,12 +272,12 @@ void hvm_set_rdtsc_exiting(struct domain
> struct vcpu *v;
>
> for_each_vcpu ( d, v )
> -hvm_funcs.set_rdtsc_exiting(v, enable);
> +alternative_vcall(hvm_funcs.set_rdtsc_exiting, v, enable);
> }
>
> void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
> {
> -if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
> +if ( !alternative_call(hvm_funcs.get_guest_pat, v, guest_pat) )
> *guest_pat = v->arch.hvm.pat_cr;
> }
>
> @@ -302,7 +302,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
> return 0;
> }
>
> -if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
> +if ( !alternative_call(hvm_funcs.set_guest_pat, v, guest_pat) )
> v->arch.hvm.pat_cr = guest_pat;
>
> return 1;
> @@ -342,7 +342,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
> /* nothing, best effort only */;
> }
>
> -return hvm_funcs.set_guest_bndcfgs(v, val);
> +return alternative_call(hvm_funcs.set_guest_bndcfgs, v, val);
> }
>
> /*
> @@ -500,7 +500,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
> static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
> {
> info->cr2 = v->arch.hvm.guest_cr[2];
> -return hvm_funcs.get_pending_event(v, info);
> +
> +return alternative_call(hvm_funcs.get_pending_event, v, info);
> }
>
> void hvm_do_resume(struct vcpu *v)
> @@ -1651,7 +1652,7 @@ void hvm_inject_event(const struct x86_e
> }
> }
>
> -hvm_funcs.inject_event(event);
> +alternative_vcall(hvm_funcs.inject_event, event);
> }
>
> int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
> @@ -2238,7 +2239,7 @@ int hvm_set_cr0(unsigned long value, boo
> (!rangeset_is_empty(d->iomem_caps) ||
>!rangeset_is_empty(d->arch.ioport_caps) ||
>has_arch_pdevs(d)) )
> -hvm_funcs.handle_cd(v, value);
> +alternative_vcall(hvm_funcs.handle_cd, v, value);
>
> hvm_update_cr(v, 0, value);
>
> @@ -3477,7 +3478,8 @@ int hvm_msr_read_intercept(unsigned int
> goto gp_fault;
> /* If ret == 0 then this is not an MCE MSR, see other MSRs. */
> ret = ((ret == 0)
> - ? hvm_funcs.msr_read_intercept(msr, msr_content)
> + ? alternative_call(hvm_funcs.msr_read_intercept,
> + msr, msr_content)
> : X86EMUL_OKAY);
Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
Hi Jan, On 02/10/2018 12:58, Jan Beulich wrote: Well, that's what I would have done if you hadn't brought up the mixed-IOMMU case - clearly, without being able to test, I wouldn't have dared to try and implement patching of indirect calls for ARM. I can certainly drop that patch, but in the end it means you've made me do more work than would have been needed to reach the immediate goal I have. I have never asked you to re-arrange the code for Arm. I only asked to avoid patching indirect calls for Arm and explained why I wanted to avoid it. Sorry for the misunderstanding. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v3 0/4] x86/HVM: implement memory read caching
>>> On 02.10.18 at 12:51, wrote: > On 02/10/18 11:36, Jan Beulich wrote: > On 25.09.18 at 16:14, wrote: >>> Emulation requiring device model assistance uses a form of instruction >>> re-execution, assuming that the second (and any further) pass takes >>> exactly the same path. This is a valid assumption as far as use of CPU >>> registers goes (as those can't change without any other instruction >>> executing in between), but is wrong for memory accesses. In particular >>> it has been observed that Windows might page out buffers underneath >>> an instruction currently under emulation (hitting between two passes). >>> If the first pass translated a linear address successfully, any subsequent >>> pass needs to do so too, yielding the exact same translation. >>> >>> Introduce a cache (used just by guest page table accesses for now, i.e. >>> a form of "paging structure cache") to make sure above described >>> assumption holds. This is a very simplistic implementation for now: Only >>> exact matches are satisfied (no overlaps or partial reads or anything). >>> >>> There's also some seemingly unrelated cleanup here which was found >>> desirable on the way. >>> >>> 1: x86/mm: add optional cache to GLA->GFN translation >>> 2: x86/mm: use optional cache in guest_walk_tables() >>> 3: x86/HVM: implement memory read caching >>> 4: x86/HVM: prefill cache with PDPTEs when possible >>> >>> As for v2, I'm omitting "VMX: correct PDPTE load checks" from v3, as I >>> can't currently find enough time to carry out the requested further >>> rework. >> Andrew, George? > > You've not fixed anything from my concerns with v1. I've responded to your concerns verbally, and you went silent, as is (I regret having to say so) the case quite often. This simply blocks any progress. Hence, after enough time went by, I simply took the liberty to interpret the silence as "the verbal response took care of my concerns". > This doesn't behave like real hardware, and definitely doesn't behave as > named - "struct hvmemul_cache" is simply false. If it were named > hvmemul_psc (or some other variation on Paging Structure Cache) then it > wouldn't be so bad, as the individual levels do make more sense in that > context As previously pointed out (without any suggestion coming back from you), I chose the name "cache" for the lack of a better term. However, I certainly disagree with naming it PSC or some such, as its level zero is intentionally there to be eventually used for non-paging-structure data. > (not that it would make the behaviour any closer to how hardware > actually works). I can certainly appreciate this concern of yours, but the whole issue the series is aiming to address is something that we can't make behave like hardware does: Hardware doesn't have the concept of a device model that it needs to wait for responses from, while trying to make use of the wait time (i.e. scheduling in another CPU). Once again (I've said so more than once before) - the use of what I call cache here is a correctness thing, not a performance improvement (this, if it so happens, is just a nice side effect). Nothing like that exists on hardware; I'm merely trying to come close to paging structure caches. As to them - is it anywhere spelled out that their data must not come from memory, when doing a cache fill? We simply have no general purpose cache that the data could come from. > I'm also not overly happy with the conditional nature of the caching, or > that it isn't a transparent read-through cache. This leads to a large > amount of boilerplate code for every user. That's all fine, and I can understand it. Yet I hope you don't mean to ask that for this correctness fix to become acceptable, you demand that I implement a general purpose cache sitting transparently underneath all read/write operations? The more that it wouldn't even fulfill the purpose, as what the series introduces specifically also needs to be used for page tables living in MMIO (i.e. regardless of cachability of the memory accesses involved; I do realize that this doesn't currently function for other reasons, but it really should). As to the amount of boilerplate code: Besides expressing your dislike, do you have a concrete suggestion as to how you would envision this to be avoided in a way covering _all_ cases, i.e. in particular _all_ callers of guest_walk_tables() et al (i.e. all the functions the first two patches fiddle with)? If I had seen an obvious and natural way to achieve this, you may rest assured that I would have tried to avoid introducing the new function parameters, for which arguments need to be pushed through the various layers now. Furthermore I couldn't convince myself that doing this in a parameter-less way would be a good idea (and in the end provably correct): Of course we could make caches hang off of struct vcpu, but then we would need to find a model how to invalidate them often enough, without invalidating (parts of) them in ways breaking the
[Xen-devel] [libvirt test] 128304: tolerable all pass - PUSHED
flight 128304 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/128304/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128249 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128249 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 9f81dc1081bdf02b001083bbda7257bf24d3e604 baseline version: libvirt 199eee6aae7af3d813fbe98660c7e0fa1a8ae7b7 Last test of basis 128249 2018-09-30 04:37:46 Z2 days Testing same since 128304 2018-10-02 04:18:45 Z0 days1 attempts People who touched revisions under test: Daniel Veillard Fabiano Fidêncio Jim Fehlig John Ferlan Julio Faracco Ján Tomko Marc Hartmayer 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-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 199eee6aae..9f81dc1081 9f81dc1081bdf02b001083bbda7257bf24d3e604 -> xen-tested-master ___ Xen-devel mailing list
[Xen-devel] [xen-unstable test] 128281: regressions - FAIL
flight 128281 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/128281/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084 test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 128267 pass in 128281 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail pass in 128267 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128084 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128084 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128084 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128084 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128084 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 128084 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128084 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen edb4724e36256c495a6aa3cf1a12722efe271f9d baseline version: xen 940185b2f6f343251c2b83bd96e599398cea51ec Last test of basis 128084
Re: [Xen-devel] [PATCH v2] amd-iommu: use correct constants in amd_iommu_get_next_table_from_pte()...
Ping? Can I get an ack or otherwise from an AMD maintainer?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 26 September 2018 14:44
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH v2] amd-iommu: use correct constants in
> amd_iommu_get_next_table_from_pte()...
>
> ...and change the name to amd_iommu_get_address_from_pte() since the
> address read is not necessarily the address of a next level page table.
> (If the 'next level' field is not 1 - 6 then the address is a page
> address).
>
> The constants in use prior to this patch relate to device table entries
> rather than page table entries. Although they do have the same value, it
> makes the code confusing to read.
>
> This patch also changes the PDE/PTE pointer argument to void *, and
> removes any u32/uint32_t casts in the call sites. Unnecessary casts
> surrounding call sites are also removed.
>
> No functional change.
>
> NOTE: The patch also adds emacs boilerplate to iommu_map.c
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
> ---
> xen/drivers/passthrough/amd/iommu_map.c | 40 --
> -
> xen/drivers/passthrough/amd/pci_amd_iommu.c | 10 +++
> xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
> 3 files changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c
> b/xen/drivers/passthrough/amd/iommu_map.c
> index 70b4345b37..9fa5cd3bd3 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -285,19 +285,18 @@ void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id,
> u64 gcr3,
> dte[1] = entry;
> }
>
> -u64 amd_iommu_get_next_table_from_pte(u32 *entry)
> +uint64_t amd_iommu_get_address_from_pte(void *pte)
> {
> -u64 addr_lo, addr_hi, ptr;
> +uint32_t *entry = pte;
> +uint64_t addr_lo, addr_hi, ptr;
>
> -addr_lo = get_field_from_reg_u32(
> -entry[0],
> -IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_MASK,
> -IOMMU_DEV_TABLE_PAGE_TABLE_PTR_LOW_SHIFT);
> +addr_lo = get_field_from_reg_u32(entry[0],
> + IOMMU_PTE_ADDR_LOW_MASK,
> + IOMMU_PTE_ADDR_LOW_SHIFT);
>
> -addr_hi = get_field_from_reg_u32(
> -entry[1],
> -IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_MASK,
> -IOMMU_DEV_TABLE_PAGE_TABLE_PTR_HIGH_SHIFT);
> +addr_hi = get_field_from_reg_u32(entry[1],
> + IOMMU_PTE_ADDR_HIGH_MASK,
> + IOMMU_PTE_ADDR_HIGH_SHIFT);
>
> ptr = (addr_hi << 32) | (addr_lo << PAGE_SHIFT);
> return ptr;
> @@ -350,11 +349,11 @@ static int iommu_update_pde_count(struct domain *d,
> unsigned long pt_mfn,
> pde = table + pfn_to_pde_idx(gfn, merge_level);
>
> /* get page table of next level */
> -ntable_maddr = amd_iommu_get_next_table_from_pte((u32*)pde);
> +ntable_maddr = amd_iommu_get_address_from_pte(pde);
> ntable = map_domain_page(_mfn(paddr_to_pfn(ntable_maddr)));
>
> /* get the first mfn of next level */
> -first_mfn = amd_iommu_get_next_table_from_pte((u32*)ntable) >>
> PAGE_SHIFT;
> +first_mfn = amd_iommu_get_address_from_pte(ntable) >> PAGE_SHIFT;
>
> if ( first_mfn == 0 )
> goto out;
> @@ -401,7 +400,7 @@ static int iommu_merge_pages(struct domain *d,
> unsigned long pt_mfn,
> pde = table + pfn_to_pde_idx(gfn, merge_level);
>
> /* get first mfn */
> -ntable_mfn = amd_iommu_get_next_table_from_pte((u32*)pde) >>
> PAGE_SHIFT;
> +ntable_mfn = amd_iommu_get_address_from_pte(pde) >> PAGE_SHIFT;
>
> if ( ntable_mfn == 0 )
> {
> @@ -410,7 +409,7 @@ static int iommu_merge_pages(struct domain *d,
> unsigned long pt_mfn,
> }
>
> ntable = map_domain_page(_mfn(ntable_mfn));
> -first_mfn = amd_iommu_get_next_table_from_pte((u32*)ntable) >>
> PAGE_SHIFT;
> +first_mfn = amd_iommu_get_address_from_pte(ntable) >> PAGE_SHIFT;
>
> if ( first_mfn == 0 )
> {
> @@ -468,8 +467,7 @@ static int iommu_pde_from_gfn(struct domain *d,
> unsigned long pfn,
> pde = next_table_vaddr + pfn_to_pde_idx(pfn, level);
>
> /* Here might be a super page frame */
> -next_table_mfn =
> amd_iommu_get_next_table_from_pte((uint32_t*)pde)
> - >> PAGE_SHIFT;
> +next_table_mfn = amd_iommu_get_address_from_pte(pde) >>
> PAGE_SHIFT;
>
> /* Split super page frame into smaller pieces.*/
> if ( iommu_is_pte_present((u32*)pde) &&
> @@ -815,3 +813,13 @@ void amd_iommu_share_p2m(struct domain *d)
> mfn_x(pgd_mfn));
> }
> }
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git
Re: [Xen-devel] [PATCH] amd-iommu: get rid of pointless IOMMU_PAGING_MODE_LEVEL_X definitions
Ping? Can I get an ack or otherwise from an AMD maintainer?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 27 September 2018 13:46
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH] amd-iommu: get rid of pointless IOMMU_PAGING_MODE_LEVEL_X
> definitions
>
> The levels are absolute numbers such that IOMMU_PAGING_MODE_LEVEL_X
> evaluates to X (for the valid range of 0 - 7) so simply use numbers in
> the code.
>
> No functional change.
>
> NOTE: This patch also adds emacs boilerplate to amd-iommu-defs.h
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
> ---
> xen/drivers/passthrough/amd/iommu_map.c | 26 +++
> ---
> xen/drivers/passthrough/amd/pci_amd_iommu.c | 4 +---
> xen/include/asm-x86/hvm/svm/amd-iommu-defs.h | 21 +++--
> 3 files changed, 23 insertions(+), 28 deletions(-)
>
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c
> b/xen/drivers/passthrough/amd/iommu_map.c
> index 9fa5cd3bd3..ecd55d0573 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -40,7 +40,7 @@ void clear_iommu_pte_present(unsigned long l1_mfn,
> unsigned long gfn)
> u64 *table, *pte;
>
> table = map_domain_page(_mfn(l1_mfn));
> -pte = table + pfn_to_pde_idx(gfn, IOMMU_PAGING_MODE_LEVEL_1);
> +pte = table + pfn_to_pde_idx(gfn, 1);
> *pte = 0;
> unmap_domain_page(table);
> }
> @@ -84,7 +84,7 @@ static bool_t set_iommu_pde_present(u32 *pde, unsigned
> long next_mfn,
> /* FC bit should be enabled in PTE, this helps to solve potential
> * issues with ATS devices
> */
> -if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
> +if ( next_level == 0 )
> set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
> IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT,
> );
> pde[1] = entry;
> @@ -116,8 +116,7 @@ static bool_t set_iommu_pte_present(unsigned long
> pt_mfn, unsigned long gfn,
>
> pde = (u32*)(table + pfn_to_pde_idx(gfn, pde_level));
>
> -need_flush = set_iommu_pde_present(pde, next_mfn,
> - IOMMU_PAGING_MODE_LEVEL_0, iw,
> ir);
> +need_flush = set_iommu_pde_present(pde, next_mfn, 0, iw, ir);
> unmap_domain_page(table);
> return need_flush;
> }
> @@ -419,8 +418,7 @@ static int iommu_merge_pages(struct domain *d,
> unsigned long pt_mfn,
> }
>
> /* setup super page mapping, next level = 0 */
> -set_iommu_pde_present((u32*)pde, first_mfn,
> - IOMMU_PAGING_MODE_LEVEL_0,
> +set_iommu_pde_present((u32*)pde, first_mfn, 0,
>!!(flags & IOMMUF_writable),
>!!(flags & IOMMUF_readable));
>
> @@ -447,18 +445,17 @@ static int iommu_pde_from_gfn(struct domain *d,
> unsigned long pfn,
> table = hd->arch.root_table;
> level = hd->arch.paging_mode;
>
> -BUG_ON( table == NULL || level < IOMMU_PAGING_MODE_LEVEL_1 ||
> -level > IOMMU_PAGING_MODE_LEVEL_6 );
> +BUG_ON( table == NULL || level < 1 || level > 6 );
>
> next_table_mfn = mfn_x(page_to_mfn(table));
>
> -if ( level == IOMMU_PAGING_MODE_LEVEL_1 )
> +if ( level == 1 )
> {
> pt_mfn[level] = next_table_mfn;
> return 0;
> }
>
> -while ( level > IOMMU_PAGING_MODE_LEVEL_1 )
> +while ( level > 1 )
> {
> unsigned int next_level = level - 1;
> pt_mfn[level] = next_table_mfn;
> @@ -676,8 +673,7 @@ int amd_iommu_map_page(struct domain *d, unsigned long
> gfn, unsigned long mfn,
> }
>
> /* Install 4k mapping first */
> -need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn,
> - IOMMU_PAGING_MODE_LEVEL_1,
> +need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn, 1,
> !!(flags & IOMMUF_writable),
> !!(flags & IOMMUF_readable));
>
> @@ -690,8 +686,8 @@ int amd_iommu_map_page(struct domain *d, unsigned long
> gfn, unsigned long mfn,
> if ( is_hvm_domain(d) )
> amd_iommu_flush_pages(d, gfn, 0);
>
> -for ( merge_level = IOMMU_PAGING_MODE_LEVEL_2;
> - merge_level <= hd->arch.paging_mode; merge_level++ )
> +for ( merge_level = 2; merge_level <= hd->arch.paging_mode;
> + merge_level++ )
> {
> if ( pt_mfn[merge_level] == 0 )
> break;
> @@ -808,7 +804,7 @@ void amd_iommu_share_p2m(struct domain *d)
> hd->arch.root_table = p2m_table;
>
> /* When sharing p2m with iommu, paging mode = 4 */
> -hd->arch.paging_mode = IOMMU_PAGING_MODE_LEVEL_4;
> +hd->arch.paging_mode = 4;
> AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = %#lx\n",
> mfn_x(pgd_mfn));
>
Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
>>> On 02.10.18 at 13:00, wrote:
> On 02/10/2018 11:42, Jan Beulich wrote:
> On 02.10.18 at 12:38, wrote:
>>> On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls using the iommu_ops() return
value directly - all such calls need to have means (commonly a domain
pointer) to know the targeted IOMMU.
Disallow all hooks lacking such context for the time being, which in
effect is some dead code elimination for ARM. Once extended suitably,
individual of these hooks can be moved out of their guards again in the
future.
>>>
>>> While in theory it is possible to have platform with hetereneous IOMMUs.
>>>I don't see such such support coming in Xen for the foreseeable
>>> future. Note that even Linux does not support such case.
>>>
>>> This patch is going to make more complicate to unshare page-tables as
>>> now we would need to care of mixed case. So I would rather not set
>>> IOMMU_MIXED on Arm until we have a use case for it.
>>
>> Interesting. I essence this is the exact opposite of what you've
>> told me when I inquired about indirect call patching of the IOMMU
>> code. The sole purpose of this new option is to have a key off of
>> which I can tell whether to use patchable indirect calls or plain
>> ones.
>
> I don't think I am saying the opposite. I opened the door for mixed use
> case. It does not mean, I want to see half of the helpers dropped on Arm
> because you want them to be patchable. There are other way to do it.
I drop no helpers (or really hooks), I merely hide ones which can't
(currently) be used in mixed-IOMMU environments. And the
mixed-IOMMU case was what you've used to request that indirect
calls here not be patched for ARM.
>> I'm also not following how this change would complicate anything
>> for you. There's effectively no change for ARM, except for some
>> dead code not getting built anymore.
>
> Well, with your patch free_page_table, resume & co are under
> !IOMMU_MIXED. So they are unusable on Arm until we effectively rework
> the code to handle mixed case. More likely those callback will be
> necessary on Arm before mixed case. So I don't think this patch as such
> is what we want for Arm at the moment.
>
> I would much prefer if you drop IOMMU_MIXED and implement iommu_{v,}call
> on Arm as a iommu_ops->fun(...) (i.e no alternative for now). So call
> are still not patchable for Arm, yet we still have access to all IOMMU
> functions.
Well, that's what I would have done if you hadn't brought up the
mixed-IOMMU case - clearly, without being able to test, I wouldn't
have dared to try and implement patching of indirect calls for ARM.
I can certainly drop that patch, but in the end it means you've
made me do more work than would have been needed to reach
the immediate goal I have.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/4] tools/xen-hvmctx: drop bogus casts from dump_hpet()
Also specify field widths of the multiple similar lines printed in the
course of the loop, to help readability.
Make the iteration variable unsigned.
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -316,23 +316,20 @@ static void dump_rtc(void)
static void dump_hpet(void)
{
-int i;
HVM_SAVE_TYPE(HPET) h;
+unsigned int i;
+
READ(h);
-printf("HPET: capability %#llx config %#llx\n",
- (unsigned long long) h.capability,
- (unsigned long long) h.config);
-printf(" isr %#llx counter %#llx\n",
- (unsigned long long) h.isr,
- (unsigned long long) h.mc64);
+printf("HPET: capability %#" PRIx64 " config %#" PRIx64 "\n",
+ h.capability, h.config);
+printf(" isr %#" PRIx64 " counter %#" PRIx64 "\n",
+ h.isr, h.mc64);
for ( i = 0; i < HPET_TIMER_NUM; i++ )
{
-printf(" timer%i config %#llx cmp %#llx\n", i,
- (unsigned long long) h.timers[i].config,
- (unsigned long long) h.timers[i].cmp);
-printf(" timer%i period %#llx fsb %#llx\n", i,
- (unsigned long long) h.period[i],
- (unsigned long long) h.timers[i].fsb);
+printf(" timer%u config %#18.16" PRIx64 " cmp %#18.8" PRIx64
"\n",
+ i, h.timers[i].config, h.timers[i].cmp);
+printf(" timer%u period %#18.8" PRIx64 " fsb %#18.8" PRIx64
"\n",
+ i, h.period[i], h.timers[i].fsb);
}
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/4] tools/xen-hvmctx: drop bogus casts from dump_mtrr()
Also make the iteration variable unsigned.
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -344,19 +344,17 @@ static void dump_pmtimer(void)
static void dump_mtrr(void)
{
HVM_SAVE_TYPE(MTRR) p;
-int i;
+unsigned int i;
+
READ(p);
-printf("MTRR: PAT 0x%llx, cap 0x%llx, default 0x%llx\n",
- (unsigned long long) p.msr_pat_cr,
- (unsigned long long) p.msr_mtrr_cap,
- (unsigned long long) p.msr_mtrr_def_type);
+printf("MTRR: PAT %#" PRIx64 ", cap %#" PRIx64 ", default %#" PRIx64
"\n",
+ p.msr_pat_cr, p.msr_mtrr_cap, p.msr_mtrr_def_type);
for ( i = 0 ; i < MTRR_VCNT ; i++ )
-printf(" var %i 0x%16.16llx 0x%16.16llx\n", i,
- (unsigned long long) p.msr_mtrr_var[2 * i],
- (unsigned long long) p.msr_mtrr_var[2 * i + 1]);
+printf(" var %u %#18.13" PRIx64 " %#18.13" PRIx64 "\n", i,
+ p.msr_mtrr_var[2 * i], p.msr_mtrr_var[2 * i + 1]);
for ( i = 0 ; i < NUM_FIXED_MSR ; i++ )
-printf(" fixed %.2i 0x%16.16llx\n", i,
- (unsigned long long) p.msr_mtrr_fixed[i]);
+printf(" fixed %02x %#18.16" PRIx64 "\n",
+ i, p.msr_mtrr_fixed[i]);
}
static void dump_viridian_domain(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/4] tools/xen-hvmctx: drop bogus casts from dump_lapic_regs()
The casts weren't even to the right type - all LAPIC registers are
32-bit (pairs/groups of registers may be combined to form larger logical
ones, but this is not visible in the given data representation).
Signed-off-by: Jan Beulich
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -250,9 +250,9 @@ static void dump_lapic_regs(void)
printf("LAPIC registers:\n");
for ( i = 0 ; i < 0x400 ; i += 32 )
{
-printf(" 0x%4.4x: 0x%16.16llx 0x%4.4x: 0x%16.16llx\n",
- i, *(unsigned long long *)[i],
- i + 16, *(unsigned long long *)[i + 16]);
+printf(" 0x%03x: 0x%08" PRIx32 " 0x%03x: 0x%08" PRIx32 "\n",
+ i, *(uint32_t *)[i],
+ i + 16, *(uint32_t *)[i + 16]);
}
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/4] tools/xen-hvmctx: drop bogus casts from dump_cpu()
Also avoid printing the MSR flags (they're always zero as of commit 2f1add6e1c "x86/vmx: Don't leak host syscall MSR state into HVM guests"), and print FPU registers only when the respective flag indicates the space holds valid data. Adjust format specifiers a little at the same time, in particular to avoid at least some leading zeros to be printed when the positions can't ever be non-zero. This helps readability in my opinion. Signed-off-by: Jan Beulich --- a/tools/misc/xen-hvmctx.c +++ b/tools/misc/xen-hvmctx.c @@ -148,21 +148,20 @@ static void dump_cpu(void) "dr0 0x%16.16llx dr1 0x%16.16llx\n" "dr2 0x%16.16llx dr3 0x%16.16llx\n" "dr6 0x%16.16llx dr7 0x%16.16llx\n" - " cs 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " ds 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " es 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " fs 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " gs 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " ss 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " tr 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " ldtr 0x%8.8x (0x%16.16llx + 0x%8.8x / 0x%5.5x)\n" - " idtr(0x%16.16llx + 0x%8.8x)\n" - " gdtr(0x%16.16llx + 0x%8.8x)\n" + " cs %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " es %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " ds %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " fs %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " gs %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " ss %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.8" PRIx32 " / %#7.4" PRIx32 ")\n" + " tr %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.4" PRIx32 " / %#7.4" PRIx32 ")\n" + " ldtr %#6.4" PRIx32 " (%#18.8" PRIx64 " + %#10.4" PRIx32 " / %#7.4" PRIx32 ")\n" + " idtr(%#18.8" PRIx64 " + %#10.4" PRIx32 ")\n" + " gdtr(%#18.8" PRIx64 " + %#10.4" PRIx32 ")\n" "sysenter cs 0x%8.8llx eip 0x%16.16llx esp 0x%16.16llx\n" - " shadow gs 0x%16.16llx\n" - " MSR flags 0x%16.16llx lstar 0x%16.16llx\n" - " star 0x%16.16llx cstar 0x%16.16llx\n" - " sfmask 0x%16.16llx efer 0x%16.16llx\n" + " shadow gs %#18.16" PRIx64 " efer %#18.8" PRIx64 "\n" + " lstar %#18.16" PRIx64 " cstar %#18.16" PRIx64 "\n" + " star %#18.16" PRIx64 " sfmask %#18.8" PRIx64 "\n" "tsc 0x%16.16llx\n" " event 0x%8.8lx error 0x%8.8lx\n", (unsigned long long) c.rax, (unsigned long long) c.rbx, @@ -179,30 +178,27 @@ static void dump_cpu(void) (unsigned long long) c.dr0, (unsigned long long) c.dr1, (unsigned long long) c.dr2, (unsigned long long) c.dr3, (unsigned long long) c.dr6, (unsigned long long) c.dr7, - c.cs_sel, (unsigned long long) c.cs_base, c.cs_limit, c.cs_arbytes, - c.ds_sel, (unsigned long long) c.ds_base, c.ds_limit, c.ds_arbytes, - c.es_sel, (unsigned long long) c.es_base, c.es_limit, c.es_arbytes, - c.fs_sel, (unsigned long long) c.fs_base, c.fs_limit, c.fs_arbytes, - c.gs_sel, (unsigned long long) c.gs_base, c.gs_limit, c.gs_arbytes, - c.ss_sel, (unsigned long long) c.ss_base, c.ss_limit, c.ss_arbytes, - c.tr_sel, (unsigned long long) c.tr_base, c.tr_limit, c.tr_arbytes, - c.ldtr_sel, (unsigned long long) c.ldtr_base, - c.ldtr_limit, c.ldtr_arbytes, - (unsigned long long) c.idtr_base, c.idtr_limit, - (unsigned long long) c.gdtr_base, c.gdtr_limit, + c.cs_sel, c.cs_base, c.cs_limit, c.cs_arbytes, + c.ds_sel, c.ds_base, c.ds_limit, c.ds_arbytes, + c.es_sel, c.es_base, c.es_limit, c.es_arbytes, + c.fs_sel, c.fs_base, c.fs_limit, c.fs_arbytes, + c.gs_sel, c.gs_base, c.gs_limit, c.gs_arbytes, + c.ss_sel, c.ss_base, c.ss_limit, c.ss_arbytes, + c.tr_sel, c.tr_base, c.tr_limit, c.tr_arbytes, + c.ldtr_sel, c.ldtr_base, c.ldtr_limit, c.ldtr_arbytes, + c.idtr_base, c.idtr_limit, + c.gdtr_base, c.gdtr_limit, (unsigned long long) c.sysenter_cs, (unsigned long long) c.sysenter_eip, (unsigned long long) c.sysenter_esp, - (unsigned long long) c.shadow_gs, - (unsigned long
[Xen-devel] [PATCH 0/4] tools/xen-hvmctx: drop bogus casts
... and try to improve readability of some of the output. 1: drop bogus casts from dump_cpu() 2: drop bogus casts from dump_lapic_regs() 3: drop bogus casts from dump_hpet() 4: drop bogus casts from dump_mtrr() Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] amd/iommu: remove hidden AMD inclusive mappings
Roger,
On 10/2/18 3:08 PM, Roger Pau Monne wrote:
> And just rely on arch_iommu_hwdom_init to setup the correct inclusive
> mappings as it's done for Intel.
>
> AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up to
> max_pdx, remove this since it's now a duplication of
> arch_iommu_hwdom_init. Note that AMD mapped every page with a valid
> mfn up to max_pdx, arch_iommu_hwdom_init will only do so for memory
> below 4GB, so this is a functional change for AMD.
>
> Move the default setting of iommu_hwdom_{inclusive/reserved} to
> arch_iommu_hwdom_init since the defaults are now the same for both
> Intel and AMD.
>
> Reported-by: Paul Durrant
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Jan Beulich
> Reviewed-by: Kevin Tian
> ---
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
> Cc: Kevin Tian
> Cc: Jan Beulich
> Cc: Paul Durrant
> ---
> xen/drivers/passthrough/amd/pci_amd_iommu.c | 39 -
> xen/drivers/passthrough/vtd/iommu.c | 7
> xen/drivers/passthrough/x86/iommu.c | 8 -
> 3 files changed, 7 insertions(+), 47 deletions(-)
>
Acked-by: Suravee Suthikulpanit
Thanks,
Suravee
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 128278: regressions - FAIL
flight 128278 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/128278/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13
Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
Hi,
On 02/10/2018 11:42, Jan Beulich wrote:
On 02.10.18 at 12:38, wrote:
On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls using the iommu_ops() return
value directly - all such calls need to have means (commonly a domain
pointer) to know the targeted IOMMU.
Disallow all hooks lacking such context for the time being, which in
effect is some dead code elimination for ARM. Once extended suitably,
individual of these hooks can be moved out of their guards again in the
future.
While in theory it is possible to have platform with hetereneous IOMMUs.
I don't see such such support coming in Xen for the foreseeable
future. Note that even Linux does not support such case.
This patch is going to make more complicate to unshare page-tables as
now we would need to care of mixed case. So I would rather not set
IOMMU_MIXED on Arm until we have a use case for it.
Interesting. I essence this is the exact opposite of what you've
told me when I inquired about indirect call patching of the IOMMU
code. The sole purpose of this new option is to have a key off of
which I can tell whether to use patchable indirect calls or plain
ones.
I don't think I am saying the opposite. I opened the door for mixed use
case. It does not mean, I want to see half of the helpers dropped on Arm
because you want them to be patchable. There are other way to do it.
I'm also not following how this change would complicate anything
for you. There's effectively no change for ARM, except for some
dead code not getting built anymore.
Well, with your patch free_page_table, resume & co are under
!IOMMU_MIXED. So they are unusable on Arm until we effectively rework
the code to handle mixed case. More likely those callback will be
necessary on Arm before mixed case. So I don't think this patch as such
is what we want for Arm at the moment.
I would much prefer if you drop IOMMU_MIXED and implement iommu_{v,}call
on Arm as a iommu_ops->fun(...) (i.e no alternative for now). So call
are still not patchable for Arm, yet we still have access to all IOMMU
functions.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH v3 0/4] x86/HVM: implement memory read caching
On 02/10/18 11:36, Jan Beulich wrote: On 25.09.18 at 16:14, wrote: >> Emulation requiring device model assistance uses a form of instruction >> re-execution, assuming that the second (and any further) pass takes >> exactly the same path. This is a valid assumption as far as use of CPU >> registers goes (as those can't change without any other instruction >> executing in between), but is wrong for memory accesses. In particular >> it has been observed that Windows might page out buffers underneath >> an instruction currently under emulation (hitting between two passes). >> If the first pass translated a linear address successfully, any subsequent >> pass needs to do so too, yielding the exact same translation. >> >> Introduce a cache (used just by guest page table accesses for now, i.e. >> a form of "paging structure cache") to make sure above described >> assumption holds. This is a very simplistic implementation for now: Only >> exact matches are satisfied (no overlaps or partial reads or anything). >> >> There's also some seemingly unrelated cleanup here which was found >> desirable on the way. >> >> 1: x86/mm: add optional cache to GLA->GFN translation >> 2: x86/mm: use optional cache in guest_walk_tables() >> 3: x86/HVM: implement memory read caching >> 4: x86/HVM: prefill cache with PDPTEs when possible >> >> As for v2, I'm omitting "VMX: correct PDPTE load checks" from v3, as I >> can't currently find enough time to carry out the requested further >> rework. > Andrew, George? You've not fixed anything from my concerns with v1. This doesn't behave like real hardware, and definitely doesn't behave as named - "struct hvmemul_cache" is simply false. If it were named hvmemul_psc (or some other variation on Paging Structure Cache) then it wouldn't be so bad, as the individual levels do make more sense in that context (not that it would make the behaviour any closer to how hardware actually works). I'm also not overly happy with the conditional nature of the caching, or that it isn't a transparent read-through cache. This leads to a large amount of boilerplate code for every user. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
>>> On 02.10.18 at 12:38, wrote: > On 02/10/2018 11:18, Jan Beulich wrote: >> ARM is intended to gain support for heterogeneous IOMMUs on a single >> system. This not only disallows boot time replacement of respective >> indirect calls (handling of which is the main goal of the introduction >> here), but more generally disallows calls using the iommu_ops() return >> value directly - all such calls need to have means (commonly a domain >> pointer) to know the targeted IOMMU. >> >> Disallow all hooks lacking such context for the time being, which in >> effect is some dead code elimination for ARM. Once extended suitably, >> individual of these hooks can be moved out of their guards again in the >> future. > > While in theory it is possible to have platform with hetereneous IOMMUs. > I don't see such such support coming in Xen for the foreseeable > future. Note that even Linux does not support such case. > > This patch is going to make more complicate to unshare page-tables as > now we would need to care of mixed case. So I would rather not set > IOMMU_MIXED on Arm until we have a use case for it. Interesting. I essence this is the exact opposite of what you've told me when I inquired about indirect call patching of the IOMMU code. The sole purpose of this new option is to have a key off of which I can tell whether to use patchable indirect calls or plain ones. I'm also not following how this change would complicate anything for you. There's effectively no change for ARM, except for some dead code not getting built anymore. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 128291: tolerable FAIL - PUSHED
flight 128291 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/128291/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128215 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128215 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128215 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128215 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128215 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuua2ef4d9e95400cd387ab4ae19a317741e458fb07 baseline version: qemuu042938f46e1c477419d1931381fdadffaa49d45e Last test of basis 128215 2018-09-29 02:08:34 Z3 days Failing since128274 2018-10-01 08:36:57 Z1 days2 attempts Testing same since 128291 2018-10-01 18:07:26 Z0 days1 attempts People who touched revisions under test: Bandan Bandan Das Emilio G. Cota Eric Blake Gerd Hoffmann John Snow Marc-André Lureau Miguel GAIO Peter Maydell Peter Wu Richard Henderson Roman Kapl Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
[Xen-devel] Ping: [PATCH v3 3/4] x86/HVM: implement memory read caching
>>> On 25.09.18 at 16:25, wrote:
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far use of CPU
> registers goes (as those can't change without any other instruction
> executing in between), but is wrong for memory accesses. In particular
> it has been observed that Windows might page out buffers underneath an
> instruction currently under emulation (hitting between two passes). If
> the first pass translated a linear address successfully, any subsequent
> pass needs to do so too, yielding the exact same translation.
>
> Introduce a cache (used by just guest page table accesses for now) to
> make sure above described assumption holds. This is a very simplistic
> implementation for now: Only exact matches are satisfied (no overlaps or
> partial reads or anything).
>
> As to the actual data page in this scenario, there are a couple of
> aspects to take into consideration:
> - We must be talking about an insn accessing two locations (two memory
> ones, one of which is MMIO, or a memory and an I/O one).
> - If the non I/O / MMIO side is being read, the re-read (if it occurs at
> all) is having its result discarded, by taking the shortcut through
> the first switch()'s STATE_IORESP_READY case in hvmemul_do_io(). Note
> how, among all the re-issue sanity checks there, we avoid comparing
> the actual data.
> - If the non I/O / MMIO side is being written, it is the OSes
> responsibility to avoid actually moving page contents to disk while
> there might still be a write access in flight - this is no different
> in behavior from bare hardware.
> - Read-modify-write accesses are, as always, complicated, and while we
> deal with them better nowadays than we did in the past, we're still
> not quite there to guarantee hardware like behavior in all cases
> anyway. Nothing is getting worse by the changes made here, afaict.
>
> Signed-off-by: Jan Beulich
> Acked-by: Tim Deegan
> Reviewed-by: Paul Durrant
SVM and VMX maintainers?
Thanks, Jan
> ---
> v3: Add text about the actual data page to the description.
> v2: Re-base.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -27,6 +27,18 @@
> #include
> #include
>
> +struct hvmemul_cache
> +{
> +unsigned int max_ents;
> +unsigned int num_ents;
> +struct {
> +paddr_t gpa:PADDR_BITS;
> +unsigned int size:(BITS_PER_LONG - PADDR_BITS) / 2;
> +unsigned int level:(BITS_PER_LONG - PADDR_BITS) / 2;
> +unsigned long data;
> +} ents[];
> +};
> +
> static void hvmtrace_io_assist(const ioreq_t *p)
> {
> unsigned int size, event;
> @@ -541,7 +553,7 @@ static int hvmemul_do_mmio_addr(paddr_t
> */
> static void *hvmemul_map_linear_addr(
> unsigned long linear, unsigned int bytes, uint32_t pfec,
> -struct hvm_emulate_ctxt *hvmemul_ctxt)
> +struct hvm_emulate_ctxt *hvmemul_ctxt, struct hvmemul_cache *cache)
> {
> struct vcpu *curr = current;
> void *err, *mapping;
> @@ -586,7 +598,7 @@ static void *hvmemul_map_linear_addr(
> ASSERT(mfn_x(*mfn) == 0);
>
> res = hvm_translate_get_page(curr, addr, true, pfec,
> - , , NULL, );
> + , , NULL, , cache);
>
> switch ( res )
> {
> @@ -702,6 +714,8 @@ static int hvmemul_linear_to_phys(
> gfn_t gfn, ngfn;
> unsigned long done, todo, i, offset = addr & ~PAGE_MASK;
> int reverse;
> +struct hvmemul_cache *cache = pfec & PFEC_insn_fetch
> + ? NULL : curr->arch.hvm.data_cache;
>
> /*
> * Clip repetitions to a sensible maximum. This avoids extensive
> looping in
> @@ -731,7 +745,7 @@ static int hvmemul_linear_to_phys(
> return rc;
> gfn = gaddr_to_gfn(gaddr);
> }
> -else if ( gfn_eq(gfn = paging_gla_to_gfn(curr, addr, , NULL),
> +else if ( gfn_eq(gfn = paging_gla_to_gfn(curr, addr, , cache),
> INVALID_GFN) )
> {
> if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> @@ -747,7 +761,7 @@ static int hvmemul_linear_to_phys(
> {
> /* Get the next PFN in the range. */
> addr += reverse ? -PAGE_SIZE : PAGE_SIZE;
> -ngfn = paging_gla_to_gfn(curr, addr, , NULL);
> +ngfn = paging_gla_to_gfn(curr, addr, , cache);
>
> /* Is it contiguous with the preceding PFNs? If not then we're
> done. */
> if ( gfn_eq(ngfn, INVALID_GFN) ||
> @@ -1073,7 +1087,10 @@ static int linear_read(unsigned long add
> uint32_t pfec, struct hvm_emulate_ctxt
> *hvmemul_ctxt)
> {
> pagefault_info_t pfinfo;
> -int rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
> +int rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ,
> +
Re: [Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
Hi,
On 02/10/2018 11:18, Jan Beulich wrote:
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls using the iommu_ops() return
value directly - all such calls need to have means (commonly a domain
pointer) to know the targeted IOMMU.
Disallow all hooks lacking such context for the time being, which in
effect is some dead code elimination for ARM. Once extended suitably,
individual of these hooks can be moved out of their guards again in the
future.
While in theory it is possible to have platform with hetereneous IOMMUs.
I don't see such such support coming in Xen for the foreseeable
future. Note that even Linux does not support such case.
This patch is going to make more complicate to unshare page-tables as
now we would need to care of mixed case. So I would rather not set
IOMMU_MIXED on Arm until we have a use case for it.
Cheers,
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
select HAS_DEVICE_TREE
select HAS_PASSTHROUGH
select HAS_PDX
+ select IOMMU_MIXED
config ARCH_DEFCONFIG
string
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -938,7 +938,7 @@ static int construct_memop_from_reservat
return 0;
}
-#ifdef CONFIG_HAS_PASSTHROUGH
+#if defined(CONFIG_HAS_PASSTHROUGH) && !defined(CONFIG_IOMMU_MIXED)
struct get_reserved_device_memory {
struct xen_reserved_device_memory_map map;
unsigned int used_entries;
@@ -1550,7 +1550,7 @@ long do_memory_op(unsigned long cmd, XEN
break;
}
-#ifdef CONFIG_HAS_PASSTHROUGH
+#if defined(CONFIG_HAS_PASSTHROUGH) && !defined(CONFIG_IOMMU_MIXED)
case XENMEM_reserved_device_memory_map:
{
struct get_reserved_device_memory grdm;
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -2,6 +2,9 @@
config HAS_PASSTHROUGH
bool
+config IOMMU_MIXED
+ bool
+
if ARM
config ARM_SMMU
bool "ARM SMMUv1 and v2 driver"
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -77,9 +77,11 @@ bool_t __read_mostly amd_iommu_perdev_in
DEFINE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
+#ifndef CONFIG_IOMMU_MIXED
DEFINE_SPINLOCK(iommu_pt_cleanup_lock);
PAGE_LIST_HEAD(iommu_pt_cleanup_list);
static struct tasklet iommu_pt_cleanup_tasklet;
+#endif
static int __init parse_iommu_param(const char *s)
{
@@ -246,7 +248,9 @@ void iommu_teardown(struct domain *d)
d->need_iommu = 0;
hd->platform_ops->teardown(d);
+#ifndef CONFIG_IOMMU_MIXED
tasklet_schedule(_pt_cleanup_tasklet);
+#endif
}
int iommu_construct(struct domain *d)
@@ -332,6 +336,7 @@ int iommu_unmap_page(struct domain *d, u
return rc;
}
+#ifndef CONFIG_IOMMU_MIXED
static void iommu_free_pagetables(unsigned long unused)
{
do {
@@ -348,6 +353,7 @@ static void iommu_free_pagetables(unsign
tasklet_schedule_on_cpu(_pt_cleanup_tasklet,
cpumask_cycle(smp_processor_id(),
_online_map));
}
+#endif
int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
@@ -433,12 +439,15 @@ int __init iommu_setup(void)
iommu_hwdom_passthrough ? "Passthrough" :
iommu_hwdom_strict ? "Strict" : "Relaxed");
printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" :
"dis");
+#ifndef CONFIG_IOMMU_MIXED
tasklet_init(_pt_cleanup_tasklet, iommu_free_pagetables, 0);
+#endif
}
return rc;
}
+#ifndef CONFIG_IOMMU_MIXED
int iommu_suspend()
{
if ( iommu_enabled )
@@ -453,27 +462,6 @@ void iommu_resume()
iommu_get_ops()->resume();
}
-int iommu_do_domctl(
-struct xen_domctl *domctl, struct domain *d,
-XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
-{
-int ret = -ENODEV;
-
-if ( !iommu_enabled )
-return -ENOSYS;
-
-#ifdef CONFIG_HAS_PCI
-ret = iommu_do_pci_domctl(domctl, d, u_domctl);
-#endif
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-if ( ret == -ENODEV )
-ret = iommu_do_dt_domctl(domctl, d, u_domctl);
-#endif
-
-return ret;
-}
-
void iommu_share_p2m_table(struct domain* d)
{
if ( iommu_enabled && iommu_use_hap_pt(d) )
@@ -500,6 +488,28 @@ int iommu_get_reserved_device_memory(iom
return ops->get_reserved_device_memory(func, ctxt);
}
+#endif
+
+int iommu_do_domctl(
+struct xen_domctl *domctl, struct domain *d,
+XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+int ret = -ENODEV;
+
+if ( !iommu_enabled )
+return -ENOSYS;
+
+#ifdef CONFIG_HAS_PCI
+ret = iommu_do_pci_domctl(domctl, d, u_domctl);
+#endif
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+if ( ret ==
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
On Tue, 2018-10-02 at 11:06 +0100, George Dunlap wrote: > On 10/01/2018 06:58 PM, Dario Faggioli wrote: > > > > George, let me know if you're working on a fix already, or if I > > should > > do that myself. > > I reverted the credit2 default; but really we need to have a design > discussion about what we want the overall behavior to be. It's not > simple or obvious. > Ok. As saying to Jan, I'm starting to think that there is very few that we can do, without risking of actively stomping on our own users' feet. I mean, if someone wants to migrate a VM between a Credit and a Credit2 box, or between a Credit2 and RTDS box, who are we to forbid him/her to do it? So, basically, I'd make sure that the mismatch is being noticed, but nothing more than that (i.e., I'd print a warning, and ignore the parameters). Of course, if the two hosts do have the same scheduler, I think it does makes sense to re-apply the parameters them VM had on the source host (principle of least surprise, etc). I appreciate that there is the risk that one may have chosen RTDS, then forgot, and not set sched=rtds on destination, and get an apparently weird result... But I'd argue that if you are changing scheduler, you're doing it for a reason, and it's unlikely you don't pay attention to that when playing with migration. Anyway, I'm not working this afternoon. So ping me on IRC tomorrow, if you want to discuss this there. Or we can just go on via email, of course. :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Ping: [PATCH v3 0/4] x86/HVM: implement memory read caching
>>> On 25.09.18 at 16:14, wrote: > Emulation requiring device model assistance uses a form of instruction > re-execution, assuming that the second (and any further) pass takes > exactly the same path. This is a valid assumption as far as use of CPU > registers goes (as those can't change without any other instruction > executing in between), but is wrong for memory accesses. In particular > it has been observed that Windows might page out buffers underneath > an instruction currently under emulation (hitting between two passes). > If the first pass translated a linear address successfully, any subsequent > pass needs to do so too, yielding the exact same translation. > > Introduce a cache (used just by guest page table accesses for now, i.e. > a form of "paging structure cache") to make sure above described > assumption holds. This is a very simplistic implementation for now: Only > exact matches are satisfied (no overlaps or partial reads or anything). > > There's also some seemingly unrelated cleanup here which was found > desirable on the way. > > 1: x86/mm: add optional cache to GLA->GFN translation > 2: x86/mm: use optional cache in guest_walk_tables() > 3: x86/HVM: implement memory read caching > 4: x86/HVM: prefill cache with PDPTEs when possible > > As for v2, I'm omitting "VMX: correct PDPTE load checks" from v3, as I > can't currently find enough time to carry out the requested further > rework. Andrew, George? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 12/12] IOMMU: patch certain indirect calls to direct ones
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -228,7 +228,8 @@ void __hwdom_init iommu_hwdom_init(struc
== PGT_writable_page) )
mapping |= IOMMUF_writable;
-ret = hd->platform_ops->map_page(d, gfn, mfn, mapping);
+ret = iommu_call(hd->platform_ops, map_page,
+ d, gfn, mfn, mapping);
if ( !rc )
rc = ret;
@@ -300,7 +301,7 @@ int iommu_map_page(struct domain *d, uns
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+rc = iommu_call(hd->platform_ops, map_page, d, gfn, mfn, flags);
if ( unlikely(rc) )
{
if ( !d->is_shutting_down && printk_ratelimit() )
@@ -323,7 +324,7 @@ int iommu_unmap_page(struct domain *d, u
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-rc = hd->platform_ops->unmap_page(d, gfn);
+rc = iommu_call(hd->platform_ops, unmap_page, d, gfn);
if ( unlikely(rc) )
{
if ( !d->is_shutting_down && printk_ratelimit() )
@@ -349,7 +350,7 @@ static void iommu_free_pagetables(unsign
spin_unlock(_pt_cleanup_lock);
if ( !pg )
return;
-iommu_get_ops()->free_page_table(pg);
+iommu_vcall(iommu_get_ops(), free_page_table, pg);
} while ( !softirq_pending(smp_processor_id()) );
tasklet_schedule_on_cpu(_pt_cleanup_tasklet,
@@ -366,7 +367,7 @@ int iommu_iotlb_flush(struct domain *d,
if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush
)
return 0;
-rc = hd->platform_ops->iotlb_flush(d, gfn, page_count);
+rc = iommu_call(hd->platform_ops, iotlb_flush, d, gfn, page_count);
if ( unlikely(rc) )
{
if ( !d->is_shutting_down && printk_ratelimit() )
@@ -389,7 +390,7 @@ int iommu_iotlb_flush_all(struct domain
if ( !iommu_enabled || !hd->platform_ops ||
!hd->platform_ops->iotlb_flush_all )
return 0;
-rc = hd->platform_ops->iotlb_flush_all(d);
+rc = iommu_call(hd->platform_ops, iotlb_flush_all, d);
if ( unlikely(rc) )
{
if ( !d->is_shutting_down && printk_ratelimit() )
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1301,14 +1301,14 @@ int iommu_update_ire_from_msi(
struct msi_desc *msi_desc, struct msi_msg *msg)
{
return iommu_intremap
- ? iommu_get_ops()->update_ire_from_msi(msi_desc, msg) : 0;
+ ? iommu_call(iommu_ops, update_ire_from_msi, msi_desc, msg) : 0;
}
void iommu_read_msi_from_ire(
struct msi_desc *msi_desc, struct msi_msg *msg)
{
if ( iommu_intremap )
-iommu_get_ops()->read_msi_from_ire(msi_desc, msg);
+iommu_vcall(iommu_ops, read_msi_from_ire, msi_desc, msg);
}
static int iommu_add_device(struct pci_dev *pdev)
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -26,14 +26,12 @@
void iommu_update_ire_from_apic(
unsigned int apic, unsigned int reg, unsigned int value)
{
-const struct iommu_ops *ops = iommu_get_ops();
-ops->update_ire_from_apic(apic, reg, value);
+iommu_vcall(iommu_ops, update_ire_from_apic, apic, reg, value);
}
unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg)
{
-const struct iommu_ops *ops = iommu_get_ops();
-return ops->read_apic_from_ire(apic, reg);
+return iommu_call(iommu_ops, read_apic_from_ire, apic, reg);
}
int __init iommu_setup_hpet_msi(struct msi_desc *msi)
@@ -44,7 +42,6 @@ int __init iommu_setup_hpet_msi(struct m
int arch_iommu_populate_page_table(struct domain *d)
{
-const struct domain_iommu *hd = dom_iommu(d);
struct page_info *page;
int rc = 0, n = 0;
@@ -68,9 +65,8 @@ int arch_iommu_populate_page_table(struc
{
ASSERT(!(gfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
BUG_ON(SHARED_M2P(gfn));
-rc = hd->platform_ops->map_page(d, gfn, mfn,
-IOMMUF_readable |
-IOMMUF_writable);
+rc = iommu_call(iommu_ops, map_page, d, gfn, mfn,
+IOMMUF_readable | IOMMUF_writable);
}
if ( rc )
{
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -176,9 +176,17 @@ struct iommu_ops {
void (*dump_p2m_table)(struct domain *d);
};
-#ifndef CONFIG_IOMMU_MIXED
+#ifdef CONFIG_IOMMU_MIXED
+# define iommu_call(ops, fn, args...) ((ops)->fn(args))
+# define iommu_vcall iommu_call
+#else
+# include
+
extern struct iommu_ops iommu_ops;
+# define iommu_call(ops, fn, args...) alternative_call(iommu_ops.fn, ## args)
+# define iommu_vcall(ops, fn,
[Xen-devel] [PATCH v4 11/12] IOMMU: remove indirection from certain IOMMU hook accesses
In !IOMMU_MIXED mode there's no need to go through an extra level of
indirection. In order to limit code churn, call sites using struct
domain_iommu's platform_ops don't get touched here, however.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -29,6 +29,8 @@
static bool_t __read_mostly init_done;
+static const struct iommu_ops amd_iommu_ops;
+
struct amd_iommu *find_iommu_for_device(int seg, int bdf)
{
struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
@@ -182,6 +184,8 @@ int __init amd_iov_detect(void)
return -ENODEV;
}
+iommu_ops = amd_iommu_ops;
+
if ( amd_iommu_init() != 0 )
{
printk("AMD-Vi: Error initialization\n");
@@ -607,7 +611,7 @@ static void amd_dump_p2m_table(struct do
amd_dump_p2m_table_level(hd->arch.root_table, hd->arch.paging_mode, 0, 0);
}
-const struct iommu_ops amd_iommu_ops = {
+static const struct iommu_ops __initconstrel amd_iommu_ops = {
.init = amd_iommu_domain_init,
.hwdom_init = amd_iommu_hwdom_init,
.add_device = amd_iommu_add_device,
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -78,6 +78,8 @@ bool_t __read_mostly amd_iommu_perdev_in
DEFINE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
#ifndef CONFIG_IOMMU_MIXED
+struct iommu_ops iommu_ops;
+
DEFINE_SPINLOCK(iommu_pt_cleanup_lock);
PAGE_LIST_HEAD(iommu_pt_cleanup_list);
static struct tasklet iommu_pt_cleanup_tasklet;
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -27,6 +27,7 @@
struct pci_ats_dev;
extern bool_t rwbf_quirk;
+extern const struct iommu_ops intel_iommu_ops;
void print_iommu_regs(struct acpi_drhd_unit *drhd);
void print_vtd_entries(struct iommu *iommu, int bus, int devfn, u64 gmfn);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -897,6 +897,8 @@ int iommu_enable_x2apic_IR(void)
else if ( !x2apic_enabled )
return -EOPNOTSUPP;
+iommu_ops = intel_iommu_ops;
+
for_each_drhd_unit ( drhd )
{
iommu = drhd->iommu;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2251,6 +2251,8 @@ int __init intel_vtd_setup(void)
goto error;
}
+iommu_ops = intel_iommu_ops;
+
/* We enable the following features only if they are supported by all VT-d
* engines: Snoop Control, DMA passthrough, Queued Invalidation, Interrupt
* Remapping, and Posted Interrupt
@@ -2650,7 +2652,7 @@ static void vtd_dump_p2m_table(struct do
vtd_dump_p2m_table_level(hd->arch.pgd_maddr, agaw_to_level(hd->arch.agaw),
0, 0);
}
-const struct iommu_ops intel_iommu_ops = {
+const struct iommu_ops __initconstrel intel_iommu_ops = {
.init = intel_iommu_domain_init,
.hwdom_init = intel_iommu_hwdom_init,
.add_device = intel_iommu_add_device,
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -44,26 +44,9 @@ struct arch_iommu
struct guest_iommu *g_iommu;
};
-extern const struct iommu_ops intel_iommu_ops;
-extern const struct iommu_ops amd_iommu_ops;
int intel_vtd_setup(void);
int amd_iov_detect(void);
-static inline const struct iommu_ops *iommu_get_ops(void)
-{
-switch ( boot_cpu_data.x86_vendor )
-{
-case X86_VENDOR_INTEL:
-return _iommu_ops;
-case X86_VENDOR_AMD:
-return _iommu_ops;
-}
-
-BUG();
-
-return NULL;
-}
-
static inline int iommu_hardware_setup(void)
{
switch ( boot_cpu_data.x86_vendor )
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -176,6 +176,16 @@ struct iommu_ops {
void (*dump_p2m_table)(struct domain *d);
};
+#ifndef CONFIG_IOMMU_MIXED
+extern struct iommu_ops iommu_ops;
+
+static inline const struct iommu_ops *iommu_get_ops(void)
+{
+BUG_ON(!iommu_ops.init);
+return _ops;
+}
+#endif
+
int __must_check iommu_suspend(void);
void iommu_resume(void);
void iommu_crash_shutdown(void);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 10/12] IOMMU: introduce IOMMU_MIXED config option
ARM is intended to gain support for heterogeneous IOMMUs on a single
system. This not only disallows boot time replacement of respective
indirect calls (handling of which is the main goal of the introduction
here), but more generally disallows calls using the iommu_ops() return
value directly - all such calls need to have means (commonly a domain
pointer) to know the targeted IOMMU.
Disallow all hooks lacking such context for the time being, which in
effect is some dead code elimination for ARM. Once extended suitably,
individual of these hooks can be moved out of their guards again in the
future.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
select HAS_DEVICE_TREE
select HAS_PASSTHROUGH
select HAS_PDX
+ select IOMMU_MIXED
config ARCH_DEFCONFIG
string
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -938,7 +938,7 @@ static int construct_memop_from_reservat
return 0;
}
-#ifdef CONFIG_HAS_PASSTHROUGH
+#if defined(CONFIG_HAS_PASSTHROUGH) && !defined(CONFIG_IOMMU_MIXED)
struct get_reserved_device_memory {
struct xen_reserved_device_memory_map map;
unsigned int used_entries;
@@ -1550,7 +1550,7 @@ long do_memory_op(unsigned long cmd, XEN
break;
}
-#ifdef CONFIG_HAS_PASSTHROUGH
+#if defined(CONFIG_HAS_PASSTHROUGH) && !defined(CONFIG_IOMMU_MIXED)
case XENMEM_reserved_device_memory_map:
{
struct get_reserved_device_memory grdm;
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -2,6 +2,9 @@
config HAS_PASSTHROUGH
bool
+config IOMMU_MIXED
+ bool
+
if ARM
config ARM_SMMU
bool "ARM SMMUv1 and v2 driver"
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -77,9 +77,11 @@ bool_t __read_mostly amd_iommu_perdev_in
DEFINE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
+#ifndef CONFIG_IOMMU_MIXED
DEFINE_SPINLOCK(iommu_pt_cleanup_lock);
PAGE_LIST_HEAD(iommu_pt_cleanup_list);
static struct tasklet iommu_pt_cleanup_tasklet;
+#endif
static int __init parse_iommu_param(const char *s)
{
@@ -246,7 +248,9 @@ void iommu_teardown(struct domain *d)
d->need_iommu = 0;
hd->platform_ops->teardown(d);
+#ifndef CONFIG_IOMMU_MIXED
tasklet_schedule(_pt_cleanup_tasklet);
+#endif
}
int iommu_construct(struct domain *d)
@@ -332,6 +336,7 @@ int iommu_unmap_page(struct domain *d, u
return rc;
}
+#ifndef CONFIG_IOMMU_MIXED
static void iommu_free_pagetables(unsigned long unused)
{
do {
@@ -348,6 +353,7 @@ static void iommu_free_pagetables(unsign
tasklet_schedule_on_cpu(_pt_cleanup_tasklet,
cpumask_cycle(smp_processor_id(),
_online_map));
}
+#endif
int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
@@ -433,12 +439,15 @@ int __init iommu_setup(void)
iommu_hwdom_passthrough ? "Passthrough" :
iommu_hwdom_strict ? "Strict" : "Relaxed");
printk("Interrupt remapping %sabled\n", iommu_intremap ? "en" : "dis");
+#ifndef CONFIG_IOMMU_MIXED
tasklet_init(_pt_cleanup_tasklet, iommu_free_pagetables, 0);
+#endif
}
return rc;
}
+#ifndef CONFIG_IOMMU_MIXED
int iommu_suspend()
{
if ( iommu_enabled )
@@ -453,27 +462,6 @@ void iommu_resume()
iommu_get_ops()->resume();
}
-int iommu_do_domctl(
-struct xen_domctl *domctl, struct domain *d,
-XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
-{
-int ret = -ENODEV;
-
-if ( !iommu_enabled )
-return -ENOSYS;
-
-#ifdef CONFIG_HAS_PCI
-ret = iommu_do_pci_domctl(domctl, d, u_domctl);
-#endif
-
-#ifdef CONFIG_HAS_DEVICE_TREE
-if ( ret == -ENODEV )
-ret = iommu_do_dt_domctl(domctl, d, u_domctl);
-#endif
-
-return ret;
-}
-
void iommu_share_p2m_table(struct domain* d)
{
if ( iommu_enabled && iommu_use_hap_pt(d) )
@@ -500,6 +488,28 @@ int iommu_get_reserved_device_memory(iom
return ops->get_reserved_device_memory(func, ctxt);
}
+#endif
+
+int iommu_do_domctl(
+struct xen_domctl *domctl, struct domain *d,
+XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
+{
+int ret = -ENODEV;
+
+if ( !iommu_enabled )
+return -ENOSYS;
+
+#ifdef CONFIG_HAS_PCI
+ret = iommu_do_pci_domctl(domctl, d, u_domctl);
+#endif
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+if ( ret == -ENODEV )
+ret = iommu_do_dt_domctl(domctl, d, u_domctl);
+#endif
+
+return ret;
+}
bool_t iommu_has_feature(struct domain *d, enum iommu_feature feature)
{
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -147,7 +147,7 @@ struct iommu_ops {
int (*assign_device)(struct domain *, u8 devfn, device_t *dev, u32 flag);
int (*reassign_device)(struct domain *s, struct domain *t,
u8 devfn, device_t *dev);
-#ifdef CONFIG_HAS_PCI
+#if defined(CONFIG_HAS_PCI) &&
[Xen-devel] [PATCH v4 09/12] cpufreq: patch target() indirect call to direct one
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target(struct cpufr
{
unsigned int prev_freq = policy->cur;
-retval = cpufreq_driver.target(policy, target_freq, relation);
+retval = alternative_call(cpufreq_driver.target,
+ policy, target_freq, relation);
if ( retval == 0 )
TRACE_2D(TRC_PM_FREQ_CHANGE, prev_freq/1000, policy->cur/1000);
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 08/12] cpufreq: convert to a single post-init driver (hooks) instance
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: New.
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -53,8 +53,6 @@ enum {
struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
-static struct cpufreq_driver acpi_cpufreq_driver;
-
static bool __read_mostly acpi_pstate_strict;
boolean_param("acpi_pstate_strict", acpi_pstate_strict);
@@ -355,7 +353,7 @@ static void feature_detect(void *info)
if ( cpu_has_aperfmperf )
{
policy->aperf_mperf = 1;
-acpi_cpufreq_driver.getavg = get_measured_perf;
+cpufreq_driver.getavg = get_measured_perf;
}
eax = cpuid_eax(6);
@@ -593,7 +591,7 @@ acpi_cpufreq_cpu_init(struct cpufreq_pol
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
-acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+cpufreq_driver.get = get_cur_freq_on_cpu;
policy->cur = get_cur_freq_on_cpu(cpu);
break;
default:
@@ -635,7 +633,7 @@ static int acpi_cpufreq_cpu_exit(struct
return 0;
}
-static struct cpufreq_driver acpi_cpufreq_driver = {
+static const struct cpufreq_driver __initconstrel acpi_cpufreq_driver = {
.name = "acpi-cpufreq",
.verify = acpi_cpufreq_verify,
.target = acpi_cpufreq_target,
@@ -656,7 +654,7 @@ static int __init cpufreq_driver_init(vo
return ret;
}
-__initcall(cpufreq_driver_init);
+presmp_initcall(cpufreq_driver_init);
int cpufreq_cpu_init(unsigned int cpuid)
{
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -52,8 +52,6 @@
#define ARCH_CPU_FLAG_RESUME 1
-static struct cpufreq_driver powernow_cpufreq_driver;
-
static void transition_pstate(void *pstate)
{
wrmsrl(MSR_PSTATE_CTRL, *(unsigned int *)pstate);
@@ -215,7 +213,7 @@ static void feature_detect(void *info)
if ( cpu_has_aperfmperf )
{
policy->aperf_mperf = 1;
-powernow_cpufreq_driver.getavg = get_measured_perf;
+cpufreq_driver.getavg = get_measured_perf;
}
edx = cpuid_edx(CPUID_FREQ_VOLT_CAPABILITIES);
@@ -347,7 +345,8 @@ static int powernow_cpufreq_cpu_exit(str
return 0;
}
-static struct cpufreq_driver powernow_cpufreq_driver = {
+static const struct cpufreq_driver __initconstrel powernow_cpufreq_driver = {
+.name = "powernow",
.verify = powernow_cpufreq_verify,
.target = powernow_cpufreq_target,
.init = powernow_cpufreq_cpu_init,
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -64,7 +64,7 @@ int do_get_pm_info(struct xen_sysctl_get
case PMSTAT_PX:
if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
return -ENODEV;
-if ( !cpufreq_driver )
+if ( !cpufreq_driver.init )
return -ENODEV;
if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
return -EINVAL;
@@ -255,16 +255,16 @@ static int get_cpufreq_para(struct xen_s
return ret;
op->u.get_para.cpuinfo_cur_freq =
-cpufreq_driver->get ? cpufreq_driver->get(op->cpuid) : policy->cur;
+cpufreq_driver.get ? cpufreq_driver.get(op->cpuid) : policy->cur;
op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
op->u.get_para.scaling_cur_freq = policy->cur;
op->u.get_para.scaling_max_freq = policy->max;
op->u.get_para.scaling_min_freq = policy->min;
-if ( cpufreq_driver->name[0] )
+if ( cpufreq_driver.name[0] )
strlcpy(op->u.get_para.scaling_driver,
-cpufreq_driver->name, CPUFREQ_NAME_LEN);
+cpufreq_driver.name, CPUFREQ_NAME_LEN);
else
strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -172,7 +172,7 @@ int cpufreq_add_cpu(unsigned int cpu)
if ( !(perf->init & XEN_PX_INIT) )
return -EINVAL;
-if (!cpufreq_driver)
+if (!cpufreq_driver.init)
return 0;
if (per_cpu(cpufreq_cpu_policy, cpu))
@@ -239,7 +239,7 @@ int cpufreq_add_cpu(unsigned int cpu)
policy->cpu = cpu;
per_cpu(cpufreq_cpu_policy, cpu) = policy;
-ret = cpufreq_driver->init(policy);
+ret = cpufreq_driver.init(policy);
if (ret) {
free_cpumask_var(policy->cpus);
xfree(policy);
@@ -298,7 +298,7 @@ err1:
cpumask_clear_cpu(cpu, cpufreq_dom->map);
if (cpumask_empty(policy->cpus)) {
-cpufreq_driver->exit(policy);
+cpufreq_driver.exit(policy);
free_cpumask_var(policy->cpus);
xfree(policy);
}
@@ -362,7 +362,7 @@ int
[Xen-devel] [PATCH v4 07/12] x86/cpuidle: patch some indirect calls to direct ones
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
(from where cpuidle_init_cpu() runs the first time) the pointers need to
start out as NULL.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -102,8 +102,6 @@ bool lapic_timer_init(void)
return true;
}
-static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
-
void (*__read_mostly pm_idle_save)(void);
unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER - 1;
integer_param("max_cstate", max_cstate);
@@ -289,9 +287,9 @@ static uint64_t acpi_pm_ticks_elapsed(ui
return ((0x - t1) + t2 +1);
}
-uint64_t (*__read_mostly cpuidle_get_tick)(void) = get_acpi_pm_tick;
-static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
-= acpi_pm_ticks_elapsed;
+uint64_t (*__read_mostly cpuidle_get_tick)(void);
+static uint64_t (*__read_mostly tick_to_ns)(uint64_t);
+static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t);
static void print_acpi_power(uint32_t cpu, struct acpi_processor_power *power)
{
@@ -547,7 +545,7 @@ void update_idle_stats(struct acpi_proce
struct acpi_processor_cx *cx,
uint64_t before, uint64_t after)
{
-int64_t sleep_ticks = ticks_elapsed(before, after);
+int64_t sleep_ticks = alternative_call(ticks_elapsed, before, after);
/* Interrupts are disabled */
spin_lock(>stat_lock);
@@ -555,7 +553,8 @@ void update_idle_stats(struct acpi_proce
cx->usage++;
if ( sleep_ticks > 0 )
{
-power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
+power->last_residency = alternative_call(tick_to_ns, sleep_ticks) /
+1000UL;
cx->time += sleep_ticks;
}
power->last_state = >states[0];
@@ -635,7 +634,7 @@ static void acpi_processor_idle(void)
if ( cx->type == ACPI_STATE_C1 || local_apic_timer_c2_ok )
{
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -644,7 +643,7 @@ static void acpi_processor_idle(void)
/* Invoke C2 */
acpi_idle_do_entry(cx);
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call(cpuidle_get_tick);
trace_exit_reason(irq_traced);
/* Trace cpu idle exit */
TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
@@ -666,7 +665,7 @@ static void acpi_processor_idle(void)
lapic_timer_off();
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -717,7 +716,7 @@ static void acpi_processor_idle(void)
}
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call(cpuidle_get_tick);
/* recovering TSC */
cstate_restore_tsc();
@@ -827,11 +826,20 @@ int cpuidle_init_cpu(unsigned int cpu)
{
unsigned int i;
-if ( cpu == 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+if ( cpu == 0 && system_state < SYS_STATE_active )
{
-cpuidle_get_tick = get_stime_tick;
-ticks_elapsed = stime_ticks_elapsed;
-tick_to_ns = stime_tick_to_ns;
+if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+{
+cpuidle_get_tick = get_stime_tick;
+ticks_elapsed = stime_ticks_elapsed;
+tick_to_ns = stime_tick_to_ns;
+}
+else
+{
+cpuidle_get_tick = get_acpi_pm_tick;
+ticks_elapsed = acpi_pm_ticks_elapsed;
+tick_to_ns = acpi_pm_tick_to_ns;
+}
}
acpi_power = xzalloc(struct acpi_processor_power);
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -778,7 +778,7 @@ static void mwait_idle(void)
if (!(lapic_timer_reliable_states & (1 << cstate)))
lapic_timer_off();
- before = cpuidle_get_tick();
+ before = alternative_call(cpuidle_get_tick);
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->type, before, exp, pred);
update_last_cx_stat(power, cx, before);
@@ -786,7 +786,7 @@ static void mwait_idle(void)
if (cpu_is_haltable(cpu))
mwait_idle_with_hints(eax, MWAIT_ECX_INTERRUPT_BREAK);
- after =
[Xen-devel] [PATCH v4 06/12] x86/genapic: patch indirect calls to direct ones
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-genapic.send_IPI_mask(mask, vector);
+alternative_vcall(genapic.send_IPI_mask, mask, vector);
}
void send_IPI_self(int vector)
{
-genapic.send_IPI_self(vector);
+alternative_vcall(genapic.send_IPI_self, vector);
}
/*
--- a/xen/include/asm-x86/mach-generic/mach_apic.h
+++ b/xen/include/asm-x86/mach-generic/mach_apic.h
@@ -15,8 +15,18 @@
#define TARGET_CPUS ((const typeof(cpu_online_map) *)_online_map)
#define init_apic_ldr (genapic.init_apic_ldr)
#define clustered_apic_check (genapic.clustered_apic_check)
-#define cpu_mask_to_apicid (genapic.cpu_mask_to_apicid)
-#define vector_allocation_cpumask(cpu) (genapic.vector_allocation_cpumask(cpu))
+#define cpu_mask_to_apicid(mask) ({ \
+ /* \
+* There are a number of places where the address of a local variable \
+* gets passed here. The use of ?: in alternative_call() triggers an
\
+* "address of ... is always true" warning in such a case with at least
\
+* gcc 7 and 8. Hence the seemingly pointless local variable here. \
+*/ \
+ const cpumask_t *m_ = (mask); \
+ alternative_call(genapic.cpu_mask_to_apicid, m_); \
+})
+#define vector_allocation_cpumask(cpu) \
+ alternative_call(genapic.vector_allocation_cpumask, cpu)
static inline void enable_apic_mode(void)
{
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 03/12] x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
Reviewed-by: Wei Liu
---
v4: Re-base.
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -111,10 +111,15 @@ static void vlapic_clear_irr(int vector,
vlapic_clear_vector(vector, >regs->data[APIC_IRR]);
}
-static int vlapic_find_highest_irr(struct vlapic *vlapic)
+static void sync_pir_to_irr(struct vcpu *v)
{
if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(vlapic_vcpu(vlapic));
+alternative_vcall(hvm_funcs.sync_pir_to_irr, v);
+}
+
+static int vlapic_find_highest_irr(struct vlapic *vlapic)
+{
+sync_pir_to_irr(vlapic_vcpu(vlapic));
return vlapic_find_highest_vector(>regs->data[APIC_IRR]);
}
@@ -143,7 +148,7 @@ bool vlapic_test_irq(const struct vlapic
return false;
if ( hvm_funcs.test_pir &&
- hvm_funcs.test_pir(const_vlapic_vcpu(vlapic), vec) )
+ alternative_call(hvm_funcs.test_pir, const_vlapic_vcpu(vlapic), vec) )
return true;
return vlapic_test_vector(vec, >regs->data[APIC_IRR]);
@@ -165,10 +170,10 @@ void vlapic_set_irq(struct vlapic *vlapi
vlapic_clear_vector(vec, >regs->data[APIC_TMR]);
if ( hvm_funcs.update_eoi_exit_bitmap )
-hvm_funcs.update_eoi_exit_bitmap(target, vec, trig);
+alternative_vcall(hvm_funcs.update_eoi_exit_bitmap, target, vec, trig);
if ( hvm_funcs.deliver_posted_intr )
-hvm_funcs.deliver_posted_intr(target, vec);
+alternative_vcall(hvm_funcs.deliver_posted_intr, target, vec);
else if ( !vlapic_test_and_set_irr(vec, vlapic) )
vcpu_kick(target);
}
@@ -448,7 +453,7 @@ void vlapic_EOI_set(struct vlapic *vlapi
vlapic_clear_vector(vector, >regs->data[APIC_ISR]);
if ( hvm_funcs.handle_eoi )
-hvm_funcs.handle_eoi(vector);
+alternative_vcall(hvm_funcs.handle_eoi, vector);
vlapic_handle_EOI(vlapic, vector);
@@ -1412,8 +1417,7 @@ static int lapic_save_regs(struct vcpu *
if ( !has_vlapic(v->domain) )
return 0;
-if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(v);
+sync_pir_to_irr(v);
return hvm_save_entry(LAPIC_REGS, v->vcpu_id, h, vcpu_vlapic(v)->regs);
}
@@ -1509,7 +1513,8 @@ static int lapic_load_regs(struct domain
lapic_load_fixup(s);
if ( hvm_funcs.process_isr )
-hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
+alternative_vcall(hvm_funcs.process_isr,
+ vlapic_find_highest_isr(s), v);
vlapic_adjust_i8259_target(d);
lapic_rearm(s);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2336,12 +2336,6 @@ static struct hvm_function_table __initd
.nhvm_vcpu_vmexit_event = nvmx_vmexit_event,
.nhvm_intr_blocked= nvmx_intr_blocked,
.nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
-.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
-.process_isr = vmx_process_isr,
-.deliver_posted_intr = vmx_deliver_posted_intr,
-.sync_pir_to_irr = vmx_sync_pir_to_irr,
-.test_pir = vmx_test_pir,
-.handle_eoi = vmx_handle_eoi,
.nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
.enable_msr_interception = vmx_enable_msr_interception,
.is_singlestep_supported = vmx_is_singlestep_supported,
@@ -2469,26 +2463,23 @@ const struct hvm_function_table * __init
setup_ept_dump();
}
-if ( !cpu_has_vmx_virtual_intr_delivery )
+if ( cpu_has_vmx_virtual_intr_delivery )
{
-vmx_function_table.update_eoi_exit_bitmap = NULL;
-vmx_function_table.process_isr = NULL;
-vmx_function_table.handle_eoi = NULL;
-}
-else
+vmx_function_table.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap;
+vmx_function_table.process_isr = vmx_process_isr;
+vmx_function_table.handle_eoi = vmx_handle_eoi;
vmx_function_table.virtual_intr_delivery_enabled = true;
+}
if ( cpu_has_vmx_posted_intr_processing )
{
alloc_direct_apic_vector(_intr_vector,
pi_notification_interrupt);
if ( iommu_intpost )
alloc_direct_apic_vector(_wakeup_vector, pi_wakeup_interrupt);
-}
-else
-{
-vmx_function_table.deliver_posted_intr = NULL;
-vmx_function_table.sync_pir_to_irr = NULL;
-vmx_function_table.test_pir = NULL;
+
+vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr;
+vmx_function_table.sync_pir_to_irr = vmx_sync_pir_to_irr;
+vmx_function_table.test_pir= vmx_test_pir;
}
if ( cpu_has_vmx_tsc_scaling )
[Xen-devel] [PATCH v4 04/12] x86: patch ctxt_switch_masking() indirect call to direct one
Signed-off-by: Jan Beulich Reviewed-by: Wei Liu --- v2: Drop open-coded number from macro invocation. --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -184,7 +184,7 @@ void ctxt_switch_levelling(const struct } if (ctxt_switch_masking) - ctxt_switch_masking(next); + alternative_vcall(ctxt_switch_masking, next); } bool_t opt_cpu_info; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 05/12] x86/genapic: remove indirection from genapic hook accesses
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -943,8 +943,8 @@ void __init x2apic_bsp_setup(void)
force_iommu = 1;
-genapic = apic_x2apic_probe();
-printk("Switched to APIC driver %s.\n", genapic->name);
+genapic = *apic_x2apic_probe();
+printk("Switched to APIC driver %s.\n", genapic.name);
if ( !x2apic_enabled )
{
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -42,7 +42,7 @@ static __init int probe_bigsmp(void)
return def_to_bigsmp;
}
-const struct genapic apic_bigsmp = {
+const struct genapic __initconstrel apic_bigsmp = {
APIC_INIT("bigsmp", probe_bigsmp),
GENAPIC_PHYS
};
--- a/xen/arch/x86/genapic/default.c
+++ b/xen/arch/x86/genapic/default.c
@@ -20,7 +20,7 @@ static __init int probe_default(void)
return 1;
}
-const struct genapic apic_default = {
+const struct genapic __initconstrel apic_default = {
APIC_INIT("default", probe_default),
GENAPIC_FLAT
};
--- a/xen/arch/x86/genapic/probe.c
+++ b/xen/arch/x86/genapic/probe.c
@@ -15,11 +15,9 @@
#include
#include
-extern const struct genapic apic_bigsmp;
+struct genapic __read_mostly genapic;
-const struct genapic *__read_mostly genapic;
-
-const struct genapic *apic_probe[] __initdata = {
+const struct genapic *const __initconstrel apic_probe[] = {
_bigsmp,
_default, /* must be last */
NULL,
@@ -36,11 +34,11 @@ void __init generic_bigsmp_probe(void)
* - we find more than 8 CPUs in acpi LAPIC listing with xAPIC support
*/
- if (!cmdline_apic && genapic == _default)
+ if (!cmdline_apic && genapic.name == apic_default.name)
if (apic_bigsmp.probe()) {
- genapic = _bigsmp;
+ genapic = apic_bigsmp;
printk(KERN_INFO "Overriding APIC driver with %s\n",
- genapic->name);
+ genapic.name);
}
}
@@ -50,7 +48,7 @@ static int __init genapic_apic_force(con
for (i = 0; apic_probe[i]; i++)
if (!strcmp(apic_probe[i]->name, str)) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
rc = 0;
}
@@ -66,18 +64,18 @@ void __init generic_apic_probe(void)
record_boot_APIC_mode();
check_x2apic_preenabled();
- cmdline_apic = changed = (genapic != NULL);
+ cmdline_apic = changed = !!genapic.name;
for (i = 0; !changed && apic_probe[i]; i++) {
if (apic_probe[i]->probe()) {
changed = 1;
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
}
}
if (!changed)
- genapic = _default;
+ genapic = apic_default;
- printk(KERN_INFO "Using APIC driver %s\n", genapic->name);
+ printk(KERN_INFO "Using APIC driver %s\n", genapic.name);
}
/* These functions can switch the APIC even after the initial ->probe() */
@@ -88,9 +86,9 @@ int __init mps_oem_check(struct mp_confi
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->mps_oem_check(mpc,oem,productid)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
@@ -104,9 +102,9 @@ int __init acpi_madt_oem_check(char *oem
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->acpi_madt_oem_check(oem_id, oem_table_id)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -163,7 +163,7 @@ static void send_IPI_mask_x2apic_cluster
local_irq_restore(flags);
}
-static const struct genapic apic_x2apic_phys = {
+static const struct genapic __initconstrel apic_x2apic_phys = {
APIC_INIT("x2apic_phys", NULL),
[Xen-devel] [PATCH v4 02/12] x86/HVM: patch indirect calls through hvm_funcs to direct ones
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent patch.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v3: Re-base.
v2: Drop open-coded numbers from macro invocations. Re-base.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2104,7 +2104,7 @@ static int hvmemul_write_msr(
static int hvmemul_wbinvd(
struct x86_emulate_ctxt *ctxt)
{
-hvm_funcs.wbinvd_intercept();
+alternative_vcall(hvm_funcs.wbinvd_intercept);
return X86EMUL_OKAY;
}
@@ -2122,7 +2122,7 @@ static int hvmemul_get_fpu(
struct vcpu *curr = current;
if ( !curr->fpu_dirtied )
-hvm_funcs.fpu_dirty_intercept();
+alternative_vcall(hvm_funcs.fpu_dirty_intercept);
else if ( type == X86EMUL_FPU_fpu )
{
const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
@@ -2239,7 +2239,7 @@ static void hvmemul_put_fpu(
{
curr->fpu_dirtied = false;
stts();
-hvm_funcs.fpu_leave(curr);
+alternative_vcall(hvm_funcs.fpu_leave, curr);
}
}
}
@@ -2401,7 +2401,8 @@ static int _hvm_emulate_one(struct hvm_e
if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
{
hvmemul_ctxt->intr_shadow = new_intr_shadow;
-hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
+alternative_vcall(hvm_funcs.set_interrupt_shadow,
+ curr, new_intr_shadow);
}
if ( hvmemul_ctxt->ctxt.retire.hlt &&
@@ -2538,7 +2539,8 @@ void hvm_emulate_init_once(
memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
-hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
+hvmemul_ctxt->intr_shadow =
+alternative_call(hvm_funcs.get_interrupt_shadow, curr);
hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -272,12 +272,12 @@ void hvm_set_rdtsc_exiting(struct domain
struct vcpu *v;
for_each_vcpu ( d, v )
-hvm_funcs.set_rdtsc_exiting(v, enable);
+alternative_vcall(hvm_funcs.set_rdtsc_exiting, v, enable);
}
void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
{
-if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
+if ( !alternative_call(hvm_funcs.get_guest_pat, v, guest_pat) )
*guest_pat = v->arch.hvm.pat_cr;
}
@@ -302,7 +302,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
return 0;
}
-if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
+if ( !alternative_call(hvm_funcs.set_guest_pat, v, guest_pat) )
v->arch.hvm.pat_cr = guest_pat;
return 1;
@@ -342,7 +342,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
/* nothing, best effort only */;
}
-return hvm_funcs.set_guest_bndcfgs(v, val);
+return alternative_call(hvm_funcs.set_guest_bndcfgs, v, val);
}
/*
@@ -500,7 +500,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
{
info->cr2 = v->arch.hvm.guest_cr[2];
-return hvm_funcs.get_pending_event(v, info);
+
+return alternative_call(hvm_funcs.get_pending_event, v, info);
}
void hvm_do_resume(struct vcpu *v)
@@ -1651,7 +1652,7 @@ void hvm_inject_event(const struct x86_e
}
}
-hvm_funcs.inject_event(event);
+alternative_vcall(hvm_funcs.inject_event, event);
}
int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
@@ -2238,7 +2239,7 @@ int hvm_set_cr0(unsigned long value, boo
(!rangeset_is_empty(d->iomem_caps) ||
!rangeset_is_empty(d->arch.ioport_caps) ||
has_arch_pdevs(d)) )
-hvm_funcs.handle_cd(v, value);
+alternative_vcall(hvm_funcs.handle_cd, v, value);
hvm_update_cr(v, 0, value);
@@ -3477,7 +3478,8 @@ int hvm_msr_read_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this is not an MCE MSR, see other MSRs. */
ret = ((ret == 0)
- ? hvm_funcs.msr_read_intercept(msr, msr_content)
+ ? alternative_call(hvm_funcs.msr_read_intercept,
+ msr, msr_content)
: X86EMUL_OKAY);
break;
}
@@ -3637,7 +3639,8 @@ int hvm_msr_write_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this is not an MCE MSR, see other MSRs. */
ret = ((ret == 0)
- ? hvm_funcs.msr_write_intercept(msr, msr_content)
+ ? alternative_call(hvm_funcs.msr_write_intercept,
+ msr, msr_content)
: X86EMUL_OKAY);
break;
}
@@ -3829,7 +3832,7 @@ void hvm_hypercall_page_initialise(struc
[Xen-devel] [PATCH v4 01/12] x86: infrastructure to allow converting certain indirect calls to direct ones
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, making necessary a second passs through the
alternative patching code. Therefore some adjustments beyond the
recognition of the new special pattern are necessary there.
Note that patching such sites more than once is not supported (and the
supplied macros also don't provide any means to do so).
Signed-off-by: Jan Beulich
---
v4: Extend / adjust comments.
v3: Use "X" constraint instead of "g" in alternative_callN(). Pre-
calculate values to be put into local register variables.
v2: Introduce and use count_va_arg(). Don't omit middle operand from
?: in ALT_CALL_ARG(). Re-base.
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -177,9 +177,14 @@ text_poke(void *addr, const void *opcode
* self modifying code. This implies that asymmetric systems where
* APs have less capabilities than the boot processor are not handled.
* Tough. Make sure you disable such features by hand.
+ *
+ * The caller will set the "force" argument to true for the final
+ * invocation, such that no CALLs/JMPs to NULL pointers will be left
+ * around. See also the further comment below.
*/
-void init_or_livepatch apply_alternatives(struct alt_instr *start,
- struct alt_instr *end)
+static void init_or_livepatch _apply_alternatives(struct alt_instr *start,
+ struct alt_instr *end,
+ bool force)
{
struct alt_instr *a, *base;
@@ -208,9 +213,10 @@ void init_or_livepatch apply_alternative
/*
* Detect sequences of alt_instr's patching the same origin site, and
* keep base pointing at the first alt_instr entry. This is so we can
- * refer to a single ->priv field for patching decisions. We
- * deliberately use the alt_instr itself rather than a local variable
- * in case we end up making multiple passes.
+ * refer to a single ->priv field for some of our patching decisions,
+ * in particular the NOP optimization. We deliberately use the
alt_instr
+ * itself rather than a local variable in case we end up making
multiple
+ * passes.
*
* ->priv being nonzero means that the origin site has already been
* modified, and we shouldn't try to optimise the nops again.
@@ -218,6 +224,13 @@ void init_or_livepatch apply_alternative
if ( ALT_ORIG_PTR(base) != orig )
base = a;
+/* Skip patch sites already handled during the first pass. */
+if ( a->priv )
+{
+ASSERT(force);
+continue;
+}
+
/* If there is no replacement to make, see about optimising the nops.
*/
if ( !boot_cpu_has(a->cpuid) )
{
@@ -225,7 +238,7 @@ void init_or_livepatch apply_alternative
if ( base->priv )
continue;
-base->priv = 1;
+a->priv = 1;
/* Nothing useful to do? */
if ( toolchain_nops_are_ideal || a->pad_len <= 1 )
@@ -236,20 +249,74 @@ void init_or_livepatch apply_alternative
continue;
}
-base->priv = 1;
-
memcpy(buf, repl, a->repl_len);
/* 0xe8/0xe9 are relative branches; fix the offset. */
if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
-*(int32_t *)(buf + 1) += repl - orig;
+{
+/*
+ * Detect the special case of indirect-to-direct branch patching:
+ * - replacement is a direct CALL/JMP (opcodes 0xE8/0xE9; already
+ * checked above),
+ * - replacement's displacement is -5 (pointing back at the very
+ * insn, which makes no sense in a real replacement insn),
+ * - original is an indirect CALL/JMP (opcodes 0xFF/2 or 0xFF/4)
+ * using RIP-relative addressing.
+ * Some branch destinations may still be NULL when we come here
+ * the first time. Defer patching of those until the post-presmp-
+ * initcalls re-invocation (with force set to true). If at that
+ * point the branch destination is still NULL, insert "UD2; UD0"
+ * (for ease of recognition) instead of CALL/JMP.
+ */
+if ( a->cpuid == X86_FEATURE_ALWAYS &&
+ *(int32_t *)(buf + 1) == -5 &&
+ a->orig_len >= 6 &&
+ orig[0] == 0xff &&
+ orig[1] == (*buf & 1 ? 0x25 : 0x15) )
+{
+long disp = *(int32_t *)(orig + 2);
+const uint8_t *dest = *(void **)(orig + 6 + disp);
+
+if ( dest
[Xen-devel] [PATCH v4 00/12] x86: indirect call overhead reduction
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.
From patch 2 onwards dependencies exist on earlier, yet to be reviewed
patches ("x86/alternatives: fully leverage automatic NOP filling" as well
as the "x86: improve PDX <-> PFN and alike translations" series at the
very least). I nevertheless wanted to enable a first round of review of
the series, the more that some of the patches (not just initial ones)
could perhaps be taken irrespective of those dependencies. The first
two of the three genapic patches, otoh, are entirely independent and
could go in right away afaict if they were ack-ed.
Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are IOMMU, vPMU, and XSM. For some of these, the ARM side would
need dealing with as well - I'm not sure whether replacing indirect calls
by direct ones is worthwhile there as well; if not, the wrappers would
simply need to become function invocations in the ARM case (as was
already asked for in the IOMMU case).
01: x86: infrastructure to allow converting certain indirect calls to direct
ones
02: x86/HVM: patch indirect calls through hvm_funcs to direct ones
03: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
04: x86: patch ctxt_switch_masking() indirect call to direct one
05: x86/genapic: remove indirection from genapic hook accesses
06: x86/genapic: patch indirect calls to direct ones
07: x86/cpuidle: patch some indirect calls to direct ones
08: cpufreq: convert to a single post-init driver (hooks) instance
09: cpufreq: patch target() indirect call to direct one
10: IOMMU: introduce IOMMU_MIXED config option
11: IOMMU: remove indirection from certain IOMMU hook accesses
12: IOMMU: patch certain indirect calls to direct ones
Besides some re-basing only patch 1 has some comment improvements
compared to v2, and patches 10 and onwards are new.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] tools/libxl: Switch Arm guest type to PVH
Hi Roger,
On 02/10/2018 09:56, Roger Pau Monné wrote:
On Mon, Oct 01, 2018 at 07:57:21PM +0100, Julien Grall wrote:
Currently, the toolstack is considering Arm guest always PV. However,
they are very similar to PVH because HW virtualization extension are used
and QEMU is not started. So switch Arm guest type to PVH.
To keep compatibility with toolstack creating Arm guest with PV type
(e.g libvirt), libxl will now convert those guests to PVH.
Furthermore, the default type for Arm in xl will now be PVH to allow
smooth transition for user.
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
---
This was discussed at Xen Summit and also in various thread on
xen-devel. The latest one was when Andrew sent a patch to deny guest creation
on Arm with XEN_DOMCTL_CDF_hap unset.
I suspect we first implemented Arm guest as PV in libxl because PVH was
non-existent and the type was easier to avoid spawning QEMU. Note that
Linux and Xen are already considering Arm guest as PVH.
Changes in v3:
- Properly reset u.pvh
- Update documentation and print
- Return ERROR_INVAL rather than ERROR_FAIL
Changes in v2:
- Rather than denying PV guest, convert them to PVH
---
docs/man/xl.cfg.pod.5.in | 5 +++--
tools/libxl/libxl_arch.h | 3 ++-
tools/libxl/libxl_arm.c| 26 --
tools/libxl/libxl_create.c | 2 +-
tools/libxl/libxl_x86.c| 3 ++-
tools/xl/xl_parse.c| 4
6 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index b72718151b..b1c0be14cd 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -80,13 +80,14 @@ single host must be unique.
=item B
Specifies that this is to be a PV domain, suitable for hosting Xen-aware
-guest operating systems. This is the default.
+guest operating systems. This is the default on x86.
=item B
Specifies that this is to be an PVH domain. That is a lightweight HVM-like
guest without a device model and without many of the emulated devices
-available to HVM guests. Note that this mode requires a PVH aware kernel.
+available to HVM guests. Note that this mode requires a PVH aware kernel on
+x86. This is the default on Arm.
=item B
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5ab0c95974..930570ef1e 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -65,7 +65,8 @@ _hidden
int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t domid, int irq);
_hidden
-void libxl__arch_domain_build_info_setdefault(libxl_domain_build_info *b_info);
+void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
+ libxl_domain_build_info *b_info);
_hidden
int libxl__arch_extra_memory(libxl__gc *gc,
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 699fd9ddc6..25dc3defc6 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -953,7 +953,11 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
int rc;
uint64_t val;
-assert(info->type == LIBXL_DOMAIN_TYPE_PV);
+if (info->type != LIBXL_DOMAIN_TYPE_PVH) {
+LOG(ERROR, "Unsupported Arm guest type %s",
+libxl_domain_type_to_string(info->type));
+return ERROR_INVAL;
+}
/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
@@ -1110,10 +1114,28 @@ int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t
domid, int irq)
return xc_domain_bind_pt_spi_irq(CTX->xch, domid, irq, irq);
}
-void libxl__arch_domain_build_info_setdefault(libxl_domain_build_info *b_info)
+void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
+ libxl_domain_build_info *b_info)
{
/* ACPI is disabled by default */
libxl_defbool_setdefault(_info->acpi, false);
+
+/*
+ * Arm guest are now considered as PVH by the toolstack. To allow
+ * compatibility with previous toolstack, PV guest are automatically
+ * converted to PVH.
+ */
+if (b_info->type != LIBXL_DOMAIN_TYPE_PV)
+return;
+
+LOG(WARN, "Converting PV guest to PVH.");
+LOG(WARN, "Arm guest are now PVH.");
+LOG(WARN, "Please fix your configuration file/toolstack.");
+
+/* Re-initialize type to PVH and all associated fields to defaults. */
+memset(_info->u, '\0', sizeof(b_info->u));
I don't really like the zeroing done here, but I think it's fine as
long as it's only done when converting from PV -> PVH and after
copying the deprecated fields.
I don't think we can safely avoid to re-initialize b_info->u. Some
fields in u.pv are not initialized to 0 (e.g slack_memkb is initialized
to ~0ULL). So you will transfer that value over to pvh union and
altering the init values for PVH.
Furthermore, PVH fields may not be initialized to 0 (so
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
On 10/01/2018 06:58 PM, Dario Faggioli wrote: > On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote: >> On 01/10/2018 17:48, George Dunlap wrote: >>> On 10/01/2018 04:40 PM, Andrew Cooper wrote: On 01/10/18 16:35, Wei Liu wrote: >> Wait, the migration code reads the scheduler parameters -- >> even if these >> have not been explicitly set by the admin -- and sends them >> along with >> the migration stream? And if the remote scheduler is >> different, the >> migration fails? >> >> That's not so good. :-) > > But one can argue that the guest is specific configured that > way so it's > parameters should be preserved. We normally analyse things on a > case by > case basis. If there isn't an obvious fix, then the switch of default scheduler needs reverting until there is a fix present. This is currently blocking master. >>> >>> Agreed. I'd argue for ignoring failures to set scheduler >>> parameters on >>> migrate, on the grounds that this will be less risk to the project >>> as a >>> whole than reverting credit2 again. But either way we should do >>> something quickly. >> >> We should ignore a mismatch of the scheduler. Failures when setting >> parameters for a matching scheduler should not be ignored IMO. >> > Indeed! Especially considering that this isn't really related on what > the default scheduler is (despite it being making Credit2 default that > triggers the issue). > > In fact, what if: > - user uses Credit1 (default and supported) on host A > - user uses Credit2 (supported) on host B > - user migrates VM > - BOOOM! > > So, unless it is intended --and, I'd say, also documented somewhere-- > that migrating between hosts which use different schedulers is to be > avoided, this is already a bug, whatever the default scheduler is... > > George, let me know if you're working on a fix already, or if I should > do that myself. I reverted the credit2 default; but really we need to have a design discussion about what we want the overall behavior to be. It's not simple or obvious. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, Thanks, Basic state change is working now, after using above script. As I said, I want to share buffer between two domains. Could you please suggest outlines, how can I share buffer between 2 domains(Guest and Host)? Thanks, Omkar B On Fri, Sep 28, 2018 at 7:12 PM Juergen Gross wrote: > On 28/09/2018 14:55, Omkar Bolla wrote: > > Hi, > > I tried to run script after pause the domain and unpause domain after > > run script. But I ended up with same error > > I looked at the script again, it is wrong. The permissions should > be set for each node under the root path of the respective domains, > the first permission should be "n$domid" ($domid is the owner who > can always read/write, the n is "no access" for all domains not > explicitly listed), the second permission should be "r$domid" as > the other side should be able to read only. > > In order to do it correctly the script should be: > > #!/bin/bash > > DOMU_ID=$1 > > if [ -z "$DOMU_ID" ]; then > echo "Usage: $0 [domU ID]]" > echo > echo "Connects the new device, with dom0 as backend, domU as frontend" > exit 1 > fi > > # Pause domU as a script can't write an entry and set permission > # in a single operation. > xl pause $DOMU_ID > > DEVICE=mydevice > DOMU_KEY=/local/domain/$DOMU_ID/device/$DEVICE/0 > DOM0_KEY=/local/domain/0/backend/$DEVICE/$DOMU_ID/0 > > # Tell the domU about the new device and its backend > xenstore-write $DOMU_KEY/backend-id 0 > xenstore-write $DOMU_KEY/backend > "/local/domain/0/backend/$DEVICE/$DOMU_ID/0" > > # Tell the dom0 about the new device and its frontend > xenstore-write $DOM0_KEY/frontend-id $DOMU_ID > xenstore-write $DOM0_KEY/frontend "/local/domain/$DOMU_ID/device/$DEVICE/0" > > # Activate the device, dom0 needs to be activated last > xenstore-write $DOMU_KEY/state 1 > xenstore-write $DOM0_KEY/state 1 > > # Make sure the domU can read the dom0 data > xenstore-chmod -r $DOM0_KEY n0 r$DOMU_ID > xenstore-chmod -r $DOMU_KEY n$DOMU_ID r0 > > xl unpause $DOMU_ID > > > Juergen > -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
On Tue, 2018-10-02 at 10:36 +0100, Jan Beulich wrote: > > > > On 02.10.18 at 11:24, wrote: > > > No. See Jürgen's response. The default scheduler (irrespective of > whether it was chosen via command line option) should not matter. > Any means to force a non-default scheduler (and it indeed looks > like CPU pools are the only way) should imo retain that specific > scheduler. > Right, but the scheduler is a Xen/host (or cpupool) property, not a VM one. Do we handle like that the other similar ones? Like, do we fail migration if one host use the default setting wrt autoballooning and the other doesn't? Or wrt XPTI and the other mitigations? I mean, I think I see your point, and I'm still making up my mind about this, but I'm starting to think that this is the user responsibility to know what he's doing, and all we should do is, in this case, if we notice the mismatch between the schedulers, to print a warning and avoid setting the scheduler params... Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-snapshot test] 75336: trouble: blocked/broken
flight 75336 distros-debian-snapshot real [real] http://osstest.xensource.com/osstest/logs/75336/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-daily-netboot-pygrub 1 build-check(1) blocked n/a test-armhf-armhf-armhf-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-current-netinst-pygrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-daily-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-i386-daily-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-daily-netboot-pygrub 1 build-check(1) blocked n/a build-armhf 4 host-install(4) broken like 75284 build-armhf-pvops 4 host-install(4) broken like 75284 build-amd64-pvops 4 host-install(4) broken like 75284 build-amd64 4 host-install(4) broken like 75284 build-i3864 host-install(4) broken like 75284 build-i386-pvops 4 host-install(4) broken like 75284 baseline version: flight 75284 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-daily-netboot-pvgrub blocked test-amd64-i386-i386-daily-netboot-pvgrubblocked test-amd64-i386-amd64-daily-netboot-pygrub blocked test-armhf-armhf-armhf-daily-netboot-pygrub blocked test-amd64-amd64-i386-daily-netboot-pygrub blocked test-amd64-amd64-amd64-current-netinst-pygrubblocked test-amd64-i386-amd64-current-netinst-pygrub blocked test-amd64-amd64-i386-current-netinst-pygrub blocked test-amd64-i386-i386-current-netinst-pygrub blocked test-amd64-amd64-amd64-weekly-netinst-pygrub blocked test-amd64-i386-amd64-weekly-netinst-pygrub blocked test-amd64-amd64-i386-weekly-netinst-pygrub blocked test-amd64-i386-i386-weekly-netinst-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
>>> On 02.10.18 at 11:24, wrote: > On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote: >> > > > On 01.10.18 at 18:07, wrote: >> > >> > We should ignore a mismatch of the scheduler. Failures when setting >> > parameters for a matching scheduler should not be ignored IMO. >> >> Well, depends on whether the scheduler was explicitly chosen. >> I don't think migration should succeed when e.g. RTDS was used >> and isn't available on the destination host. >> > I'm not sure I'm understanding. > > You're saying, that, e.g., the migration of a VM between, for instance: > > - a Xen 4.11 host, booted without any sched=, and hence running Credit, > and another Xen 4.11 host, booted with sched=credit2, > > should fail _while_ : > > - a migration between a Xen 4.11 host, booted without any sched=, and > hence using Credit, and a Xen 4.12 host, booted without any sched=, > and hence using Credit2 (if we switch), > > should succeed ? No. See Jürgen's response. The default scheduler (irrespective of whether it was chosen via command line option) should not matter. Any means to force a non-default scheduler (and it indeed looks like CPU pools are the only way) should imo retain that specific scheduler. But I agree that this is not the only possible / sensible view at things. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
>>> On 29.09.18 at 11:22, wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -48,7 +48,12 @@ void __xsm_action_mismatch_detected(void);
> * There is no xsm_default_t argument available, so the value from the
> assertion
> * is used to initialize the variable.
> */
> +#ifdef CONFIG_XSM_SILO
> +#define XSM_INLINE __attribute__ ((unused))
Please don't open-code __maybe_unused. Furthermore I question
the dependency on CONFIG_XSM_SILO here: Afaict you want this for
just the single new inclusion site, without affecting any others.
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -733,6 +733,12 @@ extern const unsigned char xsm_flask_init_policy[];
> extern const unsigned int xsm_flask_init_policy_size;
> #endif
>
> +#ifdef CONFIG_XSM_SILO
> +extern void silo_init(void);
> +#else
> +static inline void silo_init(void) {}
> +#endif
Along the lines of one of my remarks on patch 1, I think you would
better get away without the inline variant, by adding suitable #ifdef-s
to eliminate the risk of wrong use of the new enumerator.
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -11,7 +11,6 @@
> */
>
> #define XSM_NO_WRAPPERS
> -#define XSM_INLINE /* */
> #include
The change looks unmotivated here, perhaps because of the
questionable CONFIG_XSM_SILO dependency further up. That
said, it looks as if the #define could go away currently, as being
redundant with what dummy.h already has. That would then
better be a small separate prereq patch imo.
> --- /dev/null
> +++ b/xen/xsm/silo.c
> @@ -0,0 +1,109 @@
> +/**
> + * xsm/silo.c
> + *
> + * SILO module for XSM(Xen Security Modules)
Would you mind adding the missing blank here?
> + * Copyright (c) 2018 Citrix Systems Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; If not, see
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote: > > > > On 01.10.18 at 18:07, wrote: > > > > We should ignore a mismatch of the scheduler. Failures when setting > > parameters for a matching scheduler should not be ignored IMO. > > Well, depends on whether the scheduler was explicitly chosen. > I don't think migration should succeed when e.g. RTDS was used > and isn't available on the destination host. > I'm not sure I'm understanding. You're saying, that, e.g., the migration of a VM between, for instance: - a Xen 4.11 host, booted without any sched=, and hence running Credit, and another Xen 4.11 host, booted with sched=credit2, should fail _while_ : - a migration between a Xen 4.11 host, booted without any sched=, and hence using Credit, and a Xen 4.12 host, booted without any sched=, and hence using Credit2 (if we switch), should succeed ? Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm
>>> On 29.09.18 at 11:22, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -899,6 +899,19 @@ hardware domain is architecture dependent.
> Note that specifying zero as domU value means zero, while for dom0 it means
> to use the default.
>
> +### xsm
> +> `= dummy | flask`
> +
> +> Default: `dummy`
> +
> +Specify which XSM module should be enabled. This option is only available if
> +the hypervisor was compiled with XSM support.
> +
> +* `dummy`: this is the default choice. Basic restriction for common
> deployment
> + (the dummy module) will be applied. it's also used when XSM is compiled
> out.
"It's" (upper case I).
> +* `flask`: this is the policy based access control. To choose this, the
> + separated option in kconfig must also be enabled.
Perhaps better "separate" (but I'm not a native speaker)?
> @@ -154,6 +154,17 @@ config XSM_FLASK_POLICY
>
> If unsure, say Y.
>
> +choice
> + prompt "Default XSM implementation"
> + depends on XSM
> + default XSM_FLASK_DEFAULT if XSM_FLASK
> + default XSM_DUMMY_DEFAULT
> + config XSM_DUMMY_DEFAULT
> + bool "Match non-XSM behavior"
> + config XSM_FLASK_DEFAULT
> + bool "FLux Advanced Security Kernel" if XSM_FLASK
> +endchoice
Personally I'd prefer XSM_DEFAULT_*; not sure what others think.
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -31,6 +31,37 @@
>
> struct xsm_operations *xsm_ops;
>
> +enum xsm_bootparam {
> +XSM_BOOTPARAM_DUMMY,
> +XSM_BOOTPARAM_FLASK,
Considering the #ifdef-s further down, should this perhaps also be
put in "#ifdef CONFIG_XSM_FLASK", to avoid it mistakenly getting
used when the code was compiled out?
> +};
> +
> +static enum xsm_bootparam __initdata xsm_bootparam =
> +#ifdef CONFIG_XSM_FLASK_DEFAULT
> +XSM_BOOTPARAM_FLASK;
> +#else
> +XSM_BOOTPARAM_DUMMY;
> +#endif
> +
> +static int __init parse_xsm_param(const char *s)
> +{
> +int rc = 0;
> +
> +if ( !strcmp(s, "dummy") )
> +xsm_bootparam = XSM_BOOTPARAM_DUMMY;
> +#ifdef CONFIG_XSM_FLASK
> +else if ( !strcmp(s, "flask") )
> +xsm_bootparam = XSM_BOOTPARAM_FLASK;
> +#endif
> +else {
Style (brace goes on its own line).
> +printk("XSM: can't parse boot parameter xsm=%s\n", s);
Again, not being a native speaker, "can't parse" sounds odd. Why
not just "unknown" or "unknown or unsupported"?
> @@ -57,7 +88,20 @@ static int __init xsm_core_init(const void *policy_buffer,
> size_t policy_size)
> }
>
> xsm_ops = _xsm_ops;
> -flask_init(policy_buffer, policy_size);
> +
> +switch ( xsm_bootparam )
> +{
> +case XSM_BOOTPARAM_DUMMY:
> +break;
> +
> +case XSM_BOOTPARAM_FLASK:
> +flask_init(policy_buffer, policy_size);
> +break;
> +
> +default:
> +printk("XSM: Invalid value for xsm= boot parameter\n");
> +break;
What situation is this covering, when all enumerators already have
their case label? Simply ASSERT_UNREACHABLE()?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask: Add check for io{port, mem}con sorting
>>> On 28.09.18 at 21:13, wrote: > These entries are not always sorted by checkpolicy. Enforce the sorting > (which can be done manually if using an unpatched checkpolicy) when > loading the policy so that later uses by the security server do not > incorrectly use the initial sid. "Enforce the sorting" could mean two things - sorting what's unsorted, or (as you do) raise an error. Isn't raising an error here possibly going to impact systems which currently work? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] tools/libxl: Switch Arm guest type to PVH
On Mon, Oct 01, 2018 at 07:57:21PM +0100, Julien Grall wrote:
> Currently, the toolstack is considering Arm guest always PV. However,
> they are very similar to PVH because HW virtualization extension are used
> and QEMU is not started. So switch Arm guest type to PVH.
>
> To keep compatibility with toolstack creating Arm guest with PV type
> (e.g libvirt), libxl will now convert those guests to PVH.
>
> Furthermore, the default type for Arm in xl will now be PVH to allow
> smooth transition for user.
>
> Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
>
> ---
>
> This was discussed at Xen Summit and also in various thread on
> xen-devel. The latest one was when Andrew sent a patch to deny guest creation
> on Arm with XEN_DOMCTL_CDF_hap unset.
>
> I suspect we first implemented Arm guest as PV in libxl because PVH was
> non-existent and the type was easier to avoid spawning QEMU. Note that
> Linux and Xen are already considering Arm guest as PVH.
>
> Changes in v3:
> - Properly reset u.pvh
> - Update documentation and print
> - Return ERROR_INVAL rather than ERROR_FAIL
>
> Changes in v2:
> - Rather than denying PV guest, convert them to PVH
> ---
> docs/man/xl.cfg.pod.5.in | 5 +++--
> tools/libxl/libxl_arch.h | 3 ++-
> tools/libxl/libxl_arm.c| 26 --
> tools/libxl/libxl_create.c | 2 +-
> tools/libxl/libxl_x86.c| 3 ++-
> tools/xl/xl_parse.c| 4
> 6 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index b72718151b..b1c0be14cd 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -80,13 +80,14 @@ single host must be unique.
> =item B
>
> Specifies that this is to be a PV domain, suitable for hosting Xen-aware
> -guest operating systems. This is the default.
> +guest operating systems. This is the default on x86.
>
> =item B
>
> Specifies that this is to be an PVH domain. That is a lightweight HVM-like
> guest without a device model and without many of the emulated devices
> -available to HVM guests. Note that this mode requires a PVH aware kernel.
> +available to HVM guests. Note that this mode requires a PVH aware kernel on
> +x86. This is the default on Arm.
>
> =item B
>
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> index 5ab0c95974..930570ef1e 100644
> --- a/tools/libxl/libxl_arch.h
> +++ b/tools/libxl/libxl_arch.h
> @@ -65,7 +65,8 @@ _hidden
> int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t domid, int irq);
>
> _hidden
> -void libxl__arch_domain_build_info_setdefault(libxl_domain_build_info
> *b_info);
> +void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> + libxl_domain_build_info
> *b_info);
>
> _hidden
> int libxl__arch_extra_memory(libxl__gc *gc,
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 699fd9ddc6..25dc3defc6 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -953,7 +953,11 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> int rc;
> uint64_t val;
>
> -assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> +if (info->type != LIBXL_DOMAIN_TYPE_PVH) {
> +LOG(ERROR, "Unsupported Arm guest type %s",
> +libxl_domain_type_to_string(info->type));
> +return ERROR_INVAL;
> +}
>
> /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
> val = MASK_INSR(HVM_PARAM_CALLBACK_TYPE_PPI,
> @@ -1110,10 +1114,28 @@ int libxl__arch_domain_map_irq(libxl__gc *gc,
> uint32_t domid, int irq)
> return xc_domain_bind_pt_spi_irq(CTX->xch, domid, irq, irq);
> }
>
> -void libxl__arch_domain_build_info_setdefault(libxl_domain_build_info
> *b_info)
> +void libxl__arch_domain_build_info_setdefault(libxl__gc *gc,
> + libxl_domain_build_info
> *b_info)
> {
> /* ACPI is disabled by default */
> libxl_defbool_setdefault(_info->acpi, false);
> +
> +/*
> + * Arm guest are now considered as PVH by the toolstack. To allow
> + * compatibility with previous toolstack, PV guest are automatically
> + * converted to PVH.
> + */
> +if (b_info->type != LIBXL_DOMAIN_TYPE_PV)
> +return;
> +
> +LOG(WARN, "Converting PV guest to PVH.");
> +LOG(WARN, "Arm guest are now PVH.");
> +LOG(WARN, "Please fix your configuration file/toolstack.");
> +
> +/* Re-initialize type to PVH and all associated fields to defaults. */
> +memset(_info->u, '\0', sizeof(b_info->u));
I don't really like the zeroing done here, but I think it's fine as
long as it's only done when converting from PV -> PVH and after
copying the deprecated fields.
Thansk, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Re: [Xen-devel] [xen-unstable test] 128240: regressions - FAIL
On 02/10/2018 10:29, Jan Beulich wrote: On 01.10.18 at 18:07, wrote: >> On 01/10/2018 17:48, George Dunlap wrote: >>> On 10/01/2018 04:40 PM, Andrew Cooper wrote: If there isn't an obvious fix, then the switch of default scheduler needs reverting until there is a fix present. This is currently blocking master. >>> >>> Agreed. I'd argue for ignoring failures to set scheduler parameters on >>> migrate, on the grounds that this will be less risk to the project as a >>> whole than reverting credit2 again. But either way we should do >>> something quickly. >> >> We should ignore a mismatch of the scheduler. Failures when setting >> parameters for a matching scheduler should not be ignored IMO. > > Well, depends on whether the scheduler was explicitly chosen. > I don't think migration should succeed when e.g. RTDS was used > and isn't available on the destination host. The only way I could think of to tell an explicit vs. an implicit scheduler selection would be to specify a cpupool in the domain's config file. So what about the following: A mismatch of the scheduler should be ignored on the receiving side if no cpupool was specified explicitly for the domain. I have checked that config.c_info.pool_name in JSON data is available only if the cpupool is specified in the domain config. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
