[Xen-devel] [qemu-mainline test] 140832: regressions - FAIL
flight 140832 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/140832/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail REGR. vs. 140282 build-amd64-xsm 6 xen-buildfail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 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-qemuu-win7-amd64 17 guest-stopfail like 140282 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 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 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-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 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail 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 version targeted for testing: qemuu23919ddfd56135cad3cb468a8f54d5a595f024f4 baseline version: qemuuafd760539308a5524accf964107cdb1d54a059e3 Last test of basis 140282 2019-08-18 05:36:51 Z 12 days Failing since140361 2019-08-19 11:36:26 Z 11 days 13 attempts Testing same since 140739 2019-08-28 07:28:02 Z
[Xen-devel] [linux-next test] 140830: tolerable FAIL
flight 140830 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/140830/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail blocked in 140778 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 140778 test-amd64-i386-examine 8 reboot fail like 140778 test-amd64-i386-libvirt 7 xen-boot fail like 140778 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 140778 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 140778 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 140778 test-amd64-i386-xl-shadow 7 xen-boot fail like 140778 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 140778 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 140778 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl-xsm7 xen-boot fail like 140778 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl7 xen-boot fail like 140778 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 140778 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 140778 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail like 140778 test-amd64-i386-xl-raw7 xen-boot fail like 140778 test-amd64-i386-pair 10 xen-boot/src_hostfail like 140778 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 140778 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 140778 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-bootfail like 140778 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail like 140778 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail like 140778 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail like 140778 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl-pvshim 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail like 140778 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 140778 test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 140778 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 140778 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140778 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140778 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 140778 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-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never
Re: [Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
+ Juergen, Boris On Fri, 30 Aug 2019, Christoph Hellwig wrote: > Can we take a step back and figure out what we want to do here? > > AFAICS this function allocates memory for the swiotlb-xen buffer, > and that means it must be <= 32-bit addressable to satisfy the DMA API > guarantees. That means we generally want to use GFP_DMA32 everywhere > that exists, but on systems with odd zones we might want to dip into > GFP_DMA. This also means swiotlb-xen doesn't actually do the right > thing on x86 at the moment. So shouldn't we just have one common > routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32 > set, then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set > and then try that, else default to GFP_KERNEL? Yes, for ARM/ARM64 it makes a lot of sense given that dom0 is 1:1 mapped (pseudo-physical == physical). I'll let Juergen and Boris comment on the x86 side of things, but on x86 PV Dom0 is not 1:1 mapped so GFP_DMA32 is probably not meaningful. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 140817: regressions - FAIL
flight 140817 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/140817/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 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-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13
[Xen-devel] [freebsd-master test] 140831: all pass - PUSHED
flight 140831 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/140831/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 32e0aaee87996d207cd719c68dcdb0a5df7e44f6 baseline version: freebsd 76040af020521b535a066e8df91e224b14ce284f Last test of basis 140746 2019-08-28 09:19:53 Z2 days Testing same since 140831 2019-08-30 09:19:36 Z0 days1 attempts People who touched revisions under test: avg delphij emaste glebius jgh jhb karels kib markj mav mjg np Ryan Moeller trasz yuripv zeising jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd 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/freebsd.git 76040af0205..32e0aaee879 32e0aaee87996d207cd719c68dcdb0a5df7e44f6 -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 140822: regressions - FAIL
flight 140822 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/140822/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 140598 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140598 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140598 test-amd64-amd64-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-i386-libvirt-xsm 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-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-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 version targeted for testing: libvirt c87c42f0eb695b0d0860da81b4fdd2e47ea6d7c7 baseline version: libvirt 9935b435dfee4d130197ee62ae64880ccbcf1855 Last test of basis 140598 2019-08-24 04:19:58 Z6 days Failing since140692 2019-08-27 04:18:58 Z3 days4 attempts Testing same since 140822 2019-08-30 05:54:21 Z0 days1 attempts People who touched revisions under test: Bjoern Walk Boris Fiuczynski Daniel Henrique Barboza Daniel P. Berrangé Jim Fehlig Jonathon Jongsma Ján Tomko Michal Privoznik Nikolay Shirokovskiy Peter Krempa 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 fail 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
[Xen-devel] [ovmf test] 140807: all pass - PUSHED
flight 140807 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/140807/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 37eef91017ad042035090cae46557f9d6e2d5917 baseline version: ovmf abc0155b034230128ad4aaa51ac05a315acfa7c1 Last test of basis 140559 2019-08-23 04:52:13 Z7 days Failing since140684 2019-08-26 22:09:16 Z3 days4 attempts Testing same since 140807 2019-08-29 20:49:08 Z0 days1 attempts People who touched revisions under test: Bob Feng Feng, Bob C Leif Lindholm Michael D Kinney Tim Lewis jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git abc0155b03..37eef91017 37eef91017ad042035090cae46557f9d6e2d5917 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/3] Add logic to use V section entry in THE REST for identifying xen trees
Specifically:
* Move check until after the MAINTAINERS file has been read
* Add get_xen_maintainers_file_version() for check
* Remove top_of_tree as not needed any more
* Faiul with extended error message when used out of tree
Signed-off-by: Lars Kurth
---
scripts/get_maintainer.pl | 58
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 174dfb7..fe84a12 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -265,11 +265,6 @@ if ($email &&
die "$P: Please select at least 1 email option\n";
}
-if (!top_of_tree($xen_path)) {
-die "$P: The current directory does not appear to be "
- . "a Xen source tree.\n";
-}
-
## Read MAINTAINERS for type/value pairs
my @typevalue = ();
@@ -311,6 +306,16 @@ while (<$maint>) {
}
close($maint);
+# Check whether we have a V entry under the REST
+# hnd use it to get the file's version number
+my $maintainers_file_version = get_xen_maintainers_file_version();
+if (!$maintainers_file_version) {
+die "$P: the MAINTAINERS file ".
+ "in the current directory does not appear to be from ".
+ "the xen.git source tree or a sister tree.\n\n".
+ "A 'V: xen-maintainers-' entry under THE REST ".
+ "is needed to identify a Xen MAINTAINERS file.\n\n";
+}
#
# Read mail address map
@@ -564,6 +569,32 @@ sub range_has_maintainer {
return 0;
}
+sub get_xen_maintainers_file_version {
+my $tvi = find_first_section();
+
+while ($tvi < @typevalue) {
+my $start = find_starting_index($tvi);
+my $end = find_ending_index($tvi);
+my $i;
+
+for ($i = $start; $i < $end; $i++) {
+my $line = $typevalue[$i];
+ if ($line =~ m/^V:\s*(.*)/) {
+my $type = $1;
+# Note that get_maintainer_role() requires processing
+# of more of the file. So do it directly
+if ($typevalue[$start] eq "THE REST") {
+if ($line =~ m/xen-maintainers-(.*)/) {
+return $1;
+}
+}
+ }
+}
+$tvi = $end + 1;
+}
+return 0;
+}
+
sub get_maintainers {
%email_hash_name = ();
%email_hash_address = ();
@@ -867,23 +898,6 @@ Notes:
EOT
}
-sub top_of_tree {
-my ($xen_path) = @_;
-
-if ($xen_path ne "" && substr($xen_path,length($xen_path)-1,1) ne "/") {
- $xen_path .= "/";
-}
-if ((-f "${xen_path}COPYING")
-&& (-f "${xen_path}MAINTAINERS")
-&& (-f "${xen_path}Makefile")
-&& (-d "${xen_path}docs")
-&& (-f "${xen_path}CODING_STYLE")
-&& (-d "${xen_path}xen")) {
- return 1;
-}
-return 0;
-}
-
sub parse_email {
my ($formatted_email) = @_;
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/3] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git
Use-case: Allow using both scripts on xen repositories such as mini-os.git, osstest.git, Assumptions: the repository contains a MAINTAINERS file that follows the same conventions as the file in xen.git A suggested template for sister repositories of Xen This file follows the same conventions as outlined in xen.git:MAINTAINERS. Please refer to the file in xen.git for more information. THE REST M: MAINTAINER1 M: MAINTAINER2 L: xen-devel@lists.xenproject.org S: Supported F: */ V: xen-maintainers-1 Changes in v2: * Remove debug message Changes in v3: * Split patch * add_maintainers.pl: do not issue a warning * add_maintainers.pl: introduce processing logic for V: tag * MAINTAINERS: Add V: tag to file Lars Kurth (3): Remove hardcoding from scripts/add_maintainers.pl Add V section entry to allow identification of Xen MAINTAINERS file Add logic to use V section entry in THE REST for identifying xen trees MAINTAINERS| 4 +++- scripts/add_maintainers.pl | 4 +-- scripts/get_maintainer.pl | 58 --- 3 files changed, 42 insertions(+), 24 deletions(-) base-commit: 6c9639a72f0ca3a9430ef75f375877182281fdef -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/3] Add V section entry to allow identification of Xen MAINTAINERS file
This change provides sufficient information to allow get_maintainer.pl / add_maintainers.pl scripts to be run on xen sister repositories such as mini-os.git, osstest.git, etc A suggested template for sister repositories of Xen is This file follows the same conventions as outlined in xen.git:MAINTAINERS. Please refer to the file in xen.git for more information. THE REST M: MAINTAINER1 M: MAINTAINER2 L: xen-devel@lists.xenproject.org S: Supported F: * F: */ V: xen-maintainers-1 Signed-off-by: Lars Kurth --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 77413e0..bb3da43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -97,6 +97,9 @@ Descriptions of section entries: matches patches or files that contain one or more of the words printk, pr_info or pr_err One regex pattern per line. Multiple K: lines acceptable. + V: Version identifier that must be under THE REST and follows + the format: + xen-maintainers- The meaning of nesting: @@ -541,3 +544,4 @@ L: xen-devel@lists.xenproject.org S: Supported F: * F: */ +V: xen-maintainers-1 -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/3] Remove hardcoding from scripts/add_maintainers.pl
Instead of using a hardcoded location, inherit the location from $0 Signed-off-by: Lars Kurth --- scripts/add_maintainers.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl index 09e9f66..5a6d0f6 100755 --- a/scripts/add_maintainers.pl +++ b/scripts/add_maintainers.pl @@ -26,9 +26,9 @@ sub insert (); sub hastag ($$); # Tool Variables -my $get_maintainer = "./scripts/get_maintainer.pl"; - my $tool = $0; +my $get_maintainer = $tool; +$get_maintainer =~ s/add_maintainers/get_maintainer/; my $usage =
Re: [Xen-devel] [Xen-unstable] boot crash while loading AMD microcode due to commit "microcode/amd: fix memory leak"
On 30/08/2019 09:49, Jan Beulich wrote: > On 30.08.2019 04:09, Chao Gao wrote: >> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote: >>> L.S., >>> >>> While testing xen-unstable, my AMD system crashes during early boot while >>> loading microcode with an "Early fatal page fault". >>> Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: >>> fix memory leak" fixes the boot issue. >> >> Sorry for this inconvenience. >> >> Could you apply the patch attached and try it again? > > I'm inclined to take this fix even without waiting for Sander's > feedback (and simply implying your S-o-b). Andrew - what do you > think? > > Jan > Just tested and it works for me, thanks! -- Sander ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 140804: regressions - FAIL
flight 140804 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140804/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 139910 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start.2fail REGR. vs. 139910 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail 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-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 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-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-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-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux01fd1694b93c92ad54fa684dac9c8068ecda8288 baseline version: linux
[Xen-devel] [linux-4.4 test] 140786: regressions - trouble: broken/fail/pass
flight 140786 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140786/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit1 broken test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit1 4 host-install(4) broken pass in 140735 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail in 140632 pass in 140786 test-armhf-armhf-xl 7 xen-boot fail in 140632 pass in 140786 test-armhf-armhf-libvirt 19 leak-check/check fail in 140632 pass in 140786 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail in 140735 pass in 140786 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail in 140735 pass in 140786 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start.2 fail pass in 140632 test-amd64-amd64-xl 7 xen-boot fail pass in 140735 test-armhf-armhf-libvirt-raw 10 debian-di-install fail pass in 140735 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit1 7 xen-boot fail in 140735 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 140735 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 140735 never pass test-amd64-amd64-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-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-amd64-amd64-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-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never
[Xen-devel] Added workflow docs for git-series
See https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git-series It solves some problems with git and makes managing series a little easier, but you still have to use autosquash So, it's not perfect Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 140783: regressions - FAIL
flight 140783 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/140783/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 139936 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 139936 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139936 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139936 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139936 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139936 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139936 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-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-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-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 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-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10
[Xen-devel] [xen-unstable-smoke test] 140836: tolerable all pass - PUSHED
flight 140836 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/140836/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: 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 test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen b376456a78ce893036002186d1003900a3b8833d baseline version: xen eb912011076e76f6c5e4013616a61ba670e7fc15 Last test of basis 140829 2019-08-30 09:00:51 Z0 days Testing same since 140836 2019-08-30 14:00:40 Z0 days1 attempts People who touched revisions under test: Igor Druzhinin Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git eb91201107..b376456a78 b376456a78ce893036002186d1003900a3b8833d -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 140780: regressions - FAIL
flight 140780 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/140780/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 139876 test-amd64-amd64-qemuu-nested-amd 7 xen-bootfail REGR. vs. 139876 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 139876 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 139876 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 139876 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 139876 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 139876 test-xtf-amd64-amd64-37 xen-boot fail REGR. vs. 139876 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 139876 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 139876 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 139876 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 139876 test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 139876 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139876 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139876 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-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-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-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-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-libvirt-raw 12 migrate-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
Re: [Xen-devel] [PATCH v3 4/5] x86/boot: Copy 16-bit boot variables back up to Xen image
On Fri, 2019-08-30 at 17:43 +0200, Jan Beulich wrote: > On 21.08.2019 18:35, David Woodhouse wrote: > > From: David Woodhouse > > > > Ditch the bootsym() access from C code for the variables populated by > > 16-bit boot code. As well as being cleaner this also paves the way for > > not having the 16-bit boot code in low memory for no-real-mode or EFI > > loader boots at all. > > > > These variables are put into a separate .data.boot16 section and > > accessed in low memory during the real-mode boot, then copied back to > > their native location in the Xen image when real mode has finished. > > > > Fix the limit in gdt_48 to admit that trampoline_gdt actually includes > > 7 entries, since we do now use the seventh (BOOT_FS) in late code so it > > matters. Andrew has a patch to further tidy up the GDT and initialise > > accessed bits etc., so I won't go overboard with more than the trivial > > size fix for now. > > > > The bootsym() macro remains in C code purely for the variables which > > are written for the later AP startup and wakeup trampoline to use. > > > > Signed-off-by: David Woodhouse > > --- > > xen/arch/x86/boot/edd.S | 2 ++ > > xen/arch/x86/boot/head.S | 16 +++ > > xen/arch/x86/boot/mem.S | 2 ++ > > xen/arch/x86/boot/trampoline.S| 33 --- > > xen/arch/x86/boot/video.S | 30 +++- > > xen/arch/x86/platform_hypercall.c | 18 - > > xen/arch/x86/setup.c | 22 ++--- > > xen/arch/x86/xen.lds.S| 9 - > > xen/include/asm-x86/edd.h | 1 - > > 9 files changed, 94 insertions(+), 39 deletions(-) > > > > diff --git a/xen/arch/x86/boot/edd.S b/xen/arch/x86/boot/edd.S > > index 434bbbd960..138d04c964 100644 > > --- a/xen/arch/x86/boot/edd.S > > +++ b/xen/arch/x86/boot/edd.S > > @@ -163,6 +163,7 @@ edd_done: > > .Ledd_mbr_sig_skip: > > ret > > > > +.pushsection .data.boot16, "aw", @progbits > > GLOBAL(boot_edd_info_nr) > > .byte 0 > > GLOBAL(boot_mbr_signature_nr) > > @@ -171,3 +172,4 @@ GLOBAL(boot_mbr_signature) > > .fill EDD_MBR_SIG_MAX*8,1,0 > > GLOBAL(boot_edd_info) > > .fill EDD_INFO_MAX * (EDDEXTSIZE + EDDPARMSIZE), 1, 0 > > +.popsection > > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > > index 4118f73683..6d315020d2 100644 > > --- a/xen/arch/x86/boot/head.S > > +++ b/xen/arch/x86/boot/head.S > > @@ -725,6 +725,17 @@ trampoline_setup: > > cmp $sym_offs(__bootsym_seg_stop),%edi > > jb 1b > > > > +/* Relocations for the boot data section. */ > > +mov sym_fs(trampoline_phys),%edx > > +add $(boot_trampoline_end - boot_trampoline_start),%edx > > +mov $sym_offs(__bootdatasym_rel_start),%edi > > +1: > > +mov %fs:(%edi),%eax > > +add %edx,%fs:(%edi,%eax) > > +add $4,%edi > > +cmp $sym_offs(__bootdatasym_rel_stop),%edi > > +jb 1b > > + > > /* Do not parse command line on EFI platform here. */ > > cmpb$0,sym_fs(efi_platform) > > jnz 1f > > @@ -762,6 +773,11 @@ trampoline_setup: > > mov $((boot_trampoline_end - boot_trampoline_start) / 4),%ecx > > rep movsl %fs:(%esi),%es:(%edi) > > > > +/* Copy boot data template to low memory. */ > > +mov $sym_offs(bootdata_start),%esi > > +mov $((bootdata_end - bootdata_start) / 4),%ecx > > +rep movsl %fs:(%esi),%es:(%edi) > > Afaict neither bootdata_start nor bootdata_end are aligned, and so > the difference isn't necessarily a multiple of 4. In fact the > other (preexisting) movsl looks to have the same issue; I wonder > if we propagate bad EDID data for that reason on certain builds / > in certain versions. Hm, I'm not sure I quite realised the distinction between bootdata_start and __bootdata_start (and likewise _end). Now that things are placed in the .data.boot16 section by .pushsection/.popsection can we rely on the ordering, and that the globals in the .S files are actually at the start and end? I thought we *needed* to use the ones in the linker script, and what I should probably do here is kill bootdata_start/bootdata_end completely and rely only on the ones from the linker script? Either that or I should kill the ones in the linker script completely. > > --- a/xen/arch/x86/boot/trampoline.S > > +++ b/xen/arch/x86/boot/trampoline.S > > @@ -47,11 +47,15 @@ > > .long 111b - (off) - .;\ > > .popsection > > > > -#define bootdatasym(s) ((s)-boot_trampoline_start) > > +.pushsection .data.boot16, "aw", @progbits > > +GLOBAL(bootdata_start) > > +.popsection > > + > > +#define bootdatasym(s) > > ((s)-bootdata_start+(boot_trampoline_end-boot_trampoline_start)) > > Please can you add the missing blanks around the binary
Re: [Xen-devel] [PATCH v3 2/5] x86/boot: Split bootsym() into four types of relocations
On Fri, 2019-08-30 at 17:10 +0200, Jan Beulich wrote:
> On 21.08.2019 18:35, David Woodhouse wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -699,14 +699,30 @@ trampoline_setup:
> > cmp $sym_offs(__trampoline_rel_stop),%edi
> > jb 1b
> >
> > -/* Patch in the trampoline segment. */
> > +mov $sym_offs(__trampoline32_rel_start),%edi
> > +1:
> > +mov %fs:(%edi),%eax
> > +add %edx,%fs:(%edi,%eax)
> > +add $4,%edi
> > +cmp $sym_offs(__trampoline32_rel_stop),%edi
> > +jb 1b
> > +
> > +mov $sym_offs(__bootsym_rel_start),%edi
> > +1:
> > +mov %fs:(%edi),%eax
> > +add %edx,%fs:(%edi,%eax)
> > +add $4,%edi
> > +cmp $sym_offs(__bootsym_rel_stop),%edi
> > +jb 1b
>
> With the smaller sets now - are we risking misbehavior if one
> of the relocation sets ends up empty? This wasn't reasonable to
> expect before, but I think it would be nice to have a build-time
> check rather than a hard to debug crash in case this happens.
Or just code it differently as a while() instead of a do{}while() so
that it actually copes with a zero-length section.
> > --- a/xen/arch/x86/boot/trampoline.S
> > +++ b/xen/arch/x86/boot/trampoline.S
> > @@ -16,21 +16,62 @@
> > * not guaranteed to persist.
> > */
> >
> > -/* NB. bootsym() is only usable in real mode, or via BOOT_PSEUDORM_DS. */
> > +/*
> > + * There are four sets of relocations:
> > + *
> > + * bootsym(): Boot-time code relocated to low memory and run only once.
> > + *Only usable at boot; in real mode or via
> > BOOT_PSEUDORM_DS.
> > + * bootdatasym(): Boot-time BIOS-discovered data, relocated back up to Xen
> > + *image after discovery.
> > + * trampsym():Permanent trampoline code relocated into low memory for
> > AP
> > + *startup and wakeup.
> > + * tramp32sym(): 32-bit trampoline code which at boot can be used directly
> > + *from the Xen image in memory, but which will need to be
> > + *relocated into low (well, into *mapped*) memory in order
> > + *to be used for AP startup.
> > + */
> > #undef bootsym
> > #define bootsym(s) ((s)-trampoline_start)
> >
> > #define bootsym_rel(sym, off, opnd...) \
> > bootsym(sym),##opnd; \
> > 111:; \
> > -.pushsection .trampoline_rel, "a"; \
> > +.pushsection .bootsym_rel, "a";\
> > .long 111b - (off) - .;\
> > .popsection
> >
> > #define bootsym_segrel(sym, off) \
> > $0,$bootsym(sym); \
> > 111:; \
> > -.pushsection .trampoline_seg, "a"; \
> > +.pushsection .bootsym_seg, "a";\
> > +.long 111b - (off) - .;\
> > +.popsection
> > +
> > +#define bootdatasym(s) ((s)-trampoline_start)
> > +#define bootdatasym_rel(sym, off, opnd...) \
> > +bootdatasym(sym),##opnd; \
> > +111:; \
> > +.pushsection .bootdatasym_rel, "a";\
> > +.long 111b - (off) - .;\
> > +.popsection
> > +
> > +#undef trampsym
>
> Why this and ...
>
> > +#define trampsym(s) ((s)-trampoline_start)
> > +
> > +#define trampsym_rel(sym, off, opnd...)\
> > +trampsym(sym),##opnd; \
> > +111:; \
> > +.pushsection .trampsym_rel, "a"; \
> > +.long 111b - (off) - .;\
> > +.popsection
> > +
> > +#undef tramp32sym
>
> ... this #undef? You have none ahead of the bootdatasym #define-s,
> and (other than for bootsym) there's not conflicting C level one
> afaics.
>
> > +#define tramp32sym(s) ((s)-trampoline_start)
> > +
> > +#define tramp32sym_rel(sym, off, opnd...) \
> > +tramp32sym(sym),##opnd;\
> > +111:; \
> > +.pushsection .tramp32sym_rel, "a"; \
> > .long 111b - (off) - .;\
> > .popsection
>
> After your reply to my comment regarding the redundancy here I've
> checked (in your git branch) how things end up. Am I mistaken, or
> are the trampsym and tramp32sym #define-s entirely identical
> (except for the relocations section name)? Even between the others
> there's little enough difference, so it continues to be unclear to
> me why you think it's better to have four instances of about the
> same (not entirely trivial) thing.
The distinction is that in a no-real-mode boot tramp32 is used in place
in the Xen image at the physical address it happened to be loaded at,
and then *again* later in the AP/wakeup path. In the latter case it
needs to be moved to low memory (or we need to put the physical
location into idle_pg_table which seemed to
Re: [Xen-devel] [PATCH v7 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
> -Original Message-
> From: Jan Beulich
> Sent: 30 August 2019 15:08
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject: Re: [PATCH v7 5/6] iommu: tidy up iommu_use_hap_pt() and
> need_iommu_pt_sync() macros
>
> On 30.08.2019 10:29, Paul Durrant wrote:
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
> > * default until we find a good solution to resolve it.
> > */
> > bool_t __read_mostly iommu_intpost;
> > -bool_t __read_mostly iommu_hap_pt_share = 1;
> > +
> > +#ifndef CONFIG_ARM
> > +bool __read_mostly iommu_hap_pt_share = true;
> > +#endif
>
> The #idef here should be in line with ...
>
> > @@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
> > iommu_hwdom_passthrough = val;
> > else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
> > iommu_hwdom_strict = val;
> > +#ifndef iommu_hap_pt_share
> > else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
> > iommu_hap_pt_share = val;
> > +#endif
>
> ... the one here, i.e. neither should be Arm-specific. What a specific
> architecture wants should be controlled in a single place (in a header).
Ah, ok. I obviously misunderstood what you meant.
>
> > @@ -268,6 +274,17 @@ struct domain_iommu {
> > #define iommu_set_feature(d, f) set_bit(f, dom_iommu(d)->features)
> > #define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
> >
> > +/* Are we using the domain P2M table as its IOMMU pagetable? */
> > +#define iommu_use_hap_pt(d) \
> > +(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
> > +
> > +/* Does the IOMMU pagetable need to be kept synchronized with the P2M */
> > +#ifdef CONFIG_HAS_PASSTHROUGH
> > +#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
> > +#else
> > +#define need_iommu_pt_sync(d) ({ (void)d; false; })
>
> "d" wants to be parenthesized.
>
Ok.
> With these taken care of (possibly while committing)
> Reviewed-by: Jan Beulich
>
Thanks.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
On 30.08.2019 17:30, Juergen Gross wrote: > On 30.08.19 17:22, Jan Beulich wrote: >> On 30.08.2019 16:29, Juergen Gross wrote: >>> On 30.08.19 16:21, Jan Beulich wrote: On 30.08.2019 10:32, Juergen Gross wrote: > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t); >DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); >DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > > +/* Define a variable length array (depends on compiler). */ > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > +#define __XEN_VARLEN_ARRAY_SIZE > +#elif defined(__GNUC__) > +#define __XEN_VARLEN_ARRAY_SIZE 0 > +#else > +#define __XEN_VARLEN_ARRAY_SIZE 1 /* variable size */ > +#endif To be in line with the intentions, the C90 standard, and io/ring.h I'd suggest to use FLEX instead of VARLEN. Furthermore, especially in a public header, two double leading underscores need to go away. And then, with FLEX in the name, SIZE isn't really appropriate anymore. Therefore I see three possible names: XEN_FLEXIBLE_ARRAY, XEN_FLEX_ARRAY_DIMENSION (possibly just _DIM at its end), or XEN_FLEX_ARRAY_DESIGNATOR. >>> >>> Okay to the "FLEX" part, but the "XEN_" prefix is not working due to >>> compat header generation (that will result in COMPAT_ prefix in the >>> compat headers). >>> >>> So any other ideas for a sensible prefix? >> >> Hmm, ugly. Perhaps all lower case then? Or have > > xen_ and Xen_ are being converted, too. For Xen_ I agree, but for xen_ I only see [ r"(struct|union|enum)\s+(xen_?)?(\w)", r"\1 compat_\3" ], and [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ], , neither of which should match your #define. But perhaps I'm missing something. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/5] x86/boot: Copy 16-bit boot variables back up to Xen image
On 21.08.2019 18:35, David Woodhouse wrote: > From: David Woodhouse > > Ditch the bootsym() access from C code for the variables populated by > 16-bit boot code. As well as being cleaner this also paves the way for > not having the 16-bit boot code in low memory for no-real-mode or EFI > loader boots at all. > > These variables are put into a separate .data.boot16 section and > accessed in low memory during the real-mode boot, then copied back to > their native location in the Xen image when real mode has finished. > > Fix the limit in gdt_48 to admit that trampoline_gdt actually includes > 7 entries, since we do now use the seventh (BOOT_FS) in late code so it > matters. Andrew has a patch to further tidy up the GDT and initialise > accessed bits etc., so I won't go overboard with more than the trivial > size fix for now. > > The bootsym() macro remains in C code purely for the variables which > are written for the later AP startup and wakeup trampoline to use. > > Signed-off-by: David Woodhouse > --- > xen/arch/x86/boot/edd.S | 2 ++ > xen/arch/x86/boot/head.S | 16 +++ > xen/arch/x86/boot/mem.S | 2 ++ > xen/arch/x86/boot/trampoline.S| 33 --- > xen/arch/x86/boot/video.S | 30 +++- > xen/arch/x86/platform_hypercall.c | 18 - > xen/arch/x86/setup.c | 22 ++--- > xen/arch/x86/xen.lds.S| 9 - > xen/include/asm-x86/edd.h | 1 - > 9 files changed, 94 insertions(+), 39 deletions(-) > > diff --git a/xen/arch/x86/boot/edd.S b/xen/arch/x86/boot/edd.S > index 434bbbd960..138d04c964 100644 > --- a/xen/arch/x86/boot/edd.S > +++ b/xen/arch/x86/boot/edd.S > @@ -163,6 +163,7 @@ edd_done: > .Ledd_mbr_sig_skip: > ret > > +.pushsection .data.boot16, "aw", @progbits > GLOBAL(boot_edd_info_nr) > .byte 0 > GLOBAL(boot_mbr_signature_nr) > @@ -171,3 +172,4 @@ GLOBAL(boot_mbr_signature) > .fill EDD_MBR_SIG_MAX*8,1,0 > GLOBAL(boot_edd_info) > .fill EDD_INFO_MAX * (EDDEXTSIZE + EDDPARMSIZE), 1, 0 > +.popsection > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index 4118f73683..6d315020d2 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -725,6 +725,17 @@ trampoline_setup: > cmp $sym_offs(__bootsym_seg_stop),%edi > jb 1b > > +/* Relocations for the boot data section. */ > +mov sym_fs(trampoline_phys),%edx > +add $(boot_trampoline_end - boot_trampoline_start),%edx > +mov $sym_offs(__bootdatasym_rel_start),%edi > +1: > +mov %fs:(%edi),%eax > +add %edx,%fs:(%edi,%eax) > +add $4,%edi > +cmp $sym_offs(__bootdatasym_rel_stop),%edi > +jb 1b > + > /* Do not parse command line on EFI platform here. */ > cmpb$0,sym_fs(efi_platform) > jnz 1f > @@ -762,6 +773,11 @@ trampoline_setup: > mov $((boot_trampoline_end - boot_trampoline_start) / 4),%ecx > rep movsl %fs:(%esi),%es:(%edi) > > +/* Copy boot data template to low memory. */ > +mov $sym_offs(bootdata_start),%esi > +mov $((bootdata_end - bootdata_start) / 4),%ecx > +rep movsl %fs:(%esi),%es:(%edi) Afaict neither bootdata_start nor bootdata_end are aligned, and so the difference isn't necessarily a multiple of 4. In fact the other (preexisting) movsl looks to have the same issue; I wonder if we propagate bad EDID data for that reason on certain builds / in certain versions. > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -47,11 +47,15 @@ > .long 111b - (off) - .;\ > .popsection > > -#define bootdatasym(s) ((s)-boot_trampoline_start) > +.pushsection .data.boot16, "aw", @progbits > +GLOBAL(bootdata_start) > +.popsection > + > +#define bootdatasym(s) > ((s)-bootdata_start+(boot_trampoline_end-boot_trampoline_start)) Please can you add the missing blanks around the binary operators here? (I should perhaps asked this already on the earlier patch adding this #define.) Also it looks like the line might be overly long. > --- a/xen/arch/x86/boot/video.S > +++ b/xen/arch/x86/boot/video.S > @@ -15,10 +15,10 @@ > > #include "video.h" > > -/* Scratch space layout: boot_trampoline_end to boot_trampoline_end+0x1000. > */ > -#define modelist bootsym(boot_trampoline_end) /* 2kB (256 entries) */ > -#define vesa_glob_info (modelist + 0x800)/* 1kB */ > -#define vesa_mode_info (vesa_glob_info + 0x400) /* 1kB */ > +/* Scratch space layout: bootdata_end to bootdata_end+0x1000. */ > +#define modelist(t) bootdatasym_rel(bootdata_end,2,t) /* 2KiB > (256 entries) */ > +#define vesa_glob_info(t) bootdatasym_rel((bootdata_end+0x800),2,t) /* 1KiB > */ > +#define
Re: [Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
On 30.08.19 17:22, Jan Beulich wrote: On 30.08.2019 16:29, Juergen Gross wrote: On 30.08.19 16:21, Jan Beulich wrote: On 30.08.2019 10:32, Juergen Gross wrote: --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); +/* Define a variable length array (depends on compiler). */ +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L +#define __XEN_VARLEN_ARRAY_SIZE +#elif defined(__GNUC__) +#define __XEN_VARLEN_ARRAY_SIZE 0 +#else +#define __XEN_VARLEN_ARRAY_SIZE 1 /* variable size */ +#endif To be in line with the intentions, the C90 standard, and io/ring.h I'd suggest to use FLEX instead of VARLEN. Furthermore, especially in a public header, two double leading underscores need to go away. And then, with FLEX in the name, SIZE isn't really appropriate anymore. Therefore I see three possible names: XEN_FLEXIBLE_ARRAY, XEN_FLEX_ARRAY_DIMENSION (possibly just _DIM at its end), or XEN_FLEX_ARRAY_DESIGNATOR. Okay to the "FLEX" part, but the "XEN_" prefix is not working due to compat header generation (that will result in COMPAT_ prefix in the compat headers). So any other ideas for a sensible prefix? Hmm, ugly. Perhaps all lower case then? Or have xen_ and Xen_ are being converted, too. #define COMPAT_FLEX_... XEN_FLEX_... somewhere? Seems as if doing that in include/public/xen-compat.h is working. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
On 30.08.2019 16:29, Juergen Gross wrote: > On 30.08.19 16:21, Jan Beulich wrote: >> On 30.08.2019 10:32, Juergen Gross wrote: >>> --- a/xen/include/public/xen.h >>> +++ b/xen/include/public/xen.h >>> @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t); >>> DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); >>> DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); >>> >>> +/* Define a variable length array (depends on compiler). */ >>> +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L >>> +#define __XEN_VARLEN_ARRAY_SIZE >>> +#elif defined(__GNUC__) >>> +#define __XEN_VARLEN_ARRAY_SIZE 0 >>> +#else >>> +#define __XEN_VARLEN_ARRAY_SIZE 1 /* variable size */ >>> +#endif >> >> To be in line with the intentions, the C90 standard, and io/ring.h >> I'd suggest to use FLEX instead of VARLEN. Furthermore, especially >> in a public header, two double leading underscores need to go away. >> >> And then, with FLEX in the name, SIZE isn't really appropriate >> anymore. Therefore I see three possible names: XEN_FLEXIBLE_ARRAY, >> XEN_FLEX_ARRAY_DIMENSION (possibly just _DIM at its end), or >> XEN_FLEX_ARRAY_DESIGNATOR. > > Okay to the "FLEX" part, but the "XEN_" prefix is not working due to > compat header generation (that will result in COMPAT_ prefix in the > compat headers). > > So any other ideas for a sensible prefix? Hmm, ugly. Perhaps all lower case then? Or have #define COMPAT_FLEX_... XEN_FLEX_... somewhere? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/5] x86/boot: Split bootsym() into four types of relocations
On 21.08.2019 18:35, David Woodhouse wrote: > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -699,14 +699,30 @@ trampoline_setup: > cmp $sym_offs(__trampoline_rel_stop),%edi > jb 1b > > -/* Patch in the trampoline segment. */ > +mov $sym_offs(__trampoline32_rel_start),%edi > +1: > +mov %fs:(%edi),%eax > +add %edx,%fs:(%edi,%eax) > +add $4,%edi > +cmp $sym_offs(__trampoline32_rel_stop),%edi > +jb 1b > + > +mov $sym_offs(__bootsym_rel_start),%edi > +1: > +mov %fs:(%edi),%eax > +add %edx,%fs:(%edi,%eax) > +add $4,%edi > +cmp $sym_offs(__bootsym_rel_stop),%edi > +jb 1b With the smaller sets now - are we risking misbehavior if one of the relocation sets ends up empty? This wasn't reasonable to expect before, but I think it would be nice to have a build-time check rather than a hard to debug crash in case this happens. > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -16,21 +16,62 @@ > * not guaranteed to persist. > */ > > -/* NB. bootsym() is only usable in real mode, or via BOOT_PSEUDORM_DS. */ > +/* > + * There are four sets of relocations: > + * > + * bootsym(): Boot-time code relocated to low memory and run only once. > + *Only usable at boot; in real mode or via BOOT_PSEUDORM_DS. > + * bootdatasym(): Boot-time BIOS-discovered data, relocated back up to Xen > + *image after discovery. > + * trampsym():Permanent trampoline code relocated into low memory for AP > + *startup and wakeup. > + * tramp32sym(): 32-bit trampoline code which at boot can be used directly > + *from the Xen image in memory, but which will need to be > + *relocated into low (well, into *mapped*) memory in order > + *to be used for AP startup. > + */ > #undef bootsym > #define bootsym(s) ((s)-trampoline_start) > > #define bootsym_rel(sym, off, opnd...) \ > bootsym(sym),##opnd; \ > 111:; \ > -.pushsection .trampoline_rel, "a"; \ > +.pushsection .bootsym_rel, "a";\ > .long 111b - (off) - .;\ > .popsection > > #define bootsym_segrel(sym, off) \ > $0,$bootsym(sym); \ > 111:; \ > -.pushsection .trampoline_seg, "a"; \ > +.pushsection .bootsym_seg, "a";\ > +.long 111b - (off) - .;\ > +.popsection > + > +#define bootdatasym(s) ((s)-trampoline_start) > +#define bootdatasym_rel(sym, off, opnd...) \ > +bootdatasym(sym),##opnd; \ > +111:; \ > +.pushsection .bootdatasym_rel, "a";\ > +.long 111b - (off) - .;\ > +.popsection > + > +#undef trampsym Why this and ... > +#define trampsym(s) ((s)-trampoline_start) > + > +#define trampsym_rel(sym, off, opnd...)\ > +trampsym(sym),##opnd; \ > +111:; \ > +.pushsection .trampsym_rel, "a"; \ > +.long 111b - (off) - .;\ > +.popsection > + > +#undef tramp32sym ... this #undef? You have none ahead of the bootdatasym #define-s, and (other than for bootsym) there's not conflicting C level one afaics. > +#define tramp32sym(s) ((s)-trampoline_start) > + > +#define tramp32sym_rel(sym, off, opnd...) \ > +tramp32sym(sym),##opnd;\ > +111:; \ > +.pushsection .tramp32sym_rel, "a"; \ > .long 111b - (off) - .;\ > .popsection After your reply to my comment regarding the redundancy here I've checked (in your git branch) how things end up. Am I mistaken, or are the trampsym and tramp32sym #define-s entirely identical (except for the relocations section name)? Even between the others there's little enough difference, so it continues to be unclear to me why you think it's better to have four instances of about the same (not entirely trivial) thing. > @@ -48,16 +89,19 @@ > GLOBAL(trampoline_realmode_entry) > mov %cs,%ax > mov %ax,%ds > -movb$0xA5,bootsym(trampoline_cpu_started) > +movb$0xA5,trampsym(trampoline_cpu_started) > cld > cli > -lidtbootsym(idt_48) > -lgdtbootsym(gdt_48) > +lidttrampsym(idt_48) > +lgdttrampsym(gdt_48) > mov $1,%bl# EBX != 0 indicates we are an AP > xor %ax, %ax > inc %ax > lmsw%ax # CR0.PE = 1 (enter protected mode) > -ljmpl $BOOT_CS32,$bootsym_rel(trampoline_protmode_entry,6) > +ljmpl
Re: [Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
On 30.08.19 16:21, Jan Beulich wrote: On 30.08.2019 10:32, Juergen Gross wrote: --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); +/* Define a variable length array (depends on compiler). */ +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L +#define __XEN_VARLEN_ARRAY_SIZE +#elif defined(__GNUC__) +#define __XEN_VARLEN_ARRAY_SIZE 0 +#else +#define __XEN_VARLEN_ARRAY_SIZE 1 /* variable size */ +#endif To be in line with the intentions, the C90 standard, and io/ring.h I'd suggest to use FLEX instead of VARLEN. Furthermore, especially in a public header, two double leading underscores need to go away. And then, with FLEX in the name, SIZE isn't really appropriate anymore. Therefore I see three possible names: XEN_FLEXIBLE_ARRAY, XEN_FLEX_ARRAY_DIMENSION (possibly just _DIM at its end), or XEN_FLEX_ARRAY_DESIGNATOR. Okay to the "FLEX" part, but the "XEN_" prefix is not working due to compat header generation (that will result in COMPAT_ prefix in the compat headers). So any other ideas for a sensible prefix? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/5] x86/boot: Only jump into low trampoline code for real-mode boot
On Fri, 2019-08-30 at 16:25 +0200, Jan Beulich wrote: > On 21.08.2019 18:35, David Woodhouse wrote: > > --- a/xen/arch/x86/boot/head.S > > +++ b/xen/arch/x86/boot/head.S > > @@ -727,7 +727,17 @@ trampoline_setup: > > /* Switch to low-memory stack which lives at the end of > > trampoline region. */ > > mov sym_fs(trampoline_phys),%edi > > lea TRAMPOLINE_SPACE+TRAMPOLINE_STACK_SPACE(%edi),%esp > > +cmpb$0, sym_fs(skip_realmode) > > +jz 1f > > +/* If no-real-mode, jump straight to > > trampoline_protmode_entry */ > > +lea trampoline_protmode_entry- > > trampoline_start(%edi),%eax > > +/* EBX == 0 indicates we are the BP (Boot Processor). */ > > +xor %ebx,%ebx > > +jmp 2f > > +1: > > +/* Go via 16-bit code in trampoline_boot_cpu_entry */ > > lea trampoline_boot_cpu_entry- > > trampoline_start(%edi),%eax > > +2: > > pushl $BOOT_CS32 > > push%eax > > Provided it goes in together with the subsequent change removing this > double jump again > Acked-by: Jan Beulich Thanks. > Of course it would have been nice if within you addition you'd been > consistent with adding (or not) blanks after commas separating insn > operands. Yeah, I can see how that would be useful. I'll do it as I rebase on top of the current staging branch and redo the conflict resolution with Andy's changes. smime.p7s Description: S/MIME cryptographic signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/5] x86/boot: Only jump into low trampoline code for real-mode boot
On 21.08.2019 18:35, David Woodhouse wrote: > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -727,7 +727,17 @@ trampoline_setup: > /* Switch to low-memory stack which lives at the end of trampoline > region. */ > mov sym_fs(trampoline_phys),%edi > lea TRAMPOLINE_SPACE+TRAMPOLINE_STACK_SPACE(%edi),%esp > +cmpb$0, sym_fs(skip_realmode) > +jz 1f > +/* If no-real-mode, jump straight to trampoline_protmode_entry */ > +lea trampoline_protmode_entry-trampoline_start(%edi),%eax > +/* EBX == 0 indicates we are the BP (Boot Processor). */ > +xor %ebx,%ebx > +jmp 2f > +1: > +/* Go via 16-bit code in trampoline_boot_cpu_entry */ > lea trampoline_boot_cpu_entry-trampoline_start(%edi),%eax > +2: > pushl $BOOT_CS32 > push%eax Provided it goes in together with the subsequent change removing this double jump again Acked-by: Jan Beulich Of course it would have been nice if within you addition you'd been consistent with adding (or not) blanks after commas separating insn operands. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
On 30.08.2019 10:32, Juergen Gross wrote: > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -53,6 +53,15 @@ DEFINE_XEN_GUEST_HANDLE(uint64_t); > DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); > DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > > +/* Define a variable length array (depends on compiler). */ > +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > +#define __XEN_VARLEN_ARRAY_SIZE > +#elif defined(__GNUC__) > +#define __XEN_VARLEN_ARRAY_SIZE 0 > +#else > +#define __XEN_VARLEN_ARRAY_SIZE 1 /* variable size */ > +#endif To be in line with the intentions, the C90 standard, and io/ring.h I'd suggest to use FLEX instead of VARLEN. Furthermore, especially in a public header, two double leading underscores need to go away. And then, with FLEX in the name, SIZE isn't really appropriate anymore. Therefore I see three possible names: XEN_FLEXIBLE_ARRAY, XEN_FLEX_ARRAY_DIMENSION (possibly just _DIM at its end), or XEN_FLEX_ARRAY_DESIGNATOR. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 6/6] introduce a 'passthrough' configuration option to xl.cfg...
> On 30 Aug 2019, at 09:29, Paul Durrant wrote: > > tools/ocaml/libs/xc/xenctrl.ml | 4 + > tools/ocaml/libs/xc/xenctrl.mli | 4 + > tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- The OCaml part looks good to me. Options are represented on the OCaml side as a list (of an enumeration type) and a bit vector in C and the bindings translate between the two. — C -- Acked-by: Christian Lindig ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
On 30.08.2019 10:29, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
> * default until we find a good solution to resolve it.
> */
> bool_t __read_mostly iommu_intpost;
> -bool_t __read_mostly iommu_hap_pt_share = 1;
> +
> +#ifndef CONFIG_ARM
> +bool __read_mostly iommu_hap_pt_share = true;
> +#endif
The #idef here should be in line with ...
> @@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
> iommu_hwdom_passthrough = val;
> else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
> iommu_hwdom_strict = val;
> +#ifndef iommu_hap_pt_share
> else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
> iommu_hap_pt_share = val;
> +#endif
... the one here, i.e. neither should be Arm-specific. What a specific
architecture wants should be controlled in a single place (in a header).
> @@ -268,6 +274,17 @@ struct domain_iommu {
> #define iommu_set_feature(d, f) set_bit(f, dom_iommu(d)->features)
> #define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
>
> +/* Are we using the domain P2M table as its IOMMU pagetable? */
> +#define iommu_use_hap_pt(d) \
> +(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
> +
> +/* Does the IOMMU pagetable need to be kept synchronized with the P2M */
> +#ifdef CONFIG_HAS_PASSTHROUGH
> +#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
> +#else
> +#define need_iommu_pt_sync(d) ({ (void)d; false; })
"d" wants to be parenthesized.
With these taken care of (possibly while committing)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 4/6] remove late (on-demand) construction of IOMMU page tables
On 30.08.2019 10:29, Paul Durrant wrote: > Now that there is a per-domain IOMMU-enable flag, which should be set if > any device is going to be passed through, stop deferring page table > construction until the assignment is done. Also don't tear down the tables > again when the last device is de-assigned; defer that task until domain > destruction. > > This allows the has_iommu_pt() helper and iommu_status enumeration to be > removed. Calls to has_iommu_pt() are simply replaced by calls to > is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can > also be replaced by calls to iommu_use_hap_pt(). > The arch_iommu_populate_page_table() and iommu_construct() functions become > redundant, as does the 'strict mode' dom0 page_list mapping code in > iommu_hwdom_init(), and iommu_teardown() can be made static is its only > remaining caller, iommu_domain_destroy(), is within the same source > module. > > All in all, about 220 lines of code are removed from the hypervisor. > > NOTE: This patch will cause a small amount of extra resource to be used > to accommodate IOMMU page tables that may never be used, since the > per-domain IOMMU-enable flag is currently set to the value of the > global iommu_enable flag. A subsequent patch will add an option to > the toolstack to allow it to be turned off if there is no intention > to assign passthrough hardware to the domain. > To account for the extra resource, 'iommu_memkb' has been added to > domain_build_info. This patch sets it unconditionally to a value > calculated based on the domain's maximum memory but, when the > toolstack option mentioned above is added, it can be set to zero > if the per-domain IOMMU-enable flag is turned off. > > Signed-off-by: Paul Durrant > Reviewed-by: Alexandru Isaila > Acked-by: Razvan Cojocaru Hypervisor parts Reviewed-by: Jan Beulich And thanks for doing the tool stack adjustment! Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 3/6] use is_iommu_enabled() where appropriate...
> -Original Message-
> From: Jan Beulich
> Sent: 30 August 2019 14:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suravee Suthikulpanit
> ; JulienGrall
> ; Andrew Cooper ; Roger Pau
> Monne
> ; Volodymyr Babchuk ;
> George Dunlap
> ; Jun Nakajima ; Kevin Tian
> ;
> Stefano Stabellini ; Daniel De Graaf
> ; WeiLiu
>
> Subject: Re: [PATCH v7 3/6] use is_iommu_enabled() where appropriate...
>
> On 30.08.2019 10:29, Paul Durrant wrote:
> > --- a/xen/include/asm-x86/iommu.h
> > +++ b/xen/include/asm-x86/iommu.h
> > @@ -61,8 +61,17 @@ extern struct iommu_ops iommu_ops;
> >
> > #ifdef NDEBUG
> > # include
> > -# define iommu_call(ops, fn, args...) alternative_call(iommu_ops.fn, ##
> > args)
> > -# define iommu_vcall(ops, fn, args...) alternative_vcall(iommu_ops.fn, ##
> > args)
> > +# define iommu_call(ops, fn, args...) \
> > +({\
> > +(void)ops;\
> > +alternative_call(iommu_ops.fn, ## args); \
> > +})
> > +
> > +# define iommu_vcall(ops, fn, args...)\
> > +({\
> > +(void)ops;\
> > +alternative_vcall(iommu_ops.fn, ## args); \
> > +})
> > #endif
>
> While unlikely to become an issue, "ops" should be parenthesized
> here. Also we commonly (but, granted, not consistently) put ({ on
> the #define line. Can both be done while committing.
>
Ok, thanks.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 3/6] use is_iommu_enabled() where appropriate...
On 30.08.2019 10:29, Paul Durrant wrote:
> --- a/xen/include/asm-x86/iommu.h
> +++ b/xen/include/asm-x86/iommu.h
> @@ -61,8 +61,17 @@ extern struct iommu_ops iommu_ops;
>
> #ifdef NDEBUG
> # include
> -# define iommu_call(ops, fn, args...) alternative_call(iommu_ops.fn, ##
> args)
> -# define iommu_vcall(ops, fn, args...) alternative_vcall(iommu_ops.fn, ##
> args)
> +# define iommu_call(ops, fn, args...) \
> +({\
> +(void)ops;\
> +alternative_call(iommu_ops.fn, ## args); \
> +})
> +
> +# define iommu_vcall(ops, fn, args...)\
> +({\
> +(void)ops;\
> +alternative_vcall(iommu_ops.fn, ## args); \
> +})
> #endif
While unlikely to become an issue, "ops" should be parenthesized
here. Also we commonly (but, granted, not consistently) put ({ on
the #define line. Can both be done while committing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
On 30.08.2019 10:29, Paul Durrant wrote: > This patch introduces a common domain creation flag to determine whether > the domain is permitted to make use of the IOMMU. Currently the flag is > always set (for both dom0 and domU) if the IOMMU is globally enabled > (i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject > the flag if !iommu_enabled. > > A new helper function, is_iommu_enabled(), is added to test the flag and > iommu_domain_init() will return immediately if !is_iommu_enabled(). This is > slightly different to the previous behaviour based on !iommu_enabled where > the call to arch_iommu_domain_init() was made regardless, however it appears > that this call was only necessary to initialize the dt_devices list for ARM > such that iommu_release_dt_devices() can be called unconditionally by > domain_relinquish_resources(). Adding a simple check of is_iommu_enabled() > into iommu_release_dt_devices() keeps this unconditional call working. > > No functional change should be observed with this patch applied. > > Subsequent patches will allow the toolstack to control whether use of the > IOMMU is enabled for a domain. > > NOTE: The introduction of the is_iommu_enabled() helper function might > seem excessive but its use is expected to increase with subsequent > patches. Also, having iommu_domain_init() bail before calling > arch_iommu_domain_init() is not strictly necessary, but I think the > consequent addition of the call to is_iommu_enabled() in > iommu_release_dt_devices() makes the code clearer. > > Signed-off-by: Paul Durrant > Reviewed-by: "Roger Pau Monné" Hypervisor parts (non-Arm) Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] evtchn: Introduce a per-guest knob to control FIFO ABI
On 19.08.2019 14:08, Eslam Elnikety wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1170,6 +1170,7 @@ long do_event_channel_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>
> case EVTCHNOP_init_control: {
> struct evtchn_init_control init_control;
> +
> if ( copy_from_guest(_control, arg, 1) != 0 )
> return -EFAULT;
> rc = evtchn_fifo_init_control(_control);
Stray (leftover?) change. If intended, it should be a separate
patch dealing with all similar issues within this switch().
Apart from this cosmetic adjustment (which could be done by
the committer if no other need for a v4 arises) I can live with
this change in its current shape now, but I'm hesitant to give
my ack for the reason stated during v1/v2 review.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 0/3] x86: S3 resume adjustments
On 30.08.2019 15:38, Jan Beulich wrote:
> 1: x86/ACPI: restore VESA mode upon resume from S3
> 2: x86: a little bit of 16-bit video mode setting code cleanup
> 3: x86: shrink video_{flags,mode} to {8,16} bits
And (sadly) the patches as attachments again.
Jan
x86/ACPI: restore VESA mode upon resume from S3
In order for "acpi_sleep=s3_mode" to have any effect, we should record
the video mode we switched to during boot. Since right now there's mode
setting code for VESA modes only in the resume case, record the mode
just in that one case.
Signed-off-by: Jan Beulich
---
I'm wondering actually whether the user having to explicitly request the
mode restoration is a good model: Why would we _not_ want to restore the
mode we've set during boot? In the worst case Dom0 kernel or X will
change the mode another time.
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -455,14 +455,17 @@ check_vesa:
cmpb$0x99, %al
jnz _setbad # Doh! No linear frame buffer.
+pushw %bx
subb$VIDEO_FIRST_VESA>>8, %bh
orw $0x4000, %bx# Use linear frame buffer
movw$0x4f02, %ax# VESA BIOS mode set call
int $0x10
+popw%bx
cmpw$0x004f, %ax# AL=4f if implemented
jnz _setbad # AH=0 if OK
movb$1, bootsym(graphic_mode) # flag graphic mode
+movw%bx, bootsym(video_mode)
stc
ret
x86: a little bit of 16-bit video mode setting code cleanup
To "compensate" for the code size growth by an earlier change:
- drop "trampoline" labels (in almost all cases the target label is
reachable with an 8-bit-displacement branch anyway, and a single 16-
bit-displacement branch is still better than a pair of two branches)
- drop an entirely dead insn from wakeup.S:mode_setw
- reduce code size in a few other (obvious I hope) cases, by more
suitable insn/operands selection
Also drop redundant #define-s (move suitable #include a little earlier
instead) and add two alignment directives.
Signed-off-by: Jan Beulich
---
v2: Minor adjustment to description. Re-base.
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -176,6 +176,7 @@ start64:
jmpq*%rdi
+#include "video.h"
#include "wakeup.S"
.balign 8
@@ -282,8 +283,6 @@ trampoline_boot_cpu_entry:
/* Jump to the common bootstrap entry point. */
jmp trampoline_protmode_entry
-#include "video.h"
-
.align 2
/* Keep in sync with cmdline.c:early_boot_opts_t type! */
early_boot_opts:
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -384,9 +384,6 @@ lmbad: leawbootsym(unknt), %si
jmp mode_menu
lmdef: ret
-_setrec:jmp setrec # Ugly...
-_set_80x25: jmp set_80x25
-
# Setting of user mode (AX=mode ID) => CF=success
mode_set:
movw%ax, bootsym(boot_vid_mode)
@@ -396,7 +393,7 @@ mode_set:
je setvesabysize
testb $VIDEO_RECALC>>8, %ah
-jnz _setrec
+jnz setrec
cmpb$VIDEO_FIRST_SPECIAL>>8, %ah
jz setspc
@@ -421,7 +418,7 @@ setspc: xorb%bh, %bh
setmenu:
orb %al, %al# 80x25 is an exception
-jz _set_80x25
+jz set_80x25
pushw %bx # Set mode chosen from menu
callmode_table # Build the mode table
@@ -441,36 +438,32 @@ check_vesa:
cmpw$0x004f, %ax
jnz setbad
-leawvesa_mode_info, %di
-subb$VIDEO_FIRST_VESA>>8, %bh
-movw%bx, %cx# Get mode information structure
+leawvesa_mode_info, %di # Get mode information structure
+leaw-VIDEO_FIRST_VESA(%bx), %cx
movw$0x4f01, %ax
int $0x10
-addb$VIDEO_FIRST_VESA>>8, %bh
cmpw$0x004f, %ax
jnz setbad
movb(%di), %al # Check mode attributes.
andb$0x99, %al
cmpb$0x99, %al
-jnz _setbad # Doh! No linear frame buffer.
+jnz setbad # Doh! No linear frame buffer.
pushw %bx
subb$VIDEO_FIRST_VESA>>8, %bh
-orw $0x4000, %bx# Use linear frame buffer
+orb $0x40, %bh # Use linear frame buffer
movw$0x4f02, %ax# VESA BIOS mode set call
int $0x10
popw%bx
cmpw$0x004f, %ax# AL=4f if implemented
-jnz _setbad # AH=0 if OK
+jnz setbad # AH=0 if OK
movb$1, bootsym(graphic_mode) # flag graphic mode
movw%bx, bootsym(video_mode)
stc
ret
-_setbad: jmpsetbad #
[Xen-devel] [PATCH v2 3/3] x86: shrink video_{flags, mode} to {8, 16} bits
We really don't need them to be any wider. Also remove the C level declaration (and hence also the GLOBAL) of video_mode altogether; it's used in assembly code only. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/boot/wakeup.S +++ b/xen/arch/x86/boot/wakeup.S @@ -82,10 +82,9 @@ bogus_real_magic: .align 4 real_magic: .long 0x12345678 -GLOBAL(video_mode) -.long 0 +video_mode: .word 0 GLOBAL(video_flags) -.long 0 +.byte 0 .code32 --- a/xen/include/asm-x86/config.h +++ b/xen/include/asm-x86/config.h @@ -99,7 +99,9 @@ extern char trampoline_realmode_entry[]; extern unsigned int trampoline_xen_phys_start; extern unsigned char trampoline_cpu_started; extern char wakeup_start[]; -extern unsigned int video_mode, video_flags; + +extern unsigned char video_flags; + extern unsigned short boot_edid_caps; extern unsigned char boot_edid_info[128]; #endif ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/3] x86: a little bit of 16-bit video mode setting code cleanup
To "compensate" for the code size growth by an earlier change: - drop "trampoline" labels (in almost all cases the target label is reachable with an 8-bit-displacement branch anyway, and a single 16- bit-displacement branch is still better than a pair of two branches) - drop an entirely dead insn from wakeup.S:mode_setw - reduce code size in a few other (obvious I hope) cases, by more suitable insn/operands selection Also drop redundant #define-s (move suitable #include a little earlier instead) and add two alignment directives. Signed-off-by: Jan Beulich --- v2: Minor adjustment to description. Re-base. --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -176,6 +176,7 @@ start64: jmpq*%rdi +#include "video.h" #include "wakeup.S" .balign 8 @@ -282,8 +283,6 @@ trampoline_boot_cpu_entry: /* Jump to the common bootstrap entry point. */ jmp trampoline_protmode_entry -#include "video.h" - .align 2 /* Keep in sync with cmdline.c:early_boot_opts_t type! */ early_boot_opts: --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -384,9 +384,6 @@ lmbad: leawbootsym(unknt), %si jmp mode_menu lmdef: ret -_setrec:jmp setrec # Ugly... -_set_80x25: jmp set_80x25 - # Setting of user mode (AX=mode ID) => CF=success mode_set: movw%ax, bootsym(boot_vid_mode) @@ -396,7 +393,7 @@ mode_set: je setvesabysize testb $VIDEO_RECALC>>8, %ah -jnz _setrec +jnz setrec cmpb$VIDEO_FIRST_SPECIAL>>8, %ah jz setspc @@ -421,7 +418,7 @@ setspc: xorb%bh, %bh setmenu: orb %al, %al# 80x25 is an exception -jz _set_80x25 +jz set_80x25 pushw %bx # Set mode chosen from menu callmode_table # Build the mode table @@ -441,36 +438,32 @@ check_vesa: cmpw$0x004f, %ax jnz setbad -leawvesa_mode_info, %di -subb$VIDEO_FIRST_VESA>>8, %bh -movw%bx, %cx# Get mode information structure +leawvesa_mode_info, %di # Get mode information structure +leaw-VIDEO_FIRST_VESA(%bx), %cx movw$0x4f01, %ax int $0x10 -addb$VIDEO_FIRST_VESA>>8, %bh cmpw$0x004f, %ax jnz setbad movb(%di), %al # Check mode attributes. andb$0x99, %al cmpb$0x99, %al -jnz _setbad # Doh! No linear frame buffer. +jnz setbad # Doh! No linear frame buffer. pushw %bx subb$VIDEO_FIRST_VESA>>8, %bh -orw $0x4000, %bx# Use linear frame buffer +orb $0x40, %bh # Use linear frame buffer movw$0x4f02, %ax# VESA BIOS mode set call int $0x10 popw%bx cmpw$0x004f, %ax# AL=4f if implemented -jnz _setbad # AH=0 if OK +jnz setbad # AH=0 if OK movb$1, bootsym(graphic_mode) # flag graphic mode movw%bx, bootsym(video_mode) stc ret -_setbad: jmpsetbad # Ugly... - # Recalculate vertical display end registers -- this fixes various # inconsistencies of extended modes on many adapters. Called when # the VIDEO_RECALC flag is set in the mode ID. @@ -515,7 +508,7 @@ setvesabysize: leawmodelist,%si 1: add $8,%si cmpw$ASK_VGA,-8(%si)# End? -je _setbad +je setbad movw-6(%si),%ax cmpw%ax,bootsym(vesa_size)+0 jne 1b @@ -948,6 +941,7 @@ store_edid: #endif ret +.p2align 1 mt_end: .word 0 # End of video mode table if built edit_buf: .space 6 # Line editor buffer card_name: .word 0 # Pointer to adapter name @@ -991,6 +985,7 @@ vesa_name: .asciz "VESA" name_bann: .asciz "Video adapter: " +.p2align 1 force_size: .word 0 # Use this size instead of the one in BIOS vars GLOBAL(boot_vid_info) --- a/xen/arch/x86/boot/wakeup.S +++ b/xen/arch/x86/boot/wakeup.S @@ -30,7 +30,7 @@ ENTRY(wakeup_start) jne bogus_real_magic # for acpi_sleep=s3_bios -testl $1, wakesym(video_flags) +testb $1, wakesym(video_flags) jz 1f lcall $0xc000, $3 movw%cs, %ax# In case messed by BIOS @@ -38,9 +38,9 @@ ENTRY(wakeup_start) movw%ax, %ss# Need this? How to ret if clobbered? 1: # for acpi_sleep=s3_mode -testl $2, wakesym(video_flags) +testb $2, wakesym(video_flags) jz 1f -
[Xen-devel] [PATCH v2 1/3] x86/ACPI: restore VESA mode upon resume from S3
In order for "acpi_sleep=s3_mode" to have any effect, we should record the video mode we switched to during boot. Since right now there's mode setting code for VESA modes only in the resume case, record the mode just in that one case. Signed-off-by: Jan Beulich --- I'm wondering actually whether the user having to explicitly request the mode restoration is a good model: Why would we _not_ want to restore the mode we've set during boot? In the worst case Dom0 kernel or X will change the mode another time. --- a/xen/arch/x86/boot/video.S +++ b/xen/arch/x86/boot/video.S @@ -455,14 +455,17 @@ check_vesa: cmpb$0x99, %al jnz _setbad # Doh! No linear frame buffer. +pushw %bx subb$VIDEO_FIRST_VESA>>8, %bh orw $0x4000, %bx# Use linear frame buffer movw$0x4f02, %ax# VESA BIOS mode set call int $0x10 +popw%bx cmpw$0x004f, %ax# AL=4f if implemented jnz _setbad # AH=0 if OK movb$1, bootsym(graphic_mode) # flag graphic mode +movw%bx, bootsym(video_mode) stc ret ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/3] x86: S3 resume adjustments
1: x86/ACPI: restore VESA mode upon resume from S3
2: x86: a little bit of 16-bit video mode setting code cleanup
3: x86: shrink video_{flags,mode} to {8,16} bits
Patch 1 is meant to address an issue I've observed while testing
the v1 patch that was committed already, and patch 2 is simply a
collection of misc changes noticed while putting together patch 1
as possibly worthwhile to make. Patch 3 is a result of v1 review
feedback.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RESEND/PING] timers: limit heap size
First and foremost make timer_softirq_action() avoid growing the heap
if its new size can't be stored without truncation. 64k entries is a
lot, and I don't think we're at risk of actually running into the issue,
but I also think it's better not to allow for hard to debug problems to
occur in the first place.
Furthermore also adjust the code such the size/limit fields becoming
unsigned int would at least work from a mere sizing point of view. For
this also switch various uses of plain int to unsigned int.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v2: Log (once) when heap limit would have been exceeded.
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -63,9 +63,9 @@ static struct heap_metadata *heap_metada
}
/* Sink down element @pos of @heap. */
-static void down_heap(struct timer **heap, int pos)
+static void down_heap(struct timer **heap, unsigned int pos)
{
-int sz = heap_metadata(heap)->size, nxt;
+unsigned int sz = heap_metadata(heap)->size, nxt;
struct timer *t = heap[pos];
while ( (nxt = (pos << 1)) <= sz )
@@ -84,7 +84,7 @@ static void down_heap(struct timer **hea
}
/* Float element @pos up @heap. */
-static void up_heap(struct timer **heap, int pos)
+static void up_heap(struct timer **heap, unsigned int pos)
{
struct timer *t = heap[pos];
@@ -103,8 +103,8 @@ static void up_heap(struct timer **heap,
/* Delete @t from @heap. Return TRUE if new top of heap. */
static int remove_from_heap(struct timer **heap, struct timer *t)
{
-int sz = heap_metadata(heap)->size;
-int pos = t->heap_offset;
+unsigned int sz = heap_metadata(heap)->size;
+unsigned int pos = t->heap_offset;
if ( unlikely(pos == sz) )
{
@@ -130,7 +130,7 @@ static int remove_from_heap(struct timer
/* Add new entry @t to @heap. Return TRUE if new top of heap. */
static int add_to_heap(struct timer **heap, struct timer *t)
{
-int sz = heap_metadata(heap)->size;
+unsigned int sz = heap_metadata(heap)->size;
/* Fail if the heap is full. */
if ( unlikely(sz == heap_metadata(heap)->limit) )
@@ -462,9 +462,17 @@ static void timer_softirq_action(void)
if ( unlikely(ts->list != NULL) )
{
/* old_limit == (2^n)-1; new_limit == (2^(n+4))-1 */
-int old_limit = heap_metadata(heap)->limit;
-int new_limit = ((old_limit + 1) << 4) - 1;
-struct timer **newheap = xmalloc_array(struct timer *, new_limit + 1);
+unsigned int old_limit = heap_metadata(heap)->limit;
+unsigned int new_limit = ((old_limit + 1) << 4) - 1;
+struct timer **newheap = NULL;
+
+/* Don't grow the heap beyond what is representable in its metadata. */
+if ( new_limit == (typeof(heap_metadata(heap)->limit))new_limit &&
+ new_limit + 1 )
+newheap = xmalloc_array(struct timer *, new_limit + 1);
+else
+printk_once(XENLOG_WARNING "CPU%u: timer heap limit reached\n",
+smp_processor_id());
if ( newheap != NULL )
{
spin_lock_irq(>lock);
@@ -543,7 +551,7 @@ static void dump_timerq(unsigned char ke
struct timers *ts;
unsigned long flags;
s_time_t now = NOW();
-inti, j;
+unsigned int i, j;
printk("Dumping timer queues:\n");
@@ -555,7 +563,7 @@ static void dump_timerq(unsigned char ke
spin_lock_irqsave(>lock, flags);
for ( j = 1; j <= heap_metadata(ts->heap)->size; j++ )
dump_timer(ts->heap[j], now);
-for ( t = ts->list, j = 0; t != NULL; t = t->list_next, j++ )
+for ( t = ts->list; t != NULL; t = t->list_next )
dump_timer(t, now);
spin_unlock_irqrestore(>lock, flags);
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RESEND/PING] core-parking: interact with runtime SMT-disabling
When disabling SMT at runtime, secondary threads should no longer be
candidates for bringing back up in response to _PUD ACPI events. Purge
them from the tracking array.
Doing so involves adding locking to guard accounting data in the core
parking code. While adding the declaration for the lock, take the
liberty to drop two unnecessary forward function declarations.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -128,6 +128,9 @@ static long smt_up_down_helper(void *dat
if ( !(x86_cpu_to_apicid[cpu] & sibling_mask) )
continue;
+if ( !up && core_parking_remove(cpu) )
+continue;
+
ret = up ? cpu_up_helper(_p(cpu))
: cpu_down_helper(_p(cpu));
--- a/xen/common/core_parking.c
+++ b/xen/common/core_parking.c
@@ -25,9 +25,7 @@
#define CORE_PARKING_INCREMENT 1
#define CORE_PARKING_DECREMENT 2
-static unsigned int core_parking_power(unsigned int event);
-static unsigned int core_parking_performance(unsigned int event);
-
+static DEFINE_SPINLOCK(accounting_lock);
static uint32_t cur_idle_nums;
static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1};
@@ -100,10 +98,10 @@ static unsigned int core_parking_perform
break;
case CORE_PARKING_DECREMENT:
-{
-cpu = core_parking_cpunum[cur_idle_nums -1];
-}
-break;
+spin_lock(_lock);
+cpu = core_parking_cpunum[cur_idle_nums - 1];
+spin_unlock(_lock);
+break;
default:
break;
@@ -158,10 +156,10 @@ static unsigned int core_parking_power(u
break;
case CORE_PARKING_DECREMENT:
-{
-cpu = core_parking_cpunum[cur_idle_nums -1];
-}
-break;
+spin_lock(_lock);
+cpu = core_parking_cpunum[cur_idle_nums - 1];
+spin_unlock(_lock);
+break;
default:
break;
@@ -185,7 +183,11 @@ long core_parking_helper(void *data)
ret = cpu_down(cpu);
if ( ret )
return ret;
+
+spin_lock(_lock);
+BUG_ON(cur_idle_nums >= ARRAY_SIZE(core_parking_cpunum));
core_parking_cpunum[cur_idle_nums++] = cpu;
+spin_unlock(_lock);
}
while ( cur_idle_nums > idle_nums )
@@ -194,12 +196,43 @@ long core_parking_helper(void *data)
ret = cpu_up(cpu);
if ( ret )
return ret;
-core_parking_cpunum[--cur_idle_nums] = -1;
+
+if ( !core_parking_remove(cpu) )
+{
+ret = cpu_down(cpu);
+if ( ret == -EEXIST )
+ret = 0;
+if ( ret )
+break;
+}
}
return ret;
}
+bool core_parking_remove(unsigned int cpu)
+{
+unsigned int i;
+bool found = false;
+
+spin_lock(_lock);
+
+for ( i = 0; i < cur_idle_nums; ++i )
+if ( core_parking_cpunum[i] == cpu )
+{
+found = true;
+--cur_idle_nums;
+break;
+}
+
+for ( ; i < cur_idle_nums; ++i )
+core_parking_cpunum[i] = core_parking_cpunum[i + 1];
+
+spin_unlock(_lock);
+
+return found;
+}
+
uint32_t get_cur_idle_nums(void)
{
return cur_idle_nums;
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -63,6 +63,7 @@ long cpu_up_helper(void *data);
long cpu_down_helper(void *data);
long core_parking_helper(void *data);
+bool core_parking_remove(unsigned int cpu);
uint32_t get_cur_idle_nums(void);
/*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/domain: don't destroy IOREQ servers on soft reset
On 30.08.2019 14:12, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 30 August 2019 12:57
>> To: xen-devel@lists.xenproject.org
>> Cc: jbeul...@suse.com; Andrew Cooper ; Paul
>> Durrant
>> ; w...@xen.org; Roger Pau Monne
>> ; Igor Druzhinin
>>
>> Subject: [PATCH] x86/domain: don't destroy IOREQ servers on soft reset
>>
>> Performing soft reset should not opportunistically kill IOREQ servers
>> for device emulators that might be currently running for a domain.
>> Every emulator is supposed to clean up IOREQ servers for itself on exit.
>> This allows a toolstack to elect whether or not a particular device
>> model should be restarted.
>>
>> The original code was introduced in 3235cbfe ("arch-specific hooks for
>> domain_soft_reset()") likely due to the fact 'default' IOREQ server
>> existed in Xen at the time and used by QEMU didn't have an API call to
>> destroy. Since the removal of 'default' IOREQ server from Xen this
>> reason has gone away.
>>
>> Since commit ba7fdd64b ("xen: cleanup IOREQ server on exit") QEMU now
>> destroys IOREQ server for itself as every other device emulator
>> is supposed to do. It's now safe to remove this code from soft reset
>> path - existing systems with old QEMU should be able to work as
>> even if there are IOREQ servers left behind, a new QEMU instance will
>> override its ranges anyway.
>>
>> Signed-off-by: Igor Druzhinin
>
> Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 140829: tolerable all pass - PUSHED
flight 140829 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/140829/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: 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 test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen eb912011076e76f6c5e4013616a61ba670e7fc15 baseline version: xen 41c7700a00011ad08be3c9d71126b67e08e58ac3 Last test of basis 140800 2019-08-29 14:00:34 Z0 days Testing same since 140829 2019-08-30 09:00:51 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Chao Gao Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 41c7700a00..eb91201107 eb912011076e76f6c5e4013616a61ba670e7fc15 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/domain: don't destroy IOREQ servers on soft reset
> -Original Message-
> From: Igor Druzhinin
> Sent: 30 August 2019 12:57
> To: xen-devel@lists.xenproject.org
> Cc: jbeul...@suse.com; Andrew Cooper ; Paul Durrant
> ; w...@xen.org; Roger Pau Monne
> ; Igor Druzhinin
>
> Subject: [PATCH] x86/domain: don't destroy IOREQ servers on soft reset
>
> Performing soft reset should not opportunistically kill IOREQ servers
> for device emulators that might be currently running for a domain.
> Every emulator is supposed to clean up IOREQ servers for itself on exit.
> This allows a toolstack to elect whether or not a particular device
> model should be restarted.
>
> The original code was introduced in 3235cbfe ("arch-specific hooks for
> domain_soft_reset()") likely due to the fact 'default' IOREQ server
> existed in Xen at the time and used by QEMU didn't have an API call to
> destroy. Since the removal of 'default' IOREQ server from Xen this
> reason has gone away.
>
> Since commit ba7fdd64b ("xen: cleanup IOREQ server on exit") QEMU now
> destroys IOREQ server for itself as every other device emulator
> is supposed to do. It's now safe to remove this code from soft reset
> path - existing systems with old QEMU should be able to work as
> even if there are IOREQ servers left behind, a new QEMU instance will
> override its ranges anyway.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Paul Durrant
> ---
> xen/arch/x86/domain.c | 2 --
> xen/arch/x86/hvm/hvm.c| 5 -
> xen/include/asm-x86/hvm/hvm.h | 1 -
> 3 files changed, 8 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 2df3123..957f059 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -713,8 +713,6 @@ int arch_domain_soft_reset(struct domain *d)
> if ( !is_hvm_domain(d) )
> return -EINVAL;
>
> -hvm_domain_soft_reset(d);
> -
> spin_lock(>event_lock);
> for ( i = 0; i < d->nr_pirqs ; i++ )
> {
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 029eea3..2b81899 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5045,11 +5045,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
> v->arch.hvm.single_step = !v->arch.hvm.single_step;
> }
>
> -void hvm_domain_soft_reset(struct domain *d)
> -{
> -hvm_destroy_all_ioreq_servers(d);
> -}
> -
> /*
> * Segment caches in VMCB/VMCS are inconsistent about which bits are checked,
> * important, and preserved across vmentry/exit. Cook the values to make
> them
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index b327bd2..4e72d07 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -240,7 +240,6 @@ extern const struct hvm_function_table *start_vmx(void);
> int hvm_domain_initialise(struct domain *d);
> void hvm_domain_relinquish_resources(struct domain *d);
> void hvm_domain_destroy(struct domain *d);
> -void hvm_domain_soft_reset(struct domain *d);
>
> int hvm_vcpu_initialise(struct vcpu *v);
> void hvm_vcpu_destroy(struct vcpu *v);
> --
> 2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/domain: don't destroy IOREQ servers on soft reset
Performing soft reset should not opportunistically kill IOREQ servers
for device emulators that might be currently running for a domain.
Every emulator is supposed to clean up IOREQ servers for itself on exit.
This allows a toolstack to elect whether or not a particular device
model should be restarted.
The original code was introduced in 3235cbfe ("arch-specific hooks for
domain_soft_reset()") likely due to the fact 'default' IOREQ server
existed in Xen at the time and used by QEMU didn't have an API call to
destroy. Since the removal of 'default' IOREQ server from Xen this
reason has gone away.
Since commit ba7fdd64b ("xen: cleanup IOREQ server on exit") QEMU now
destroys IOREQ server for itself as every other device emulator
is supposed to do. It's now safe to remove this code from soft reset
path - existing systems with old QEMU should be able to work as
even if there are IOREQ servers left behind, a new QEMU instance will
override its ranges anyway.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/domain.c | 2 --
xen/arch/x86/hvm/hvm.c| 5 -
xen/include/asm-x86/hvm/hvm.h | 1 -
3 files changed, 8 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 2df3123..957f059 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -713,8 +713,6 @@ int arch_domain_soft_reset(struct domain *d)
if ( !is_hvm_domain(d) )
return -EINVAL;
-hvm_domain_soft_reset(d);
-
spin_lock(>event_lock);
for ( i = 0; i < d->nr_pirqs ; i++ )
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 029eea3..2b81899 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5045,11 +5045,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
v->arch.hvm.single_step = !v->arch.hvm.single_step;
}
-void hvm_domain_soft_reset(struct domain *d)
-{
-hvm_destroy_all_ioreq_servers(d);
-}
-
/*
* Segment caches in VMCB/VMCS are inconsistent about which bits are checked,
* important, and preserved across vmentry/exit. Cook the values to make them
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b327bd2..4e72d07 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -240,7 +240,6 @@ extern const struct hvm_function_table *start_vmx(void);
int hvm_domain_initialise(struct domain *d);
void hvm_domain_relinquish_resources(struct domain *d);
void hvm_domain_destroy(struct domain *d);
-void hvm_domain_soft_reset(struct domain *d);
int hvm_vcpu_initialise(struct vcpu *v);
void hvm_vcpu_destroy(struct vcpu *v);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 140788: regressions - FAIL
flight 140788 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/140788/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-arm64-arm64-xl-credit2 13
Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email
On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote: > We would like to have a common maintainers email address for DornerWorks > maintained code, which currently is the ARINC653 scheduler. This will > enable us to better monitor and respond to the Xen community. This patch > adds a maintainer line with the DornerWorks maintainers email address. > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 77413e0d9e..3cce253931 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -168,6 +168,7 @@ F:xen/common/argo.c > ARINC653 SCHEDULER > M: Josh Whitehead > M: Robert VanVossen > +M: DornerWorks Xen-Devel The correct symbol here is L. L: Mailing list that is relevant to this area > S: Supported > F: xen/common/sched_arinc653.c > F: tools/libxc/xc_arinc653.c > -- > 2.17.1 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xilinx ARM64 Xen testing
On Wed, Aug 28, 2019 at 11:31:58AM -0700, Joseph Komlodi wrote: > Hi all, > > I'm working on ARM64 Xen testing with Xilinx, and I have a few > quick questions to ask. > > How is success vs failure determined with testing using Gitlab CI? > It looks like everything goes into a log, but is there parsing > done afterwards to make the output easier to go through? Do whatever you want in the script: parsing log, testing process exit status. Success or failure is determined by the return value of the script. > > If I have a container on Docker Hub with a QEMU binary in it, could > I use it in the Dockerfile for Xen testing as one of the FROM containers? > Yes. Please submit a patch against xen.git to put the dockerfile under automation directory. And then add your configuration to Gitlab CI's YML files in xen.git. Once your patches are reviewed or acked, someone with proper permissions will first push the docker image to our own repository and then push all your patches to xen.git. Your test cases will be run automatically from then on. > What are the best ways to get a binary for Xen? > Do we download it, or should we build from source? There are two stages in the pipeline. One is build, the other is test. The xen binaries are always built in the build stage of the pipeline. Test cases in test stage will get their binaries from build stage. Wei. > > Thanks! > > Joe ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
Can we take a step back and figure out what we want to do here? AFAICS this function allocates memory for the swiotlb-xen buffer, and that means it must be <= 32-bit addressable to satisfy the DMA API guarantees. That means we generally want to use GFP_DMA32 everywhere that exists, but on systems with odd zones we might want to dip into GFP_DMA. This also means swiotlb-xen doesn't actually do the right thing on x86 at the moment. So shouldn't we just have one common routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32 set, then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set and then try that, else default to GFP_KERNEL? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
Hi Peng,
On 30/08/2019 04:28, Peng Fan wrote:
> From: Peng Fan
>
> arm64 shares some code under arch/arm/xen, including mm.c.
> However ZONE_DMA is removed by commit
> ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> So introduce xen_set_gfp_dma for arm32/arm64 and using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.
>
> Signed-off-by: Peng Fan
> ---
>
> V2:
> Follow suggestion from Stefano,
> introduce static inline void xen_set_gfp_dma(gfp_t *flags) for arm32/arm64,
> and
> for arm64 using __GFP_DMA for the former and __GFP_DMA32 for the latter.
>
> arch/arm/include/asm/xen/page.h | 5 +
> arch/arm/xen/mm.c | 2 +-
> arch/arm64/include/asm/xen/page.h | 5 +
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 31bbc803cecb..d08309c45e6c 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -1 +1,6 @@
> #include
> +
> +static inline void xen_set_gfp_dma(gfp_t *flags)
> +{
> + *flags |= __GFP_DMA;
> +}
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index d33b77e9add3..828f49dc95f9 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -28,7 +28,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0x) {
> - flags |= __GFP_DMA;
> + xen_set_gfp_dma();
The name of the helper is quite misleading, this is specific to swiotlb
yet it gives the impression it can be used everywhere. The helper will
actually set the flags in order to allocate memory below 4GB.
Also, I saw an e-mail suggesting that __GFP_DMA may be used on Arm64. So
a user may think using xen_set_gfp_dma() will set _GFP_DMA and not
_GFP_DMA32.
I know duplication is not great but it feels that duplicating the full
function (or only the allocation part) would be the best. This would
require to introduce a new file mm{32,64}.c in the respective arch
directory.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: add macro for defining variable length array in public headers
Several public headers of the hypervisor contain structures with
variable length arrays. In order to be usable with different compilers
those definitions are depending on the compiler type and the standard
supported by the compiler.
In order to avoid open coding the different variants in each header
add a common macro for that purpose in xen.h.
This at once corrects most of the definitions which miss one case
leading to not defining the array at all.
Signed-off-by: Juergen Gross
---
xen/include/public/arch-x86/hvm/save.h | 8 +---
xen/include/public/arch-x86/pmu.h | 12 ++--
xen/include/public/argo.h | 18 +++---
xen/include/public/physdev.h | 6 +-
xen/include/public/version.h | 7 ++-
xen/include/public/xen.h | 9 +
6 files changed, 18 insertions(+), 42 deletions(-)
diff --git a/xen/include/public/arch-x86/hvm/save.h
b/xen/include/public/arch-x86/hvm/save.h
index 8344aa471f..7cb6952ab8 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -632,13 +632,7 @@ struct hvm_msr {
uint32_t index;
uint32_t _rsvd;
uint64_t val;
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-} msr[];
-#elif defined(__GNUC__)
-} msr[0];
-#else
-} msr[1 /* variable size */];
-#endif
+} msr[__XEN_VARLEN_ARRAY_SIZE];
};
#define CPU_MSR_CODE 20
diff --git a/xen/include/public/arch-x86/pmu.h
b/xen/include/public/arch-x86/pmu.h
index 68ebf121d0..6c3b8cd4b6 100644
--- a/xen/include/public/arch-x86/pmu.h
+++ b/xen/include/public/arch-x86/pmu.h
@@ -35,11 +35,7 @@ struct xen_pmu_amd_ctxt {
uint32_t ctrls;
/* Counter MSRs */
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-uint64_t regs[];
-#elif defined(__GNUC__)
-uint64_t regs[0];
-#endif
+uint64_t regs[__XEN_VARLEN_ARRAY_SIZE];
};
typedef struct xen_pmu_amd_ctxt xen_pmu_amd_ctxt_t;
DEFINE_XEN_GUEST_HANDLE(xen_pmu_amd_ctxt_t);
@@ -71,11 +67,7 @@ struct xen_pmu_intel_ctxt {
uint64_t debugctl;
/* Fixed and architectural counter MSRs */
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-uint64_t regs[];
-#elif defined(__GNUC__)
-uint64_t regs[0];
-#endif
+uint64_t regs[__XEN_VARLEN_ARRAY_SIZE];
};
typedef struct xen_pmu_intel_ctxt xen_pmu_intel_ctxt_t;
DEFINE_XEN_GUEST_HANDLE(xen_pmu_intel_ctxt_t);
diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
index cc603d395d..696b227137 100644
--- a/xen/include/public/argo.h
+++ b/xen/include/public/argo.h
@@ -82,11 +82,7 @@ typedef struct xen_argo_ring
* multiple of the message slot size.
*/
uint8_t reserved[56];
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-uint8_t ring[];
-#elif defined(__GNUC__)
-uint8_t ring[0];
-#endif
+uint8_t ring[__XEN_VARLEN_ARRAY_SIZE];
} xen_argo_ring_t;
typedef struct xen_argo_register_ring
@@ -136,11 +132,7 @@ typedef struct xen_argo_ring_data
{
uint32_t nent;
uint32_t pad;
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-struct xen_argo_ring_data_ent data[];
-#elif defined(__GNUC__)
-struct xen_argo_ring_data_ent data[0];
-#endif
+struct xen_argo_ring_data_ent data[__XEN_VARLEN_ARRAY_SIZE];
} xen_argo_ring_data_t;
struct xen_argo_ring_message_header
@@ -148,11 +140,7 @@ struct xen_argo_ring_message_header
uint32_t len;
struct xen_argo_addr source;
uint32_t message_type;
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-uint8_t data[];
-#elif defined(__GNUC__)
-uint8_t data[0];
-#endif
+uint8_t data[__XEN_VARLEN_ARRAY_SIZE];
};
/*
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index b6faf8350c..c20c4451d3 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -300,11 +300,7 @@ struct physdev_pci_device_add {
* First element ([0]) is PXM domain associated with the device (if
* XEN_PCI_DEV_PXM is set)
*/
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-uint32_t optarr[];
-#elif defined(__GNUC__)
-uint32_t optarr[0];
-#endif
+uint32_t optarr[__XEN_VARLEN_ARRAY_SIZE];
};
typedef struct physdev_pci_device_add physdev_pci_device_add_t;
DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t);
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 7063e8ca55..4cdab53872 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -95,11 +95,8 @@ typedef char xen_commandline_t[1024];
#define XENVER_build_id 10
struct xen_build_id {
uint32_tlen; /* IN: size of buf[]. */
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
-unsigned char buf[];
-#elif defined(__GNUC__)
-unsigned char buf[1]; /* OUT: Variable length buffer with build_id.
*/
-#endif
+unsigned char buf[__XEN_VARLEN_ARRAY_SIZE];
+
[Xen-devel] [PATCH v7 1/6] x86/domain: remove the 'oos_off' flag
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v3:
- Force 'oos_off' to be set for PV guests (to avoid call to
is_hvm_domain() except in ASSERT)
- Dropped Tim's A-b because of the change
v2:
- Move some of the hunks from patch #3
- Also update the definition of shadow_domain_init() in none.c
---
xen/arch/x86/mm/paging.c| 2 +-
xen/arch/x86/mm/shadow/common.c | 7 ---
xen/arch/x86/mm/shadow/none.c | 2 +-
xen/common/domain.c | 16
xen/include/asm-x86/domain.h| 1 -
xen/include/asm-x86/shadow.h| 2 +-
6 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 097a27f608..69aa228e46 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -653,7 +653,7 @@ int paging_domain_init(struct domain *d)
if ( hap_enabled(d) )
hap_domain_init(d);
else
-rc = shadow_domain_init(d, d->options);
+rc = shadow_domain_init(d);
return rc;
}
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index c0d4a27287..9463794059 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -46,7 +46,7 @@ static void sh_clean_dirty_bitmap(struct domain *);
/* Set up the shadow-specific parts of a domain struct at start of day.
* Called for every domain from arch_domain_create() */
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags)
+int shadow_domain_init(struct domain *d)
{
static const struct log_dirty_ops sh_ops = {
.enable = sh_enable_log_dirty,
@@ -62,7 +62,6 @@ int shadow_domain_init(struct domain *d, unsigned int
domcr_flags)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
d->arch.paging.shadow.oos_active = 0;
-d->arch.paging.shadow.oos_off = domcr_flags & XEN_DOMCTL_CDF_oos_off;
#endif
d->arch.paging.shadow.pagetable_dying_op = 0;
@@ -2528,11 +2527,13 @@ static void sh_update_paging_modes(struct vcpu *v)
#if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
/* We need to check that all the vcpus have paging enabled to
* unsync PTs. */
-if ( is_hvm_domain(d) && !d->arch.paging.shadow.oos_off )
+if ( !(d->options & XEN_DOMCTL_CDF_oos_off) )
{
int pe = 1;
struct vcpu *vptr;
+ASSERT(is_hvm_domain(d));
+
for_each_vcpu(d, vptr)
{
if ( !hvm_paging_enabled(vptr) )
diff --git a/xen/arch/x86/mm/shadow/none.c b/xen/arch/x86/mm/shadow/none.c
index a70888bd98..2fddf4274c 100644
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -18,7 +18,7 @@ static void _clean_dirty_bitmap(struct domain *d)
ASSERT(is_pv_domain(d));
}
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags)
+int shadow_domain_init(struct domain *d)
{
static const struct log_dirty_ops sh_none_ops = {
.enable = _enable_log_dirty,
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e9d2c613e0..eb13807af9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -313,11 +313,19 @@ static int sanitise_domain_config(struct
xen_domctl_createdomain *config)
return -EINVAL;
}
-if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) &&
- (config->flags & XEN_DOMCTL_CDF_hap) )
+if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) )
{
-dprintk(XENLOG_INFO, "HAP requested for non-HVM guest\n");
-return -EINVAL;
+if ( config->flags & XEN_DOMCTL_CDF_hap )
+{
+dprintk(XENLOG_INFO, "HAP requested for non-HVM guest\n");
+return -EINVAL;
+}
+
+/*
+ * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear
+ * for HVM guests.
+ */
+config->flags |= XEN_DOMCTL_CDF_oos_off;
}
return arch_sanitise_domain_config(config);
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 9f3afd12bc..7cebfa4fb9 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -115,7 +115,6 @@ struct shadow_domain {
/* OOS */
bool_t oos_active;
-bool_t oos_off;
/* Has this domain ever used HVMOP_pagetable_dying? */
bool_t pagetable_dying_op;
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index f29f0f652b..8ebb89c027 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -49,7 +49,7 @@
/* Set up the shadow-specific parts of a domain struct at start of day.
* Called from paging_domain_init(). */
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags);
+int shadow_domain_init(struct domain *d);
/* Setup the shadow-specific parts of a vcpu struct. It is called by
* paging_vcpu_init() in paging.c */
--
[Xen-devel] [PATCH v7 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed to just being ignored), so define
'iommu_hap_pt_share' to be true for ARM then then gate parsing the
command line option on '#ifndef iommu_hap_pt_share'.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Volodymyr Babchuk
Cc: "Roger Pau Monné"
Previously part of
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Re-work the ARM handling of 'sharept' as suggested by Jan
- Make sure that need_iommu_pt_sync() always evaluates its argument
---
xen/drivers/passthrough/iommu.c | 8 +++-
xen/include/asm-arm/iommu.h | 3 ---
xen/include/asm-x86/iommu.h | 4
xen/include/xen/iommu.h | 19 ++-
xen/include/xen/sched.h | 6 --
5 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4f71db95ea..6506a28d4f 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
* default until we find a good solution to resolve it.
*/
bool_t __read_mostly iommu_intpost;
-bool_t __read_mostly iommu_hap_pt_share = 1;
+
+#ifndef CONFIG_ARM
+bool __read_mostly iommu_hap_pt_share = true;
+#endif
+
bool_t __read_mostly iommu_debug;
bool_t __read_mostly amd_iommu_perdev_intremap = 1;
@@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
iommu_hwdom_passthrough = val;
else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
iommu_hwdom_strict = val;
+#ifndef iommu_hap_pt_share
else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
iommu_hap_pt_share = val;
+#endif
else
rc = -EINVAL;
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 1577e83d2b..77a94b29eb 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -20,9 +20,6 @@ struct arch_iommu
void *priv;
};
-/* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) is_iommu_enabled(d)
-
const struct iommu_ops *iommu_get_ops(void);
void 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 f52d6f75ef..9ef9d38934 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -88,10 +88,6 @@ struct iommu_init_ops {
extern const struct iommu_init_ops *iommu_init_ops;
-/* Are we using the domain P2M table as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) \
-(hap_enabled(d) && is_iommu_enabled(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);
int iommu_setup_hpet_msi(struct msi_desc *);
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 4b6871936c..e785aacbfb 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -55,7 +55,13 @@ static inline bool_t dfn_eq(dfn_t x, dfn_t y)
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose, iommu_igfx;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
-extern bool_t iommu_hap_pt_share;
+
+#ifdef CONFIG_ARM
+#define iommu_hap_pt_share true
+#else
+extern bool iommu_hap_pt_share;
+#endif
+
extern bool_t iommu_debug;
extern bool_t amd_iommu_perdev_intremap;
@@ -268,6 +274,17 @@ struct domain_iommu {
#define iommu_set_feature(d, f) set_bit(f, dom_iommu(d)->features)
#define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
+/* Are we using the domain P2M table as its IOMMU pagetable? */
+#define iommu_use_hap_pt(d) \
+(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
+
+/* Does the IOMMU pagetable need to be kept synchronized with the P2M */
+#ifdef CONFIG_HAS_PASSTHROUGH
+#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
+#else
+#define need_iommu_pt_sync(d) ({ (void)d; false; })
+#endif
+
int __must_check iommu_suspend(void);
void iommu_resume(void);
void iommu_crash_shutdown(void);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 3f8ad56655..0b5c106a37 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -965,12 +965,6 @@ static inline bool is_hwdom_pinned_vcpu(const struct vcpu
*v)
cpumask_weight(v->cpu_hard_affinity) == 1);
}
-#ifdef CONFIG_HAS_PASSTHROUGH
-#define need_iommu_pt_sync(d)
[Xen-devel] [PATCH v7 6/6] introduce a 'passthrough' configuration option to xl.cfg...
...and hence the ability to disable IOMMU mappings, and control EPT sharing. This patch introduces a new 'libxl_passthrough' enumeration into libxl_domain_create_info. The value will be set by xl either when it parses a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough hardware specified for the domain. If the value of the passthrough configuration option is 'disabled' then the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain flags, thus allowing the toolstack to control whether the domain gets IOMMU mappings or not (where previously they were globally set). If the value of the passthrough configuration option is 'sync_pt' then a new 'iommu_opts' field in xen_domctl_createdomain will be set with the value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default set in iommu_hap_pt_share, thus allowing the toolstack to control whether EPT sharing is used for the domain. NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will only be set to zero if passthrough is 'disabled'. It is not safe to set the overhead to zero in the 'share_pt' case because the toolstack has no means of knowing whether the hardware actually supports IOMMU page table sharing. Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich --- Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Anthony PERARD Cc: Christian Lindig Cc: David Scott Cc: Volodymyr Babchuk Cc: "Roger Pau Monné" Previously part of series https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html v7: - Added missing breaks - Added missing ocaml binding changes v6: - Remove the libxl_physinfo() call since it's usefulness is limited to x86 v5: - Expand xen_domctl_createdomain flags field and hence bump interface version - Fix spelling mistakes in context line --- docs/man/xl.cfg.5.pod.in| 52 +++ tools/libxl/libxl.h | 5 + tools/libxl/libxl_create.c | 9 ++ tools/libxl/libxl_types.idl | 7 ++ tools/ocaml/libs/xc/xenctrl.ml | 4 + tools/ocaml/libs/xc/xenctrl.mli | 4 + tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- tools/xl/xl_parse.c | 140 ++-- xen/arch/arm/domain.c | 10 +- xen/arch/x86/domain.c | 2 +- xen/common/domain.c | 7 ++ xen/common/domctl.c | 13 --- xen/drivers/passthrough/iommu.c | 13 ++- xen/include/public/domctl.h | 6 +- xen/include/xen/iommu.h | 19 ++-- 15 files changed, 229 insertions(+), 77 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index c99d40307e..fd35685e9e 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -605,6 +605,58 @@ option should only be used with a trusted device tree. Note that the partial device tree should avoid using the phandle 65000 which is reserved by the toolstack. +=item B + +Specify whether IOMMU mappings are enabled for the domain and hence whether +it will be enabled for passthrough hardware. Valid values for this option +are: + +=over 4 + +=item B + +IOMMU mappings are disabled for the domain and so hardware may not be +passed through. + +This option is the default if no passthrough hardware is specified +in the domain's configuration. + +=item B + +This option means that IOMMU mappings will be synchronized with the +domain's P2M table as follows: + +For a PV domain, all writable pages assigned to the domain are identity +mapped by MFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware for DMA using MFN values +(i.e. host/machine frame numbers) looked up in its P2M. + +For an HVM domain, all non-foreign RAM pages present in its P2M will be +mapped by GFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware using GFN values (i.e. guest +physical frame numbers) without any further translation. + +This option is the default if the domain is PV and passthrough hardware +is specified in the configuration. + +This option is not available on Arm. + +=item B + +This option is unavailable for a PV domain. For an HVM domain, this option +means that the IOMMU will be programmed to directly reference the domain's +P2M table as its page table. From the point of view of a device driver +running in the domain this is functionally equivalent to B but +places less load on the hypervisor and so should generally be selected in +preference. However, the availability of this option is hardware specific +and thus, if it is specified for a domain running on hardware that does +not allow it (e.g. AMD), B will be used instead. + +This option is the default if the domain is HVM and passthrough hardware +is specified in the configuration. + +=back + =back
[Xen-devel] [PATCH v7 3/6] use is_iommu_enabled() where appropriate...
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be translated into tests of the per-domain flag. Some of the other tests of
purely the global iommu_enabled flag can also be translated into tests of
the per-domain flag.
NOTE: The comment in iommu_share_p2m_table() is also fixed; need_iommu()
disappeared some time ago. Also, whilst the style of the 'if' in
flask_iommu_resource_use_perm() is fixed, I have not translated any
instances of u32 into uint32_t to keep consistency. IMO such a
translation would be better done globally for the source module in
a separate patch.
The change to the definition of iommu_call() is to keep the PV shim
build happy. Without this change it will fail to compile with errors
of the form:
iommu.c:361:32: error: unused variable ‘hd’ [-Werror=unused-variable]
const struct domain_iommu *hd = dom_iommu(d);
^~
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
Reviewed-by: Kevin Tian
Acked-by: Daniel De Graaf
Reviewed-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Volodymyr Babchuk
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Jun Nakajima
Cc: George Dunlap
Cc: Suravee Suthikulpanit
Previously part of series
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Fix iommu_call() rather than messing with the initializtion of 'hd'
- Constify domain pointer passed to flask_iommu_resource_use_perm()
v5:
- Fix logic in ARM p2m_init()
- Make iommu_do_domctl() return -EOPNOTSUPP rather than -ENOSYS if the
IOMMU is not enabled
- Fix test in pci_enable_acs()
- Fix test in flask_iommu_resource_use_perm()
---
xen/arch/arm/p2m.c| 2 +-
xen/arch/x86/dom0_build.c | 2 +-
xen/arch/x86/domctl.c | 4 +--
xen/arch/x86/hvm/hvm.c| 6 ++---
xen/arch/x86/hvm/vioapic.c| 2 +-
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
xen/arch/x86/hvm/vmx/vmx.c| 2 +-
xen/arch/x86/mm/p2m-ept.c | 4 +--
xen/drivers/passthrough/amd/iommu_guest.c | 2 +-
xen/drivers/passthrough/device_tree.c | 4 +--
xen/drivers/passthrough/io.c | 8 +++---
xen/drivers/passthrough/iommu.c | 31 ++-
xen/drivers/passthrough/pci.c | 16 ++--
xen/drivers/passthrough/vtd/iommu.c | 2 +-
xen/drivers/passthrough/vtd/x86/hvm.c | 2 +-
xen/drivers/passthrough/x86/iommu.c | 2 +-
xen/include/asm-x86/iommu.h | 13 --
xen/xsm/flask/hooks.c | 18 ++---
18 files changed, 64 insertions(+), 58 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e28ea1c85a..7f1442932a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1531,7 +1531,7 @@ int p2m_init(struct domain *d)
* shared with the CPU, Xen has to make sure that the PT changes have
* reached the memory
*/
-p2m->clean_pte = iommu_enabled &&
+p2m->clean_pte = is_iommu_enabled(d) &&
!iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
rc = p2m_alloc_table(d);
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c69570920c..d381784edd 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -356,7 +356,7 @@ unsigned long __init dom0_compute_nr_pages(
avail -= d->max_vcpus - 1;
/* Reserve memory for iommu_dom0_init() (rough estimate). */
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
{
unsigned int s;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1e98fc8009..c4cb00bcf0 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -703,7 +703,7 @@ long arch_do_domctl(
break;
ret = -ESRCH;
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
{
pcidevs_lock();
ret = pt_irq_create_bind(d, bind);
@@ -732,7 +732,7 @@ long arch_do_domctl(
if ( ret )
break;
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
{
pcidevs_lock();
ret = pt_irq_destroy_bind(d, bind);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 029eea3b85..172c860acc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -465,7 +465,7 @@ void hvm_migrate_timers(struct vcpu *v)
void hvm_migrate_pirq(struct hvm_pirq_dpci *pirq_dpci, const struct vcpu *v)
{
-ASSERT(iommu_enabled &&
+ASSERT(is_iommu_enabled(v->domain) &&
(is_hardware_domain(v->domain) || hvm_domain_irq(v->domain)->dpci));
if ( (pirq_dpci->flags &
[Xen-devel] [PATCH v7 0/6] add per-domain IOMMU control
These are revisions of the remaining uncommitted patches from my previous series: https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01737.html Paul Durrant (6): x86/domain: remove the 'oos_off' flag domain: introduce XEN_DOMCTL_CDF_iommu flag use is_iommu_enabled() where appropriate... remove late (on-demand) construction of IOMMU page tables iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros introduce a 'passthrough' configuration option to xl.cfg... docs/man/xl.cfg.5.pod.in | 52 +++ tools/libxl/libxl.h | 5 + tools/libxl/libxl_create.c| 9 ++ tools/libxl/libxl_mem.c | 6 +- tools/libxl/libxl_types.idl | 8 + tools/libxl/libxl_utils.c | 15 ++ tools/libxl/libxl_utils.h | 1 + tools/ocaml/libs/xc/xenctrl.ml| 12 +- tools/ocaml/libs/xc/xenctrl.mli | 12 +- tools/ocaml/libs/xc/xenctrl_stubs.c | 15 +- tools/xl/xl_parse.c | 145 +++-- xen/arch/arm/domain.c | 10 +- xen/arch/arm/p2m.c| 4 +- xen/arch/arm/setup.c | 3 + xen/arch/x86/dom0_build.c | 4 +- xen/arch/x86/domain.c | 2 +- xen/arch/x86/domctl.c | 4 +- xen/arch/x86/hvm/hvm.c| 6 +- xen/arch/x86/hvm/mtrr.c | 5 +- xen/arch/x86/hvm/vioapic.c| 2 +- xen/arch/x86/hvm/vmx/vmcs.c | 2 +- xen/arch/x86/hvm/vmx/vmx.c| 2 +- xen/arch/x86/mm/mem_sharing.c | 2 +- xen/arch/x86/mm/p2m-ept.c | 4 +- xen/arch/x86/mm/p2m.c | 4 +- xen/arch/x86/mm/paging.c | 4 +- xen/arch/x86/mm/shadow/common.c | 7 +- xen/arch/x86/mm/shadow/none.c | 2 +- xen/arch/x86/setup.c | 3 + xen/arch/x86/x86_64/mm.c | 2 +- xen/common/domain.c | 30 +++- xen/common/memory.c | 4 +- xen/common/vm_event.c | 2 +- xen/drivers/passthrough/amd/iommu_guest.c | 2 +- xen/drivers/passthrough/device_tree.c | 18 +-- xen/drivers/passthrough/io.c | 8 +- xen/drivers/passthrough/iommu.c | 180 +++--- xen/drivers/passthrough/pci.c | 28 +--- xen/drivers/passthrough/vtd/iommu.c | 12 +- xen/drivers/passthrough/vtd/x86/hvm.c | 2 +- xen/drivers/passthrough/x86/iommu.c | 99 +--- xen/include/asm-arm/iommu.h | 3 - xen/include/asm-x86/domain.h | 1 - xen/include/asm-x86/iommu.h | 17 +- xen/include/asm-x86/shadow.h | 2 +- xen/include/public/domctl.h | 10 +- xen/include/xen/iommu.h | 48 +++--- xen/include/xen/sched.h | 13 +- xen/xsm/flask/hooks.c | 18 +-- 49 files changed, 437 insertions(+), 412 deletions(-) --- Cc: Andrew Cooper Cc: Anthony PERARD Cc: Christian Lindig Cc: David Scott Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Jun Nakajima Cc: Konrad Rzeszutek Wilk Cc: Petre Pircalabu Cc: "Roger Pau Monné" Cc: Stefano Stabellini Cc: Suravee Suthikulpanit Cc: Tamas K Lengyel Cc: Tim Deegan Cc: Volodymyr Babchuk Cc: Wei Liu -- 2.20.1.2.gb21ebb671 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 4/6] remove late (on-demand) construction of IOMMU page tables
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
destruction.
This allows the has_iommu_pt() helper and iommu_status enumeration to be
removed. Calls to has_iommu_pt() are simply replaced by calls to
is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can
also be replaced by calls to iommu_use_hap_pt().
The arch_iommu_populate_page_table() and iommu_construct() functions become
redundant, as does the 'strict mode' dom0 page_list mapping code in
iommu_hwdom_init(), and iommu_teardown() can be made static is its only
remaining caller, iommu_domain_destroy(), is within the same source
module.
All in all, about 220 lines of code are removed from the hypervisor.
NOTE: This patch will cause a small amount of extra resource to be used
to accommodate IOMMU page tables that may never be used, since the
per-domain IOMMU-enable flag is currently set to the value of the
global iommu_enable flag. A subsequent patch will add an option to
the toolstack to allow it to be turned off if there is no intention
to assign passthrough hardware to the domain.
To account for the extra resource, 'iommu_memkb' has been added to
domain_build_info. This patch sets it unconditionally to a value
calculated based on the domain's maximum memory but, when the
toolstack option mentioned above is added, it can be set to zero
if the per-domain IOMMU-enable flag is turned off.
Signed-off-by: Paul Durrant
Reviewed-by: Alexandru Isaila
Acked-by: Razvan Cojocaru
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Volodymyr Babchuk
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Tamas K Lengyel
Cc: George Dunlap
Cc: Petre Pircalabu
Previously part of series
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Add toolstack memory reservation for IOMMU page tables... Re-use of
shadow calculation didn't seem appropriate so a new helper function is
added
v5:
- Minor style fixes
---
tools/libxl/libxl_mem.c | 6 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_utils.c | 15 +++
tools/libxl/libxl_utils.h | 1 +
tools/xl/xl_parse.c | 7 +-
xen/arch/arm/p2m.c| 2 +-
xen/arch/x86/dom0_build.c | 2 +-
xen/arch/x86/hvm/mtrr.c | 5 +-
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/arch/x86/mm/p2m.c | 4 +-
xen/arch/x86/mm/paging.c | 2 +-
xen/arch/x86/x86_64/mm.c | 2 +-
xen/common/memory.c | 4 +-
xen/common/vm_event.c | 2 +-
xen/drivers/passthrough/device_tree.c | 11 ---
xen/drivers/passthrough/iommu.c | 134 ++
xen/drivers/passthrough/pci.c | 12 ---
xen/drivers/passthrough/vtd/iommu.c | 10 +-
xen/drivers/passthrough/x86/iommu.c | 97 ---
xen/include/asm-arm/iommu.h | 2 +-
xen/include/asm-x86/iommu.h | 2 +-
xen/include/xen/iommu.h | 16 ---
xen/include/xen/sched.h | 2 -
23 files changed, 70 insertions(+), 271 deletions(-)
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index 448a2af8fd..fd6f33312e 100644
--- a/tools/libxl/libxl_mem.c
+++ b/tools/libxl/libxl_mem.c
@@ -461,15 +461,17 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
if (rc) goto out;
*need_memkb = b_info->target_memkb;
+*need_memkb += b_info->shadow_memkb + b_info->iommu_memkb;
+
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_PVH:
case LIBXL_DOMAIN_TYPE_HVM:
-*need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
+*need_memkb += LIBXL_HVM_EXTRA_MEMORY;
if (libxl_defbool_val(b_info->device_model_stubdomain))
*need_memkb += 32 * 1024;
break;
case LIBXL_DOMAIN_TYPE_PV:
-*need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
+*need_memkb += LIBXL_PV_EXTRA_MEMORY;
break;
default:
rc = ERROR_INVAL;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b61399ce36..d94b7453cb 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -486,6 +486,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("target_memkb",MemKB),
("video_memkb", MemKB),
("shadow_memkb",MemKB),
+("iommu_memkb", MemKB),
("rtc_timeoffset", uint32),
("exec_ssidref",uint32),
("exec_ssid_label", string),
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index
[Xen-devel] [PATCH v7 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject
the flag if !iommu_enabled.
A new helper function, is_iommu_enabled(), is added to test the flag and
iommu_domain_init() will return immediately if !is_iommu_enabled(). This is
slightly different to the previous behaviour based on !iommu_enabled where
the call to arch_iommu_domain_init() was made regardless, however it appears
that this call was only necessary to initialize the dt_devices list for ARM
such that iommu_release_dt_devices() can be called unconditionally by
domain_relinquish_resources(). Adding a simple check of is_iommu_enabled()
into iommu_release_dt_devices() keeps this unconditional call working.
No functional change should be observed with this patch applied.
Subsequent patches will allow the toolstack to control whether use of the
IOMMU is enabled for a domain.
NOTE: The introduction of the is_iommu_enabled() helper function might
seem excessive but its use is expected to increase with subsequent
patches. Also, having iommu_domain_init() bail before calling
arch_iommu_domain_init() is not strictly necessary, but I think the
consequent addition of the call to is_iommu_enabled() in
iommu_release_dt_devices() makes the code clearer.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
---
Cc: Christian Lindig
Cc: David Scott
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Volodymyr Babchuk
Previously part of series
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Add a check to verify that the toolstack has not set XEN_DOMCTL_CDF_iommu
- Add missing ocaml binding changes
v6:
- Remove the toolstack parts as there's no nice method of testing whether
the IOMMU is enabled in an architecture-neutral way
v5:
- Move is_iommu_enabled() check into iommu_domain_init()
- Reject XEN_DOMCTL_CDF_iommu in sanitise_domain_config() if !iommu_enabled
- Use evaluate_nospec() in defintion of is_iommu_enabled()
---
tools/ocaml/libs/xc/xenctrl.ml| 8 +++-
tools/ocaml/libs/xc/xenctrl.mli | 8 +++-
xen/arch/arm/setup.c | 3 +++
xen/arch/x86/setup.c | 3 +++
xen/common/domain.c | 9 -
xen/common/domctl.c | 13 +
xen/drivers/passthrough/device_tree.c | 3 +++
xen/drivers/passthrough/iommu.c | 6 +++---
xen/include/public/domctl.h | 4
xen/include/xen/sched.h | 5 +
10 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 35958b94d5..bdf3f2e395 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -56,7 +56,13 @@ type arch_domainconfig =
| ARM of xen_arm_arch_domainconfig
| X86 of xen_x86_arch_domainconfig
-type domain_create_flag = CDF_HVM | CDF_HAP
+type domain_create_flag =
+ | CDF_HVM
+ | CDF_HAP
+ | CDF_S3_INTEGRITY
+ | CDF_OOS_OFF
+ | CDF_XS_DOMAIN
+ | CDF_IOMMU
type domctl_create_config =
{
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 6c4268d453..fc40885671 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -49,7 +49,13 @@ type arch_domainconfig =
| ARM of xen_arm_arch_domainconfig
| X86 of xen_x86_arch_domainconfig
-type domain_create_flag = CDF_HVM | CDF_HAP
+type domain_create_flag =
+ | CDF_HVM
+ | CDF_HAP
+ | CDF_S3_INTEGRITY
+ | CDF_OOS_OFF
+ | CDF_XS_DOMAIN
+ | CDF_IOMMU
type domctl_create_config = {
ssidref: int32;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index fa6c110b11..dc2640f8b9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -961,6 +961,9 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.arch.tee_type = tee_get_type();
dom0_cfg.max_vcpus = dom0_max_vcpus();
+if ( iommu_enabled )
+dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
dom0 = domain_create(0, _cfg, true);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0\n");
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d0b35b0ce2..fa226a2bab 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1733,6 +1733,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
}
dom0_cfg.max_vcpus = dom0_max_vcpus();
+if ( iommu_enabled )
+dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
/* Create initial domain 0. */
dom0 = domain_create(get_initial_domain_id(), _cfg, !pv_shim);
Re: [Xen-devel] [Xen-unstable] boot crash while loading AMD microcode due to commit "microcode/amd: fix memory leak"
On Fri, Aug 30, 2019 at 09:49:04AM +0200, Jan Beulich wrote: >On 30.08.2019 04:09, Chao Gao wrote: >> On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote: >>> L.S., >>> >>> While testing xen-unstable, my AMD system crashes during early boot while >>> loading microcode with an "Early fatal page fault". >>> Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: >>> fix memory leak" fixes the boot issue. >> >> Sorry for this inconvenience. >> >> Could you apply the patch attached and try it again? > >I'm inclined to take this fix even without waiting for Sander's >feedback (and simply implying your S-o-b). Ack. Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-unstable] boot crash while loading AMD microcode due to commit "microcode/amd: fix memory leak"
On 30.08.2019 04:09, Chao Gao wrote: > On Fri, Aug 30, 2019 at 01:04:54AM +0200, Sander Eikelenboom wrote: >> L.S., >> >> While testing xen-unstable, my AMD system crashes during early boot while >> loading microcode with an "Early fatal page fault". >> Reverting commit de45e3ff37bb1602796054afabfa626ea5661c45 "microcode/amd: >> fix memory leak" fixes the boot issue. > > Sorry for this inconvenience. > > Could you apply the patch attached and try it again? I'm inclined to take this fix even without waiting for Sander's feedback (and simply implying your S-o-b). Andrew - what do you think? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mmcfg: add "force" option for MCFG
On 29.08.2019 21:25, Igor Druzhinin wrote: > On 29/08/2019 09:00, Roger Pau Monné wrote: >>> >>> I think we need to have this option to at least have a way to workaround >>> problem (1). Problem (2) could be solved in Dom0 kernel by invoking >>> xen_mcfg_late() earlier but before the first PCI bus enumertaion which >>> currently happens somwhere during ACPI scan I think. >>> >>> The question is what the defult value for this option should be? >> >> Have you tested this against a variety of hardware? > Not yet, I presume it's possible in theory that there is such a box in > the wild that will misbehave if we attempt to access MCFG earlier it'd > be discovered through ACPI. Other than that I don't see a reason why it > would cause any problem. But you're right - we need to run some tests > with this option set to true on our fleet before deciding. > >> Have you found any box that has a wrong MMCFG area in the MCFG static >> table? (ie: one that doesn't match the motherboard resource >> reservation in the dynamic ACPI tables?) > > I think it's possible that size of the table reported from ACPI is > smaller which would be a problem if we access out-of-bounds preliminary > - hence the ability to fall back. But I'm not aware of any hardware like > that. The reason why Linux had put these two checks (E820 and ACPI) in place (and we cloned them) was that in the old days (at least until around the first x86-64 systems appearing) there were many such systems (iirc more than there were well behaved ones). The bad situation with BIOSes was also why the various chipset probing methods had been introduced. Anyway - the main risk with using MCFG without knowing the range is suitably reserved is that other things may live in that range (e.g. BARs may have been allocated there). Therefore I don't think we can reasonably default this option to "true", irrespective whether perhaps _all_ systems in your testing fleet are well behaved in this regard. >>> --- a/xen/arch/x86/e820.c >>> +++ b/xen/arch/x86/e820.c >>> @@ -37,6 +37,26 @@ struct e820map e820; >>> struct e820map __initdata e820_raw; >>> >>> /* >>> + * This function checks if any part of the range is mapped >>> + * with type. >>> + */ >>> +int __init e820_any_mapped(u64 start, u64 end, unsigned type) >> >> Please use uint64_t and unsigned int. Also it looks like this >> function wants to return a bool instead of an int. >> > > The problem here is that I want this function be similar to the one > below (e820_all_mapped) which is copied from Linux as well as the rest > of the file. At the same time I don't want to introduce code churn > fixing unrelated style issues. Perhaps it's better to keep style of this > function as is? Or do you think it's still better to unify the style > across both of them (perhaps in a separate commit)? Since we're trying to gradually switch to uint_t, I think new code should by default use the intended types. Exceptions would be imports of entire files from Linux. If you followed up your change with one converting the other function(s) to the intended types as well, that'd be much appreciated, but is imo not a requirement. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode
On 30.08.2019 08:33, Chao Gao wrote:
> On Thu, Aug 29, 2019 at 02:22:47PM +0200, Jan Beulich wrote:
>> On 19.08.2019 03:25, Chao Gao wrote:
>>> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
>>> return ret;
>>> }
>>>
>>> +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int
>>> cpu)
>>> +{
>>> +/* The first thread of a core is to load an update. Don't block it. */
>>> +if ( cpu == cpumask_first(per_cpu(cpu_sibling_mask, cpu)) ||
>>> + loading_state != LOADING_CALLIN )
>>> +return 0;
>>> +
>>> +cpumask_set_cpu(cpu, _callin_map);
>>> +
>>> +while ( loading_state != LOADING_EXIT )
>>> +cpu_relax();
>>> +
>>> +return 0;
>>> +}
>>
>> By returning 0 you tell do_nmi() to continue processing the NMI.
>> Since you can't tell whether a non-IPI NMI has surfaced at about
>> the same time this is generally the right thing imo, but how do
>> you prevent unknown_nmi_error() from getting entered when do_nmi()
>> ends up setting handle_unknown to true? (The question is mostly
>> rhetorical, but there's a disconnect between do_nmi() checking
>> "cpu == 0" and the control thread running on
>> cpumask_first(_online_map), i.e. you introduce a well hidden
>> dependency on CPU 0 never going offline. IOW my request is to at
>> least make this less well hidden, such that it can be noticed if
>> and when someone endeavors to remove said limitation.)
>
> Seems the issue is that we couldn't send IPI NMI to BSP, otherwise
> unknown_nmi_error() would be trigger. And loading ucode after
> rendezvousing all CPUs in NMI handler expects all CPUs to receive IPI
> NMI. So this approach always has such issue.
Not really, I don't think: If both sides agreed (explicitly!) on which
CPU leads this effort, then it would be clear that the one CPU
handling NMIs coming from the platform should not be sent an NMI, and
hence it should be this one to lead the effort. FAOD - my remark really
was because of the new hidden(!) dependency you introduce on CPU 0
always being this "special" CPU. I don't expect you to change the code,
but I'd like you to make the currently hidden dependency explicit.
> Considering self_nmi is called at another place, could we provide a
> way to temporarily suppress or (force) ignore unknown nmi error?
I'm afraid any attempt at doing so will leave room for missing an
actual (platform) NMI.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 10/15] microcode: split out apply_microcode() from cpu_request_microcode()
On 30.08.2019 05:22, Chao Gao wrote: > On Thu, Aug 29, 2019 at 12:06:28PM +0200, Jan Beulich wrote: >> On 22.08.2019 15:59, Roger Pau Monné wrote: >>> Seeing how this works I'm not sure what's the best option here. As >>> updating will be attempted on other CPUs, I'm not sure if it's OK to >>> return an error if the update succeed on some CPUs but failed on >>> others. >> >> The overall result of a partially successful update should be an >> error - mismatched ucode may, after all, be more of a problem >> than outdated ucode. > > Will only take care -EIO case. If systems have differing ucodes on > cores, partially update is expected when we try to correct the system > with an ucode equal to the newest ucode rev already on cores. But an update attempt with what's already loaded in the CPU should yield "success", hence a "partial" update like what you describe should not be considered "partial" in the first place. Iirc an update attempt when same (or newer?) ucode is already loaded on all cores yields "success" too, doesn't it? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] xen: Switch parameter in get_page_from_gfn to use typesafe gfn
On 29.08.2019 19:36, Julien Grall wrote:
> On 29/08/2019 17:41, Jan Beulich wrote:
>> On 19.08.2019 16:26, Julien Grall wrote:
>>> No functional change intended.
>>>
>>> Only reasonable clean-ups are done in this patch. The rest will use _gfn
>>> for the time being.
>>>
>>> The code in get_page_from_gfn is slightly reworked to also handle a bad
>>> behavior because it is not safe to use mfn_to_page(...) because
>>> mfn_valid(...) succeeds.
>>
>> I guess the 2nd "because" is meant to be "before", but even then I
>> don't think I can easily agree: mfn_to_page() is just calculations,
>> no dereference.
>
> Regardless the s/because/before/. Do you disagree on the wording or the
> change? If the former, I just paraphrased what Andrew wrote in the
> previous version:
>
> "This unfortunately propagates some bad behaviour, because it is not
> safe to use mfn_to_page(mfn); before mfn_valid(mfn) succeeds. (In
> practice it works because mfn_to_page() is just pointer arithmetic.)"
>
> This is x86 code, so please agree with Andrew on the approach/wording.
Andrew - I don't see much point altering the ordering in a mechanical
patch like this one, when there are (presumably) dozens of other places
doing the same. I agree it's a grey area, but I don't think doing the
pointer arithmetic up front can really be called UB in the sense that
it may cause the compiler to mis-optimize things. This is in particular
because we don't declare frame_table[]'s bounds anywhere, so the
compiler has to view this as an array extending all the way up to the
upper address space end.
If we really were concerned, we should go through and change all such
instances.
>>> --- a/xen/arch/x86/hvm/domain.c
>>> +++ b/xen/arch/x86/hvm/domain.c
>>> @@ -296,8 +296,10 @@ int arch_set_info_hvm_guest(struct vcpu *v, const
>>> vcpu_hvm_context_t *ctx)
>>> if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
>>> {
>>> /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
>>> -struct page_info *page = get_page_from_gfn(v->domain,
>>> - v->arch.hvm.guest_cr[3] >> PAGE_SHIFT,
>>> +struct page_info *page;
>>> +
>>> +page = get_page_from_gfn(v->domain,
>>> + gaddr_to_gfn(v->arch.hvm.guest_cr[3]),
>>>NULL, P2M_ALLOC);
>>
>> Iirc I've said so before: I consider use of gaddr_to_gfn() here more
>> misleading than a plain shift by PAGE_SHIFT. Neither is really correct,
>> but in no event does CR3 as a whole hold an address. (Same elsewhere
>> then, and sadly in quite a few places.)
>
> Well, this code has not changed since v3 and you acked it... I only
> dropped the ack here because the previous version was sent 9 months ago.
> I also can't see such comment made on any version of this series.
Well, it may not have been this patch, but I clearly recall pointing
this aspect out before; I think it was even more than once.
> Anyway, I am more than happy to switch to _gfn((v->arch.hvm.guest_cr[3]
> >> PAGE_SHIFT)) if you prefer it.
Personally I'd much prefer introducing (and then using)
#define gcr3_to_gfn(cr3) gaddr_to_gfn((cr3) & X86_CR3_ADDR_MASK)
>>> --- a/xen/common/event_fifo.c
>>> +++ b/xen/common/event_fifo.c
>>> @@ -361,7 +361,7 @@ static const struct evtchn_port_ops
>>> evtchn_port_ops_fifo =
>>> .print_state = evtchn_fifo_print_state,
>>> };
>>>
>>> -static int map_guest_page(struct domain *d, uint64_t gfn, void **virt)
>>> +static int map_guest_page(struct domain *d, gfn_t gfn, void **virt)
>>> {
>>> struct page_info *p;
>>>
>>> @@ -422,7 +422,7 @@ static int setup_control_block(struct vcpu *v)
>>> return 0;
>>> }
>>>
>>> -static int map_control_block(struct vcpu *v, uint64_t gfn, uint32_t offset)
>>> +static int map_control_block(struct vcpu *v, gfn_t gfn, uint32_t offset)
>>> {
>>> void *virt;
>>> unsigned int i;
>>
>> Just as a remark (no action expected) - this makes a truncation issue
>> pretty apparent: On 32-bit platforms the upper 32 bits of a passed in
>> GFN get ignored. Correct (imo) behavior would be to reject the upper
>> bits being non-zero.
>
> This is not only here but on pretty much all the hypercalls taking a gfn
> (on Arm it is 64-bit regardless the bitness).
>
> I agree this is not nice, but I am afraid this is likely another can of
> worm that I am not to open it yet.
Right - hence me saying "no action expected".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: Fold SVM into x86
On 23.08.2019 16:25, Andrew Cooper wrote: > We are now down to 0 SVM maintainers who are active and wish to hold the > position. Fall back to general x86 maintenance until this position changes. What you say above works for SVM, but ... > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -144,18 +144,6 @@ F: xen/drivers/acpi/ > F: xen/include/acpi/ > F: tools/libacpi/ > > -AMD IOMMU > -M: Suravee Suthikulpanit > -S: Maintained > -F: xen/drivers/passthrough/amd/ ... not for this, which will make me the only maintainer, which in turn I don't think is what you want. IOW if this is the way to go (see below) then I think you want to move this F: line to the X86 section. Independent of that I wonder whether we shouldn't get at least some consent from AMD on this, even if perhaps not in the shape of a formal ack. Lars, can you possibly try to help out with this? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode
On Thu, Aug 29, 2019 at 02:11:10PM +0200, Jan Beulich wrote: >On 27.08.2019 06:52, Chao Gao wrote: >> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote: >>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote: On 19/08/2019 02:25, Chao Gao wrote: > register an nmi callback. And this callback does busy-loop on threads > which are waiting for loading completion. Control threads send NMI to > slave threads to prevent NMI acceptance during ucode loading. > > Signed-off-by: Chao Gao > --- > Changes in v9: > - control threads send NMI to all other threads. Slave threads will > stay in the NMI handling to prevent NMI acceptance during ucode > loading. Note that self-nmi is invalid according to SDM. To me this looks like a half-measure: why keep only slave threads in the NMI handler, when master threads can update the microcode from inside the NMI handler as well? >>> >>> No special reason. Because the issue we want to address is that slave >>> threads might go to handle NMI and access MSRs when master thread is >>> loading ucode. So we only keep slave threads in the NMI handler. >>> You mention that self-nmi is invalid, but Xen has self_nmi() which is used for apply_alternatives() during boot, so can be trusted to work. >>> >>> Sorry, I meant using self shorthand to send self-nmi. I tried to use >>> self shorthand but got APIC error. And I agree that it is better to >>> make slave thread call self_nmi() itself. >>> I experimented a bit with the following approach: after loading_state becomes LOADING_CALLIN, each cpu issues a self_nmi() and rendezvous via cpu_callin_map into LOADING_ENTER to do a ucode update directly in the NMI handler. And it seems to work. Separate question is about the safety of this approach: can we be sure that a ucode update would not reset the status of the NMI latch? I.e. can it cause another NMI to be delivered while Xen already handles one? >>> >>> Ashok, what's your opinion on Sergey's approach and his concern? >> >> I talked with Ashok. We think your approach is better. I will follow >> your approach in v10. It would be much helpful if you post your patch >> so that I can just rebase it onto other patches. > >Doing the actual ucode update inside an NMI handler seems rather risky >to me. Even if Ashok confirmed it would not be an issue on past and >current Intel CPUs - what about future ones, or ones from other vendors? Will confirm these with Ashok. Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 15/15] microcode: block #NMI handling when loading an ucode
On Thu, Aug 29, 2019 at 02:22:47PM +0200, Jan Beulich wrote:
>On 19.08.2019 03:25, Chao Gao wrote:
>> @@ -481,12 +478,28 @@ static int do_microcode_update(void *patch)
>> return ret;
>> }
>>
>> +static int microcode_nmi_callback(const struct cpu_user_regs *regs, int cpu)
>> +{
>> +/* The first thread of a core is to load an update. Don't block it. */
>> +if ( cpu == cpumask_first(per_cpu(cpu_sibling_mask, cpu)) ||
>> + loading_state != LOADING_CALLIN )
>> +return 0;
>> +
>> +cpumask_set_cpu(cpu, _callin_map);
>> +
>> +while ( loading_state != LOADING_EXIT )
>> +cpu_relax();
>> +
>> +return 0;
>> +}
>
>By returning 0 you tell do_nmi() to continue processing the NMI.
>Since you can't tell whether a non-IPI NMI has surfaced at about
>the same time this is generally the right thing imo, but how do
>you prevent unknown_nmi_error() from getting entered when do_nmi()
>ends up setting handle_unknown to true? (The question is mostly
>rhetorical, but there's a disconnect between do_nmi() checking
>"cpu == 0" and the control thread running on
>cpumask_first(_online_map), i.e. you introduce a well hidden
>dependency on CPU 0 never going offline. IOW my request is to at
>least make this less well hidden, such that it can be noticed if
>and when someone endeavors to remove said limitation.)
Seems the issue is that we couldn't send IPI NMI to BSP, otherwise
unknown_nmi_error() would be trigger. And loading ucode after
rendezvousing all CPUs in NMI handler expects all CPUs to receive IPI
NMI. So this approach always has such issue.
Considering self_nmi is called at another place, could we provide a
way to temporarily suppress or (force) ignore unknown nmi error?
Thanks
Chao
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
