[Xen-devel] [ovmf test] 128860: regressions - FAIL
flight 128860 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128860/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs. 128856 version targeted for testing: ovmf fea5e28658c672ce2cbe38d0927ab27beb792097 baseline version: ovmf 3a0329bed2a2c7d1ba45bd2376a2320141ef2bec Last test of basis 128856 2018-10-17 17:40:49 Z0 days Testing same since 128860 2018-10-18 01:56:06 Z0 days1 attempts People who touched revisions under test: Hao Wu Yonghong Zhu 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 fail 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 Not pushing. commit fea5e28658c672ce2cbe38d0927ab27beb792097 Author: Yonghong Zhu Date: Wed Oct 17 20:15:07 2018 +0800 BaseTools: Fix bug caused by 03c36c36a3 In the expression for unicode string and general string compare, it should check whether it startswith "L'" or 'L"', but not "L". Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao commit 53c64f4286ba86788e350a82a3798e1a7abf5ef7 Author: Yonghong Zhu Date: Tue Oct 16 16:10:24 2018 +0800 BaseTools: Fix a bug --pcd option enable and use the pcd in expression the case is: in the DSC: [PcdsFixedAtBuild.common] TokenSpaceGuid.TestFixedPcd|0xFFEAA000 [PcdsDynamicExDefault.common.DEFAULT] !if TokenSpaceGuid.PcdFlag == TRUE TokenSpaceGuid.PcdTest|TokenSpaceGuid.TestFixedPcd !endif Then build with --pcd TokenSpaceGuid.PcdFlag=TRUE, it report failure, but if we build without this --pcd option, it could build success. we found when the --pcd is enabled, the fixedatbuild pcds are not be collected into expression to calculate. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=1256 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu Reviewed-by: Liming Gao commit 5317e9ccafed5a031c18293caa06b660af3e9a85 Author: Hao Wu Date: Mon Oct 15 10:26:08 2018 +0800 MdeModulePkg/UdfDxe: Handle dead codes in FileSystemOperations.c REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1249 We found potential dead codes within File.c during the code coverage test. After manual review, we think the below ones are positive reports: A. For function GetAllocationDescriptor(): Due to the all the calling places for this function, the input parameter 'RecordingFlags' can only with value 'LongAdsSequence' or 'ShortAdsSequence'. Moreover, this is also mentioned in the function description comments for GetAllocationDescriptor(). So the below code will never be reached: return EFI_DEVICE_ERROR; This commit will add "ASSERT (FALSE);" before the above line to indicate this and thus matching the function description comments. B. For function GetAllocationDescriptorLsn(): Due to the all the calling places for this function, the input parameter 'RecordingFlags' can only with value 'LongAdsSequence' or 'ShortAdsSequence'. Moreover, this is also mentioned in the function description comments for GetAllocationDescriptorLsn(). So the below code will never be reached: return EFI_UNSUPPORTED; This commit will add "ASSERT (FALSE);" before the above line to indicate this and thus matching the function description comments. Cc: Paulo Alcantara Cc: Paulo Alcantara Cc: Ruiyu Ni
[Xen-devel] [linux-linus test] 128835: regressions - FAIL
flight 128835 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/128835/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-credit1 7 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14
[Xen-devel] [ovmf test] 128856: all pass - PUSHED
flight 128856 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128856/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3a0329bed2a2c7d1ba45bd2376a2320141ef2bec baseline version: ovmf b7dcf31402f410c53242839271ba3b94b619 Last test of basis 128846 2018-10-17 06:10:55 Z0 days Testing same since 128856 2018-10-17 17:40:49 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Michael D Kinney 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 b7dcf3..3a0329bed2 3a0329bed2a2c7d1ba45bd2376a2320141ef2bec -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128857: tolerable all pass - PUSHED
flight 128857 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128857/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 00b1b8ed737376aaa9cb842dd5bbf759e54fd86e baseline version: xen a3ae747dea48664b622ac7fc96a598578d406e86 Last test of basis 128854 2018-10-17 17:00:23 Z0 days Testing same since 128857 2018-10-17 20:00:46 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git a3ae747dea..00b1b8ed73 00b1b8ed737376aaa9cb842dd5bbf759e54fd86e -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 128833: tolerable all pass - PUSHED
flight 128833 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/128833/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128724 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128724 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-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-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 3a1cdb06fd9bc5e35230f6198e697d6ec03d1206 baseline version: libvirt 6e7e965dcd3d885739129b1454ce19e819b54c25 Last test of basis 128724 2018-10-14 08:00:24 Z3 days Testing same since 128833 2018-10-16 02:50:33 Z1 days1 attempts People who touched revisions under test: Ján Tomko Wang Huaqiang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 6e7e965dcd..3a1cdb06fd 3a1cdb06fd9bc5e35230f6198e697d6ec03d1206 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 128841: regressions - FAIL
flight 128841 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128841/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs. 128258 test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail in 128807 REGR. vs. 128258 Tests which are failing intermittently (not blocking): test-amd64-amd64-examine4 memdisk-try-append fail in 128807 pass in 128841 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 128807 pass in 128841 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 128807 pass in 128841 test-armhf-armhf-xl-arndale 7 xen-boot fail pass in 128807 test-amd64-amd64-libvirt-pair 24 guest-migrate/dst_host/src_host/debian.repeat fail pass in 128807 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 128807 like 128177 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 128807 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 128807 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 128807 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 128807 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 128807 never pass test-armhf-armhf-xl-vhd 10 debian-di-installfail like 128232 test-amd64-amd64-pair 24 guest-migrate/dst_host/src_host/debian.repeat fail like 128258 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128258 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128258 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128258 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128258 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128258 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 128258 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 build-arm64-pvops 6 kernel-build 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-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-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-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-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-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
[Xen-devel] [qemu-mainline baseline-only test] 75441: trouble: blocked/broken
This run is configured for baseline tests only. flight 75441 qemu-mainline real [real] http://osstest.xensource.com/osstest/logs/75441/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1
Re: [Xen-devel] [RFC PATCH v1 00/16] xen: sched: implement core-scheduling
On Fri, Aug 24, 2018 at 5:36 PM Dario Faggioli wrote: > > Hello, > > As anticipated here: > https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html > > Here's a preliminary version of my work, trying to implement > core-scheduling in Xen. > > First of all, this deals with Credit1 only. I have patches for Credit2, > and I've been working on having them ready by today, but I could not > defeat the latest bugs. :-/ > I'll post them when back from vacation. Just let me anticipate, that > doing something like this in Credit2, is a lot simpler than what you > see here for Credit1. > > Even these patches that I'm posting are not perfect, and In fact there > are some TODOs and XXXs --both in the changelogs and in the code. > > They give me a system that boots, where I can do basic stuff (like > playing with dom0, creating guests, etc), and where the constraint of > only scheduling vcpus from one domain at a time on pcpus that are part > of the same core is, as far as I've seen, respected. > > There are still cases where the behavior is unideal, e.g., we could > make a better use of some of the cores which are, some of the times, > left idle. > > There are git branches here: > https://gitlab.com/dfaggioli/xen.git rel/sched/core-scheduling-RFCv1 > https://github.com/fdario/xen.git rel/sched/core-scheduling-RFCv1 > > Any comment is more than welcome. Hi Dario, thanks for the series, we are in the process of evaluating it in terms of performance. Our test is to setup 2 VMs each being assigned enough vCPUs to completely saturate all hyperthreads and then we fire up CPU benchmarking inside the VMs to spin each vCPU 100% (using swet). The idea is to force the scheduler to move vCPUs in-and-out constantly to see how much performance hit there would be with core-scheduling vs plain credit1 vs disabling hyperthreading. After running the test on a handful of machines it looks like we get the best performance with hyperthreading completely disabled, which is a bit unexpected. Have you or anyone else encountered this? Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75440: trouble: blocked/broken
This run is configured for baseline tests only. flight 75440 ovmf real [real] http://osstest.xensource.com/osstest/logs/75440/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 4 host-install(4) broken baseline untested build-i3864 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested version targeted for testing: ovmf b7dcf31402f410c53242839271ba3b94b619 baseline version: ovmf 25d310d9b6187ca2e770b0b959831416441ce271 Last test of basis75437 2018-10-17 06:20:33 Z0 days Testing same since75440 2018-10-17 11:20:35 Z0 days1 attempts People who touched revisions under test: Star Zeng jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-amd64 host-install(4) broken-step build-i386 host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-amd64-xsm host-install(4) broken-step build-i386-xsm host-install(4) broken-step build-amd64-pvops host-install(4) Push not applicable. commit b7dcf31402f410c53242839271ba3b94b619 Author: Star Zeng Date: Tue Feb 28 14:01:47 2017 +0800 MdeModulePkg Variable: Fix Timestamp zeroing issue on APPEND_WRITE REF: https://bugzilla.tianocore.org/show_bug.cgi?id=415 When SetVariable() to a time based auth variable with APPEND_WRITE attribute, and if the EFI_VARIABLE_AUTHENTICATION_2.TimeStamp in the input Data is earlier than current value, it will cause timestamp zeroing. This issue may bring time based auth variable downgrade problem. For example: A vendor released three certs at 2014, 2015, and 2016, and system integrated the 2016 cert. User can SetVariable() with 2015 cert and APPEND_WRITE attribute to cause timestamp zeroing first, then SetVariable() with 2014 cert to downgrade the cert. This patch fixes this issue. Cc: Jiewen Yao Cc: Chao Zhang Cc: Jian J Wang Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128854: tolerable all pass - PUSHED
flight 128854 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128854/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen a3ae747dea48664b622ac7fc96a598578d406e86 baseline version: xen f736a3b7285384529de932055856be0703f8ac20 Last test of basis 128852 2018-10-17 14:00:43 Z0 days Testing same since 128854 2018-10-17 17:00:23 Z0 days1 attempts People who touched revisions under test: Alexander Schulz Ian Jackson Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f736a3b728..a3ae747dea a3ae747dea48664b622ac7fc96a598578d406e86 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 128829: regressions - trouble: blocked/broken/fail/pass
flight 128829 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/128829/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-armhf-pvops 5 host-build-prep fail REGR. vs. 128656 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a 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-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen ed024ef538cd10ec33c9edacd5e5f2016a5964d2 baseline version: xen 9f8eff39ea21722ec99bb45b175c3ad5224b72da Last test of basis 128656 2018-10-12 04:49:29 Z5 days Testing same since 128702 2018-10-13 19:19:49 Z3 days2 attempts People who touched revisions under test: George Dunlap Ian Jackson Samuel Thibault jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
Thanks for all your support! Alex Am 17. Oktober 2018 18:33:45 MESZ schrieb Wei Liu : >On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng >Project Member wrote: >> We are the XCP-ng project (https://xcp-ng.org) and want to distribute >our >> own PV-Tools (maybe also per windows updates) so we need an extra >range. >> >> We also registered a PCI-Device: >> >> "XCP-ng Project PCI Device for Windows Update" -> >> https://pci-ids.ucw.cz/read/PC/5853/c200 >> >> Signed-off-by: Alexander Schulz > >I think your email client / server has mangled this patch badly. As Ian >observed, it wouldn't apply. > >Anyway, in the interest of avoiding another round of posting, I have >fixed up the patch and commit it for you. > >Wei. > >> --- >> docs/man/xen-pci-device-reservations.pod.7 | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/docs/man/xen-pci-device-reservations.pod.7 >> b/docs/man/xen-pci-device-reservations.pod.7 >> index 049e47410f..1cd5a3e115 100644 >> --- a/docs/man/xen-pci-device-reservations.pod.7 >> +++ b/docs/man/xen-pci-device-reservations.pod.7 >> @@ -41,6 +41,7 @@ multiple Xen vendors using conflicting IDs. >> 0x0002| Citrix XenServer (grandfathered allocation for >> XenServer 6.1) >> 0xc000-0xc0ff | Citrix XenServer >> 0xc100-0xc1ff | Citrix XenClient >> + 0xc200-0xc2ff | XCP-ng Project (https://xcp-ng.org) >> =head1 Notes >> -- 2.17.1.windows.2 >> >> ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng Project Member wrote: > We are the XCP-ng project (https://xcp-ng.org) and want to distribute our > own PV-Tools (maybe also per windows updates) so we need an extra range. > > We also registered a PCI-Device: > > "XCP-ng Project PCI Device for Windows Update" -> > https://pci-ids.ucw.cz/read/PC/5853/c200 > > Signed-off-by: Alexander Schulz I think your email client / server has mangled this patch badly. As Ian observed, it wouldn't apply. Anyway, in the interest of avoiding another round of posting, I have fixed up the patch and commit it for you. Wei. > --- > docs/man/xen-pci-device-reservations.pod.7 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/docs/man/xen-pci-device-reservations.pod.7 > b/docs/man/xen-pci-device-reservations.pod.7 > index 049e47410f..1cd5a3e115 100644 > --- a/docs/man/xen-pci-device-reservations.pod.7 > +++ b/docs/man/xen-pci-device-reservations.pod.7 > @@ -41,6 +41,7 @@ multiple Xen vendors using conflicting IDs. > 0x0002| Citrix XenServer (grandfathered allocation for > XenServer 6.1) > 0xc000-0xc0ff | Citrix XenServer > 0xc100-0xc1ff | Citrix XenClient > + 0xc200-0xc2ff | XCP-ng Project (https://xcp-ng.org) > =head1 Notes > -- 2.17.1.windows.2 > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 22/23] xen/arm: move kernel.h to asm-arm/
On 17/10/18 17:11, Julien Grall wrote: > > > On 17/10/2018 15:42, Stefano Stabellini wrote: >> On Mon, 15 Oct 2018, Julien Grall wrote: >>> Hi Stefano, >>> >>> On 05/10/2018 19:47, Stefano Stabellini wrote: It will be #included by a file in a xen/arch/arm subdirectory. Signed-off-by: Stefano Stabellini --- xen/arch/arm/domain_build.c | 2 +- xen/arch/arm/kernel.c | 3 +- xen/arch/arm/kernel.h | 86 xen/include/asm-arm/kernel.h | 86 >>> >>> There are way to make git diff nicer for code movement. This seems >>> to be done >>> by default on 2.11.0. Not sure for older version. What are you using? >> >> Git version 1.9.1 (and guilt 0.35) > > A 4 years old git version. May I ask to update to a new git (or see if > there are an option doing the same)? This would help reviewing code > movement. git config --global diff.renames=copy ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128852: tolerable all pass - PUSHED
flight 128852 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128852/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen f736a3b7285384529de932055856be0703f8ac20 baseline version: xen 7559ab7830c3e1594cd73efd3f1acbb171036728 Last test of basis 128840 2018-10-16 17:00:58 Z0 days Testing same since 128852 2018-10-17 14:00:43 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper George Dunlap Razvan Cojocaru Roger Pau Monne Roger Pau Monné Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 7559ab7830..f736a3b728 f736a3b7285384529de932055856be0703f8ac20 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI
device range 0xc200-0xc2ff to XCP-ng Project"):
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute
> our own PV-Tools (maybe also per windows updates) so we need an extra range.
>
> We also registered a PCI-Device:
>
> "XCP-ng Project PCI Device for Windows Update" ->
> https://pci-ids.ucw.cz/read/PC/5853/c200
>
> Signed-off-by: Alexander Schulz
I tried to apply this but
gmariner:xen.git> git-am ~/News/x
Applying: Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
error: corrupt patch at line 13
Patch failed at 0001 Reservation of PCI device range 0xc200-0xc2ff to XCP-ng
Project
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
mariner:xen.git>
That's on the copy I got via my colo and its mail-to-news gateway, so
not mangled by the Citrix corporate email system.
If you prefer you can publish a git branch...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 22/23] xen/arm: move kernel.h to asm-arm/
On 17/10/2018 15:42, Stefano Stabellini wrote: On Mon, 15 Oct 2018, Julien Grall wrote: Hi Stefano, On 05/10/2018 19:47, Stefano Stabellini wrote: It will be #included by a file in a xen/arch/arm subdirectory. Signed-off-by: Stefano Stabellini --- xen/arch/arm/domain_build.c | 2 +- xen/arch/arm/kernel.c| 3 +- xen/arch/arm/kernel.h| 86 xen/include/asm-arm/kernel.h | 86 There are way to make git diff nicer for code movement. This seems to be done by default on 2.11.0. Not sure for older version. What are you using? Git version 1.9.1 (and guilt 0.35) A 4 years old git version. May I ask to update to a new git (or see if there are an option doing the same)? This would help reviewing code movement. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
On Wed, Oct 17, 2018 at 04:16:03PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
> qemu-xen runnning in a Linux-based stubdomain."):
> > [stuff]
>
> So, I only got a little way through this series, but it was a while
> ago and you say things are done differently now. I'm not sure if it
> is useful for me to review the rest of it.
>
> Would it be better for me to await a repost ?
All the xenconsoled stuff is unchanged (and unlikely to change), so it
should be safe to review it. Patches 06 and 07 also shouldn't change.
The thing that will change is qemu cmdline and qmp handling. TBH I'm not sure
if its better to touch qmp now, or after reworked qmp handling by
Anthony will be merged. There will definitely be some conflicts and it
may even affects what underlying mechanism is chosen for qmp transport.
Based on discussion here, and in libxl__ev_qmp_* thread, I see two
viable options:
1. libvchan
pros:
- out of band reset support, so qmp capabilities negotiation can be
handled gracefully
cons:
- more work, require patching qemu (or adding vchan->socket proxy),
adds dependency on libvchan to libxl (probably not a problem)
- possibly more complex libxl__ev_qmp_* handling, or at least needs
separate handling of send/receive for stubdomain case
2. pv console
pros:
- no qemu modifications
- same read()/write() on libxl side
cons:
- no out of band reset, needs libxl handling for that (skipping
negotiation)
- possibly other problems from that (events filling up some buffers
when no one is listening?)
In both cases, there is only one simultaneous connection to qemu, so
some locking will be needed at libxl side.
BTW Does libxl listed for qmp events?
There is also third option: xenstore, but that would probably require
totally separate libxl__ev_qmp_* implementation, so I'd rule it out.
If problems with pv console could be solved, I'd go this way. But
otherwise libvchan seems like a good alternative.
Adding Anthony.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH] cr-for-branches: Add linux 4.4 branch as that is an LTS
---
cr-for-branches | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cr-for-branches b/cr-for-branches
index 6f544379..f7e4caea 100755
--- a/cr-for-branches
+++ b/cr-for-branches
@@ -31,7 +31,7 @@ scriptoptions="$1"; shift
LOGFILE=tmp/cr-for-branches.log
export LOGFILE
-: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-4.6-testing xen-4.7-testing
xen-4.8-testing xen-4.9-testing xen-4.10-testing xen-4.11-testing xen-unstable
qemu-mainline qemu-upstream-unstable qemu-upstream-4.2-testing
qemu-upstream-4.3-testing qemu-upstream-4.4-testing qemu-upstream-4.5-testing
qemu-upstream-4.6-testing qemu-upstream-4.7-testing qemu-upstream-4.8-testing
qemu-upstream-4.9-testing qemu-upstream-4.10-testing qemu-upstream-4.11-testing
linux-linus linux-4.14 linux-4.9 linux-4.1 linux-3.18 linux-3.16 linux-3.14
linux-3.10 linux-3.4 linux-arm-xen seabios ovmf xtf ${EXTRA_BRANCHES}}
+: ${BRANCHES:=osstest xen-4.0-testing xen-4.1-testing xen-4.2-testing
xen-4.3-testing xen-4.4-testing xen-4.5-testing xen-4.6-testing xen-4.7-testing
xen-4.8-testing xen-4.9-testing xen-4.10-testing xen-4.11-testing xen-unstable
qemu-mainline qemu-upstream-unstable qemu-upstream-4.2-testing
qemu-upstream-4.3-testing qemu-upstream-4.4-testing qemu-upstream-4.5-testing
qemu-upstream-4.6-testing qemu-upstream-4.7-testing qemu-upstream-4.8-testing
qemu-upstream-4.9-testing qemu-upstream-4.10-testing qemu-upstream-4.11-testing
linux-linus linux-4.14 linux-4.9 linux-4.4 linux-4.1 linux-3.18 linux-3.16
linux-3.14 linux-3.10 linux-3.4 linux-arm-xen seabios ovmf xtf
${EXTRA_BRANCHES}}
export BRANCHES
fetchwlem=$wlem
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng Project Member wrote: > We are the XCP-ng project (https://xcp-ng.org) and want to distribute our > own PV-Tools (maybe also per windows updates) so we need an extra range. > > We also registered a PCI-Device: > > "XCP-ng Project PCI Device for Windows Update" -> > https://pci-ids.ucw.cz/read/PC/5853/c200 > > Signed-off-by: Alexander Schulz Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
Am 17.10.2018 um 17:14 schrieb Ian Jackson:
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI device
range 0xc200-0xc2ff to XCP-ng Project"):
We are the XCP-ng project (https://xcp-ng.org) and want to distribute
our own PV-Tools (maybe also per windows updates) so we need an extra range.
Thanks. I acked your previous message which was sent by private
email; I think you could have transferred my ack to this repost.
Acked-by: Ian Jackson
I just wanted to say that it is a very good thing to come here and
reserve a number. We should assign numbers without too much
quibbling, which is why I have given a summary ack.
IMO this should be committed soon.
We also registered a PCI-Device:
"XCP-ng Project PCI Device for Windows Update" ->
https://pci-ids.ucw.cz/read/PC/5853/c200
You've got your own PCI device *and* a range in the Xen Platform PCI
Device ? I confess I don't know why that is necessary. Perhaps it is
more obvious to those who understand this all better than I do.
It was recommended by Paul Durrant:
https://lists.xenproject.org/archives/html/win-pv-devel/2018-10/msg5.html
"I think it would probably be better if you took a range. It's not in
writing but I think other things have played with those low numbered
device ids in the past so probably best to avoid them. Would you be ok
with the next range of 0x100 above XenClient, i.e. 0xc200-0xc2ff? "
Regards,
Ian.
Alexander Schulz
XCP-ng Project Member
Maintainer of: XCP-ng Center and XCP-ng PV-Tools
XCP-ng Project
--
web: https://xcp-ng.org
Github: https://github.com/xcp-ng
IRC: #xcp-ng on Freenode
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-squeeze test] 75438: trouble: blocked/broken
flight 75438 distros-debian-squeeze real [real] http://osstest.xensource.com/osstest/logs/75438/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-i386-i386-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-squeeze-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-squeeze-netboot-pygrub 1 build-check(1)blocked n/a build-armhf 4 host-install(4) broken like 75385 build-armhf-pvops 4 host-install(4) broken like 75385 build-i3864 host-install(4) broken like 75385 build-i386-pvops 4 host-install(4) broken like 75385 build-amd64-pvops 4 host-install(4) broken like 75385 build-amd64 4 host-install(4) broken like 75385 baseline version: flight 75385 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked test-amd64-i386-amd64-squeeze-netboot-pygrub blocked test-amd64-amd64-i386-squeeze-netboot-pygrub blocked test-amd64-i386-i386-squeeze-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] devicetree, xen: add xen, shared-memory binding
On Mon, Oct 08, 2018 at 04:03:54PM -0700, Stefano Stabellini wrote: > Introduce a device tree binding for Xen reserved-memory regions. They > are used to share memory across VMs from the VM config files. (See > static_shm config option.) > > Signed-off-by: Stefano Stabellini checkpatch.pl complains that the author and S-o-b don't match. > Cc: julien.gr...@arm.com > > diff --git > a/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt > b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt > new file mode 100644 > index 000..a927a94 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt > @@ -0,0 +1,20 @@ > +* Xen hypervisor reserved-memory binding > + > +Expose one or more memory regions as reserved-memory to the guest > +virtual machine. Typically, a region is configured at VM creation time > +to be a shared memory area across multiple virtual machines for > +communication among them. > + > +For each of these pre-shared memory regions, a range is exposed under > +the /reserved-memory node as a child node. Each range sub-node is named > +xen-shmem@ and has the following properties: > + > +- compatible: > + compatible = xen,shared-memory" Any need for versioning? > + > +- reg: > + the base guest physical address and size of the shared memory region > + > +- id: xen,id > + a string that identifies the shared memory region as specified in > + the VM config file ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k
The P2M common code currently restricts the MMIO mapping order of any
domain with IOMMU mappings, but that is not using shared tables, to 4k.
This has been shown to have a huge performance cost when passing through
a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
boot time from ~20s to several minutes when iommu=no-sharept is specified
on the Xen command line.
The limitation was added by commit c3c756bd "x86/p2m: use large pages
for MMIO mappings" however the underlying implementations of p2m->set_entry
for Intel and AMD are coded to cope with mapping orders higher than 4k,
even though the IOMMU mapping function is itself currently limited to 4k,
so there is no real need to limit the order passed into the method, other
than to avoid a potential DoS caused by a long running hypercall.
In practice, mmio_order() already strictly disallows 1G mappings since the
if clause in question starts with:
if ( 0 /*
* Don't use 1Gb pages, to limit the iteration count in
* set_typed_p2m_entry() when it needs to zap M2P entries
* for a RAM range.
*/ &&
With this patch applied (and hence 2M mappings in use) the VM boot time is
restored to something reasonable. Not as fast as without iommu=no-sharept,
but within a few seconds of it.
NOTE: This patch takes the opportunity to shorten a couple of > 80
character lines in the code.
Signed-off-by: Paul Durrant
Acked-by: George Dunlap
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
v2:
- Add an extra to the if clause disallowing 1G mappings to make sure
they are not used if need_iommu_pt_sync() is true, even though the
check is currently moot (see main comment).
---
xen/arch/x86/mm/p2m.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index a00a3c1bff..f972b4819d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2081,14 +2081,11 @@ static unsigned int mmio_order(const struct domain *d,
unsigned long start_fn, unsigned long nr)
{
/*
- * Note that the !iommu_use_hap_pt() here has three effects:
- * - cover iommu_{,un}map_page() not having an "order" input yet,
- * - exclude shadow mode (which doesn't support large MMIO mappings),
- * - exclude PV guests, should execution reach this code for such.
- * So be careful when altering this.
+ * PV guests or shadow-mode HVM guests must be restricted to 4k
+ * mappings.
*/
-if ( !iommu_use_hap_pt(d) ||
- (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >> PAGE_ORDER_2M) )
+if ( !hap_enabled(d) || (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) ||
+ !(nr >> PAGE_ORDER_2M) )
return PAGE_ORDER_4K;
if ( 0 /*
@@ -2096,8 +2093,12 @@ static unsigned int mmio_order(const struct domain *d,
* set_typed_p2m_entry() when it needs to zap M2P entries
* for a RAM range.
*/ &&
- !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) && (nr >> PAGE_ORDER_1G) &&
- hap_has_1gb )
+ !(start_fn & ((1UL << PAGE_ORDER_1G) - 1)) &&
+ (nr >> PAGE_ORDER_1G) &&
+ hap_has_1gb &&
+ /* disable 1G mappings if we need to keep the IOMMU in sync */
+ !need_iommu_pt_sync(d)
+)
return PAGE_ORDER_1G;
if ( hap_has_2mb )
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation
On Wed, Oct 17, 2018 at 7:41 AM Razvan Cojocaru wrote: > > On 10/5/18 2:00 PM, Razvan Cojocaru wrote: > > On 9/27/18 2:25 PM, George Dunlap wrote: > >> The name of the "with_gla" flag is confusing; it has nothing to do > >> with the existence or lack thereof of a faulting GLA, but rather where > >> the fault originated. The npfec.kind value is always valid, and > >> should thus be propagated, regardless of whether gla_valid is set or > >> not. > >> > >> In particular, gla_valid will never be set on AMD systems; but > >> npfec.kind will still be valid and should still be propagated. > >> > >> Signed-off-by: Alexandru Isaila > >> Signed-off-by: George Dunlap > > > > Acked-by: Razvan Cojocaru > > Does this also need Tamas' ack to go in? Hm, I recall acking this patch before. In any case: Acked-by: Tamas K Lengyel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 21/23] xen/vpl011: buffer out chars when the backend is xen
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > To avoid mixing the output of different domains on the console, buffer
> > the output chars and print line by line. Unless the domain has input
> > from the serial, in which case we want to print char by char for a
> > smooth user experience.
> >
> > The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
> > as VUART_BUT_SIZE used in vuart.c.
> >
> > Export a function named console_input_domain() to allow others to know
> > which domains has input at a given time.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: andrew.coop...@citrix.com
> > CC: george.dun...@eu.citrix.com
> > CC: ian.jack...@eu.citrix.com
> > CC: jbeul...@suse.com
> > CC: konrad.w...@oracle.com
> > CC: t...@xen.org
> > CC: wei.l...@citrix.com
> > ---
> > XXX: merge this patch with "xen/arm: Allow vpl011 to be used by DomU" on
> > commit
>
> That's not going to make the series bisectable as it depends on an
> intermediate patch for console_input_domain().
A tiny patch reordering will fix this. I'll do.
> The new logic looks better to me, few comments below.
Good!
> >
> > Changes in v4:
> > - make SBSA_UART_OUT_BUF_SIZE the same size of VUART_BUT_SIZE
> > - rearrange the code to be clearer input and != input cases
> > - code style
> > - add \n when printing the out buffer because is full
> > - don't print prefix for input domain
> > ---
> > xen/arch/arm/vpl011.c| 35 ---
> > xen/drivers/char/console.c | 7 +++
> > xen/include/asm-arm/vpl011.h | 4
> > xen/include/xen/console.h| 2 ++
> > 4 files changed, 45 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 131507e..5e57ada 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -85,12 +86,40 @@ static void vpl011_write_data_xen(struct domain *d,
> > uint8_t data)
> > {
> > unsigned long flags;
> > struct vpl011 *vpl011 = >arch.vpl011;
> > +struct vpl011_xen_backend *intf = vpl011->backend.xen;
> > +struct domain *input = console_input_domain();
> > VPL011_LOCK(d, flags);
> > -printk("%c", data);
> > -if (data == '\n')
> > -printk("DOM%u: ", d->domain_id);
> > +intf->out[intf->out_prod++] = data;
> > +if ( d == input )
> > +{
> > +if ( intf->out_prod == 1 )
> > +{
> > +printk("%c", data);
> > +intf->out_prod = 0;
> > +}
> > +else
> > +{
> > +if ( data != '\n' )
> > +intf->out[intf->out_prod++] = '\n';
> > +intf->out[intf->out_prod++] = '\0';
> > +printk("%s", intf->out);
> > +intf->out_prod = 0;
> > +}
> > +}
> > +else
> > +{
> > +if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
> > + data == '\n' )
> > +{
> > +if ( data != '\n' )
> > +intf->out[intf->out_prod++] = '\n';
> > +intf->out[intf->out_prod++] = '\0';
> > +printk("DOM%u: %s", d->domain_id, intf->out);
> > +intf->out_prod = 0;
> > +}
> > +}
> > vpl011->uartris |= TXI;
> > vpl011->uartfr &= ~TXFE;
> > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> > index 0808bac..9a2b29a 100644
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -406,6 +406,13 @@ static void dump_console_ring_key(unsigned char key)
> >*/
> > static unsigned int __read_mostly console_rx = 0;
> > +struct domain *console_input_domain(void)
> > +{
> > +if ( console_rx == 0 )
> > +return NULL;
> > +return get_domain_by_id(console_rx - 1);
> > +}
> > +
> > static void switch_serial_input(void)
> > {
> > if ( console_rx++ == max_init_domid + 1 )
> > diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
> > index 5eb6d25..ab6fd79 100644
> > --- a/xen/include/asm-arm/vpl011.h
> > +++ b/xen/include/asm-arm/vpl011.h
> > @@ -30,9 +30,13 @@
> > #define VPL011_UNLOCK(d,flags)
> > spin_unlock_irqrestore(&(d)->arch.vpl011.lock, flags)
> > #define SBSA_UART_FIFO_SIZE 32
> > +/* Same size as VUART_BUT_SIZE, used in vuart.c */
>
> s/BUT/BUF/
I'll fix
> > +#define SBSA_UART_OUT_BUF_SIZE 128
>
> You could directly use VUART_BUF_SIZE here to avoid the comment above.
That is true, but I think it is nicer to keep the two #define separate
> > struct vpl011_xen_backend {
> > char in[SBSA_UART_FIFO_SIZE];
> > +char out[SBSA_UART_OUT_BUF_SIZE];
> > XENCONS_RING_IDX in_cons, in_prod;
> > +XENCONS_RING_IDX out_prod;
> > };
> > struct vpl011 {
> > diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
> >
Re: [Xen-devel] Xen optimization
Hi,
>
> The device tree with everything seems to be system.dts, that was enough
> :-) I don't need the dtsi files you used to build the final dts, I only
> need the one you use in uboot and for your guest.
I wasn't sure so I sent everything, sorry for being bombarded with
all those files. :-)
> It looks like you set xen,passthrough correctly in system.dts for
> timer@ff11, serial@ff01, and gpio@ff0a.
Thank you for taking a look, now we are sure that passthrough works
correctly because there is no error during guest creation and there
are no prints of "DEBUG irq slow path".
> If you are not getting any errors anymore when creating your baremetal
> guest, then yes, it should be working passthrough. I would double-check
> that everything is working as expected using the DEBUG patch for Xen I
> suggested to you in the other email. You might even want to remove the
> "if" check and always print something for every interrupt of your guest
> just to get an idea of what's going on. See the attached patch.
When I apply this patch it prints forever:
(XEN) DEBUG virq=68 local=1
which is a good thing I guess because interrupts are being generated non-stop.
> Once everything is as expected I would change the frequency of the
> timer, because 1u is way too frequent. I think it should be at least
> 3us, more like 5us.
Okay, about this... I double checked my bare-metal application and
looks like interrupts weren't generated every 1 us. Maximum frequency
of interrupts is 8 us. I checked interrupt frequency with oscilloscope
just to be sure (toggling LED on/off when interrupts occur). So, when
I set:
- interrupts to be generated every 8 us I get jitter of 6 us
- interrupts to be generated every 10 us I get jitter of 3 us (after
2-3mins it jumps to 6 us)
- interrupts to be generated every 15 us jitter is the same as when
only bare-metal application runs on board (without Xen or any OS)
I want to remind you that bare-metal application that only blinks LED
with high speed gives 1 us jitter, somehow introducing frequent
interrupts causes this jitter, that's why I was unsecure about this
timer passthrough. Taking in consideration that you measured Xen
overhead of 1 us I have a feeling that I'm missing something, is there
anything else I could do to get better results except sched=null,
vwfi=native, hard vCPU pinning (1 vCPU on 1 pCPU) and passthrough (not
sure if it affects the jitter) ?
I'm forcing frequent interrupts because I'm testing to see if this
board with Xen on it could be used for real-time simulations,
real-time signal processing, etc. If I could get results like yours (1
us Xen overhead) of even better that would be great! BTW how did you
measure Xen's overhead?
> Keep in mind that jitter is about having
> deterministic IRQ latency, not about having extremely frequent
> interrupts.
Yes, but I want to see exactly where will I lose deterministic IRQ
latency which is extremely important in real-time signal processing.
So, what causes this jitter, are those Xen limits, ARM limits, etc? It
would be nice to know, I'll share all the results I get.
> I would also double check that you are not using any other devices or
> virtual interfaces in your baremetal app because that could negatively
> affect the numbers.
I checked the bare-metal app and I think there is no other devices
that bm app is using.
> Linux by default uses the virtual
> timer interface ("arm,armv8-timer", I would double check that the
> baremetal app is not doing the same -- you don't want to be using two
> timers when doing your measurements.
Hmm, I'm not sure how to check that, I could send bare-metal app if
that helps, it's created in Xilinx SDK 2017.4.
Also, should I move to Xilinx SDK 2018.2 because I'm using PetaLinux 2018.2 ?
I'm also using hardware description file for SDK that is created in
Vivado 2017.4.
Is all this could be a "not matching version" problem (I don't think
so because bm app works)?
Meng mentioned in some of his earlier posts:
> Even though the app. is the only one running on the CPU, the CPU may
> be used to handle other interrupts and its context (such as TLB and
> cache) might be flushed by other components. When these happen, the
> interrupt handling latency can vary a lot.
What do you think about this? I don't know how would I check this.
I also tried using default scheduler (removed sched=null and
vwfi=native) and jitter is 10 us when interrupt is generated every 10
us.
Thanks in advance!
Milan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> [stuff]
So, I only got a little way through this series, but it was a while
ago and you say things are done differently now. I'm not sure if it
is useful for me to review the rest of it.
Would it be better for me to await a repost ?
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI
device range 0xc200-0xc2ff to XCP-ng Project"):
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute
> our own PV-Tools (maybe also per windows updates) so we need an extra range.
Thanks. I acked your previous message which was sent by private
email; I think you could have transferred my ack to this repost.
Acked-by: Ian Jackson
I just wanted to say that it is a very good thing to come here and
reserve a number. We should assign numbers without too much
quibbling, which is why I have given a summary ack.
IMO this should be committed soon.
> We also registered a PCI-Device:
>
> "XCP-ng Project PCI Device for Windows Update" ->
> https://pci-ids.ucw.cz/read/PC/5853/c200
You've got your own PCI device *and* a range in the Xen Platform PCI
Device ? I confess I don't know why that is necessary. Perhaps it is
more obvious to those who understand this all better than I do.
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 14/23] xen/arm: generate a simple device tree for domUs
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > +static int __init make_gic_domU_node(const struct domain *d, void *fdt)
> > +{
> > +switch ( gic_hw_version() )
>
> While I understand that today domains will use the same GIC version as the
> host, it would be best if we don't rely on this in the generation of the DT.
>
> So I would use d->arch.vgic.version here.
>
> With that change:
>
> Acked-by: Julien Grall
Done, thanks!
>
> > +{
> > +case GIC_V3:
> > +return make_gicv3_domU_node(d, fdt);
> > +case GIC_V2:
> > +return make_gicv2_domU_node(d, fdt);
> > +default:
> > +panic("Unsupported GIC version");
> > +}
> > +}
>
> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 11/23] xen/arm: refactor construct_dom0
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Move generic initializations out of construct_dom0 so that they can be
> > reused.
> >
> > Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
> >
> > No functional changes in this patch.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v4:
> > - newline and style changes
> >
> > Changes in v3:
> > - move setting type before allocate_memory
> > - add ifdef around it and a comment
> >
> > Changes in v2:
> > - move discard_initial_modules() after __construct_domain()
> > - remove useless blank line
> > - leave safety BUG_ONs in __construct_domain
> > - rename prepare_dtb to prepare_dtb_hwdom
> > ---
> > xen/arch/arm/domain_build.c | 126
> >
> > 1 file changed, 68 insertions(+), 58 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index fddfd82..ba3dad1 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1456,7 +1456,7 @@ static int __init handle_node(struct domain *d, struct
> > kernel_info *kinfo,
> > return res;
> > }
> > -static int __init prepare_dtb(struct domain *d, struct kernel_info
> > *kinfo)
> > +static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
> > *kinfo)
> > {
> > const p2m_type_t default_p2mt = p2m_mmio_direct_c;
> > const void *fdt;
> > @@ -2191,75 +2191,29 @@ static void __init find_gnttab_region(struct domain
> > *d,
> > kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
> > }
> > -int __init construct_dom0(struct domain *d)
> > +static int __init __construct_domain(struct domain *d, struct kernel_info
> > *kinfo)
>
> Why do you need to add __ in front? The more we are trying to avoid
> introducing name/variable with __ in front.
No, I can rename it to construct_domain
> The rest of the patch looks good to me.
great!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 16/23] xen/arm: generate vpl011 node on device tree for domU
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Introduce vpl011 support to guests started from Xen: it provides a
> > simple way to print output from a guest, as most guests come with a
> > pl011 driver. It is also able to provide a working console with
> > interrupt support.
> >
> > The UART exposed to the guest is a SBSA compatible UART and not a PL011.
> > SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
> > would just be too difficult, so guests may require some drivers changes.
> >
> > Enable vpl011 conditionally if the user requested it.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v4:
> > - move rename set_interrupt_ppi and making set_interrupt_ppi generic to
> >a separate patch
> > - properly name the vpl011 device node name
> > - code style
> > - use #define for addrcells and sizecells
> >
> > Changes in v3:
> > - use bool
> > - retain BUG_ON(irq < 16)
> > - add vpl011 bool to kinfo
> > - return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
> >missing
> >
> > Changes in v2:
> > - code style fixes
> > - make set_interrupt_ppi generic
> > - rename set_interrupt_ppi to set_interrupt
> > - only make the vpl011 node if the option was enabled
> > ---
> > xen/arch/arm/domain_build.c | 61
> > +
> > xen/arch/arm/kernel.h | 3 +++
> > 2 files changed, 64 insertions(+)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 760ebf8..049ab84 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1605,6 +1605,54 @@ static int __init make_timer_domU_node(const struct
> > domain *d, void *fdt)
> > return res;
> > }
> > +#ifdef CONFIG_SBSA_VUART_CONSOLE
> > +static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
> > +{
> > +int res;
> > +gic_interrupt_t intr;
> > +__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
> > +__be32 *cells;
> > +
> > +res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
> > +if ( res )
> > +return res;
> > +
> > +res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
> > +if ( res )
> > +return res;
> > +
> > +cells = [0];
> > +dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
> > + GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
> > + GUEST_PL011_SIZE);
> > +if ( res )
> > +return res;
> > +res = fdt_property(fdt, "reg", reg, sizeof(reg));
> > +if ( res )
> > +return res;
> > +
> > +set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
> > +
> > +res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
> > +if ( res )
> > +return res;
> > +
> > +res = fdt_property_cell(fdt, "interrupt-parent",
> > +GUEST_PHANDLE_GIC);
> > +if ( res )
> > +return res;
> > +
> > +/* Use a default baud rate of 115200. */
> > +fdt_property_u32(fdt, "current-speed", 115200);
> > +
> > +res = fdt_end_node(fdt);
> > +if ( res )
> > +return res;
> > +
> > +return 0;
> > +}
> > +#endif
> > +
> > /*
> >* The max size for DT is 2MB. However, the generated DT is small, 4KB
> >* are enough for now, but we might have to increase it in the future.
> > @@ -1666,6 +1714,16 @@ static int __init prepare_dtb_domU(struct domain *d,
> > struct kernel_info *kinfo)
> > if ( ret )
> > goto err;
> > +if ( kinfo->vpl011 )
> > +{
> > +ret = -EINVAL;
> > +#ifdef CONFIG_SBSA_VUART_CONSOLE
> > +ret = make_vpl011_uart_node(d, kinfo->fdt);
> > +#endif
> > +if ( ret )
> > +goto err;
> > +}
> > +
> > ret = fdt_end_node(kinfo->fdt);
> > if ( ret < 0 )
> > goto err;
> > @@ -2523,6 +2581,7 @@ static int __init construct_domU(struct domain *d,
> > struct kernel_info kinfo = {};
> > int rc;
> > u64 mem;
> > +u32 len;
> > rc = dt_property_read_u64(node, "memory", );
> > if ( !rc )
> > @@ -2534,6 +2593,8 @@ static int __init construct_domU(struct domain *d,
> > printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus,
> > mem);
> > +kinfo.vpl011 = dt_get_property(node, "vpl011", ) != NULL;
>
> You can use dt_property_read_bool here.
I'll do
> > +
> > d->vcpu = xzalloc_array(struct vcpu *, d->max_vcpus);
> > if ( !d->vcpu )
> > return -ENOMEM;;
> > diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> > index 4320f72..33f3e72 100644
> > --- a/xen/arch/arm/kernel.h
> > +++ b/xen/arch/arm/kernel.h
> > @@ -33,6 +33,9 @@ struct kernel_info {
> > paddr_t dtb_paddr;
> > paddr_t initrd_paddr;
> > +/* Enable pl011 emulation */
> > +bool vpl011;
> > +
> > /* loader to use for this kernel */
> >
Re: [Xen-devel] [PATCH v2 4/4] xen: use __symbol everywhere
Hi,
On 17/10/2018 15:31, Stefano Stabellini wrote:
Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
is only required when comparing pointers, but use it everywhere to avoid
Well no. It is also required when substracting pointers (see [1]).
confusion.
[...]
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 52ed7ed..305b337 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -187,8 +187,8 @@ static int __apply_alternatives_multi_stop(void *unused)
{
int ret;
struct alt_region region;
-mfn_t xen_mfn = virt_to_mfn(_start);
-paddr_t xen_size = _end - _start;
+mfn_t xen_mfn = virt_to_mfn(__symbol(_start));
+paddr_t xen_size = __symbol(_end) - __symbol(_start);
unsigned int xen_order = get_order_from_bytes(xen_size);
void *xenmap;
@@ -206,7 +206,7 @@ static int __apply_alternatives_multi_stop(void *unused)
region.begin = __alt_instructions;
region.end = __alt_instructions_end;
-ret = __apply_alternatives(, xenmap - (void *)_start);
+ret = __apply_alternatives(, xenmap - (void *)__symbol(_start));
For instance, I think this line would be contain undefined behavior.
There are probably others below.
[...]
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7a06a33..d9d3948 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -620,7 +620,7 @@ void __init setup_pagetables(unsigned long
boot_phys_offset, paddr_t xen_paddr)
int i;
/* Calculate virt-to-phys offset for the new location */
-phys_offset = xen_paddr - (unsigned long) _start;
+phys_offset = xen_paddr - (unsigned long) __symbol(_start);
#ifdef CONFIG_ARM_64
p = (void *) xen_pgtable;
@@ -681,7 +681,8 @@ void __init setup_pagetables(unsigned long
boot_phys_offset, paddr_t xen_paddr)
ttbr = (uintptr_t) cpu0_pgtable + phys_offset;
#endif
-relocate_xen(ttbr, _start, (void*)dest_va, _end - _start);
+relocate_xen(ttbr, (void*)__symbol(_start), (void*)dest_va,
+__symbol(_end) - __symbol(_start));
No hard tab.
[...]
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ea2495a..9d0b915 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -394,7 +394,8 @@ static paddr_t __init get_xen_paddr(void)
paddr_t paddr = 0;
int i;
-min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
+min_size = (__symbol(_end) - __symbol(_start) +
+ (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
/* Find the highest bank with enough space. */
for ( i = 0; i < mi->nr_banks; i++ )
@@ -727,8 +728,9 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Register Xen's load address as a boot module. */
xen_bootmodule = add_boot_module(BOOTMOD_XEN,
- (paddr_t)(uintptr_t)(_start + boot_phys_offset),
- (paddr_t)(uintptr_t)(_end - _start + 1), NULL);
+ (paddr_t)(uintptr_t)(__symbol(_start) +
boot_phys_offset),
+ (paddr_t)(uintptr_t)(__symbol(_end) -
+
__symbol(_start) + 1), NULL);
No hard tab.
BUG_ON(!xen_bootmodule);
xen_paddr = get_xen_paddr();
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 93b79c7..0a7d6c0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
[...]
@@ -1390,22 +1393,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
{
/* Mark .text as RX (avoiding the first 2M superpage). */
modify_xen_mappings(XEN_VIRT_START + MB(2),
-(unsigned long)&__2M_text_end,
+(unsigned long)__symbol(&__2M_text_end),
PAGE_HYPERVISOR_RX);
/* Mark .rodata as RO. */
-modify_xen_mappings((unsigned long)&__2M_rodata_start,
-(unsigned long)&__2M_rodata_end,
+modify_xen_mappings((unsigned long)__symbol(&__2M_rodata_start),
+(unsigned long)__symbol(&__2M_rodata_end),
AFAICT the return of __symbol should be unsigned long, right? If so, the
cast could be removed.
Cheers,
[1]
https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] add myself as reviewer for Xen support in Linux
On 10/17/18 9:44 AM, Stefano Stabellini wrote: > It would be good for me to keep an eye on the patches that touch Xen > support in Linux to try to spot changes that break Xen on ARM early on. > > Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky > > diff --git a/MAINTAINERS b/MAINTAINERS > index 40082e4..0c1984e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -16013,6 +16013,7 @@ F:arch/arm64/include/asm/xen/ > XEN HYPERVISOR INTERFACE > M: Boris Ostrovsky > M: Juergen Gross > +R: Stefano Stabellini > L: xen-devel@lists.xenproject.org (moderated for non-subscribers) > T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > S: Supported ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/svm: Remove the pdpe fields from struct vmcb
On 10/17/18 8:47 AM, Andrew Cooper wrote: > These fields have existed since the SVM code was first introduced. > > The earliest reference I can find is c/s d1bd157fbc9 which is unforunately a > rebase & squash of a separate dev tree. Looking a the commit message, I'm > guessing it was introduced by: > > > user:twol...@xen-trw1.site > > date:Tue Dec 13 19:49:53 2005 -0500 > > files: ... xen/include/asm-x86/svm_vmcb.h ... > > description: > > Add SVM base files to repository. > > Anyway, the AMD SDM has no mention of PDPE fields in the VMCB and marks this > part of the VMCB as reserved. The manual does explicitly say that 32bit PAE > paging may read the PDPE fields from memory rather from the CPU registers. > > Chances are very good that this is a vestigial remnent of an early design. > Xen doesn't use the fields at all, except to copy them on virtual > vmentry/vmexit. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping AMD maintainers? [PATCH] x86/svm: Fix svm_update_guest_efer() for domains using shadow paging
On 10/17/18 8:08 AM, Andrew Cooper wrote: > On 05/10/18 18:02, Andrew Cooper wrote: >> When using shadow paging, EFER.NX is a Xen controlled bit, and is required by >> the shadow pagefault handler to distinguish instruction fetches from data >> accesses. >> >> This can be observed by a guest which has NX and SMEP clear but SMAP active >> by >> attempting to execute code on a user mapping. The first attempt to build the >> target shadow will #PF so is handled by the shadow code, but when walking the >> the guest pagetables, the lack of PFEC_insn_fetch being signalled causes the >> shadow code to mistake the instruction fetch for a data fetch, and believe >> that it is a real guest fault. As a result, the guest receives #PF[-d-srP] >> for an action which should complete successfully. >> >> The suspicious-looking gymnastics with LME is actually a subtle corner case >> with shadow paging. When dropping out of Long Mode, a guests choice of LME >> and Xen's choice of CR0.PG cause hardware to operate in Long Mode, but the >> shadow code to operate in 2-on-3 mode. >> >> In addition to describing this corner case in the SVM side, extend the >> comment >> for the same fix on the VT-x side. (I have a suspicion that I've just worked >> out why VT-x doesn't tolerate LMA != LME when Unrestricted Guest is clear.) >> >> Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/4] xen: introduce __symbol
On 17/10/2018 15:31, Stefano Stabellini wrote:
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids comparisons between pointers pointing to
different objects.
The C standard forbids for both comparisons and substraction (see C
Standard, 6.5.6 [ISO/IEC 9899:2011] and [1]). Also, it is probably worth
to give a pointer to the paragraph in the standard to help finding more
details.
Cheers,
[1]
https://wiki.sei.cmu.edu/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
_stext, _etext, etc. are all pointers to different
objects from ANCI C point of view.
To work around potential C compiler issues (which have actually
been found, see the comment on top of RELOC_HIDE in Linux), and to help
with certifications, let's introduce some syntactic sugar to be used in
following patches.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: wei.l...@citrix.com
---
Changes in v2:
- do not cast return to char*
- move to common header
---
xen/include/xen/compiler.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index ff6c0f5..850b0d0 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -99,6 +99,12 @@
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); })
+/*
+ * Use RELOC_HIDE with symbols such as _stext and _etext to avoid errors
+ * on comparing pointers to different objects
+ */
+#define __symbol(x) (RELOC_HIDE((unsigned long)(x), 0))
+
#ifdef __GCC_ASM_FLAG_OUTPUTS__
# define ASM_FLAG_OUT(yes, no) yes
#else
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 22/23] xen/arm: move kernel.h to asm-arm/
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > It will be #included by a file in a xen/arch/arm subdirectory.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/arch/arm/domain_build.c | 2 +-
> > xen/arch/arm/kernel.c| 3 +-
> > xen/arch/arm/kernel.h| 86
> >
> > xen/include/asm-arm/kernel.h | 86
> >
>
> There are way to make git diff nicer for code movement. This seems to be done
> by default on 2.11.0. Not sure for older version. What are you using?
Git version 1.9.1 (and guilt 0.35)
> > 4 files changed, 88 insertions(+), 89 deletions(-)
> > delete mode 100644 xen/arch/arm/kernel.h
> > create mode 100644 xen/include/asm-arm/kernel.h
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 4379538..dc9b46e 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -24,7 +25,6 @@
> > #include
> > #include
> > -#include "kernel.h"
> > static unsigned int __initdata opt_dom0_max_vcpus;
> > integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index 2239a07..b56aa79 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -16,8 +16,7 @@
> > #include
> > #include
> > -
> > -#include "kernel.h"
> > +#include
> > #define UIMAGE_MAGIC 0x27051956
> > #define UIMAGE_NMLEN 32
> > diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> > deleted file mode 100644
> > index 33f3e72..000
> > --- a/xen/arch/arm/kernel.h
> > +++ /dev/null
> > @@ -1,86 +0,0 @@
> > -/*
> > - * Kernel image loading.
> > - *
> > - * Copyright (C) 2011 Citrix Systems, Inc.
> > - */
> > -#ifndef __ARCH_ARM_KERNEL_H__
> > -#define __ARCH_ARM_KERNEL_H__
> > -
> > -#include
> > -#include
> > -
> > -struct kernel_info {
> > -#ifdef CONFIG_ARM_64
> > -enum domain_type type;
> > -#endif
> > -
> > -struct domain *d;
> > -
> > -void *fdt; /* flat device tree */
> > -paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
> > -struct meminfo mem;
> > -
> > -/* kernel entry point */
> > -paddr_t entry;
> > -
> > -/* grant table region */
> > -paddr_t gnttab_start;
> > -paddr_t gnttab_size;
> > -
> > -/* boot blob load addresses */
> > -const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
> > -const char* cmdline;
> > -paddr_t dtb_paddr;
> > -paddr_t initrd_paddr;
> > -
> > -/* Enable pl011 emulation */
> > -bool vpl011;
> > -
> > -/* loader to use for this kernel */
> > -void (*load)(struct kernel_info *info);
> > -/* loader specific state */
> > -union {
> > -struct {
> > -paddr_t kernel_addr;
> > -paddr_t len;
> > -#ifdef CONFIG_ARM_64
> > -paddr_t text_offset; /* 64-bit Image only */
> > -#endif
> > -paddr_t start; /* 32-bit zImage only */
> > -} zimage;
> > -};
> > -};
> > -
> > -/*
> > - * Probe the kernel to detemine its type and select a loader.
> > - *
> > - * Sets in info:
> > - * ->type
> > - * ->load hook, and sets loader specific variables ->zimage
> > - */
> > -int kernel_probe(struct kernel_info *info, const struct dt_device_node
> > *domain);
> > -
> > -/*
> > - * Loads the kernel into guest RAM.
> > - *
> > - * Expects to be set in info when called:
> > - * ->mem
> > - * ->fdt
> > - *
> > - * Sets in info:
> > - * ->entry
> > - * ->dtb_paddr
> > - * ->initrd_paddr
> > - */
> > -void kernel_load(struct kernel_info *info);
> > -
> > -#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
> > -
> > -/*
> > - * Local variables:
> > - * mode: C
> > - * c-file-style: "BSD"
> > - * c-basic-offset: 4
> > - * indent-tabs-mode: nil
> > - * End:
> > - */
> > diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
> > new file mode 100644
> > index 000..33f3e72
> > --- /dev/null
> > +++ b/xen/include/asm-arm/kernel.h
> > @@ -0,0 +1,86 @@
> > +/*
> > + * Kernel image loading.
> > + *
> > + * Copyright (C) 2011 Citrix Systems, Inc.
> > + */
> > +#ifndef __ARCH_ARM_KERNEL_H__
> > +#define __ARCH_ARM_KERNEL_H__
> > +
> > +#include
> > +#include
> > +
> > +struct kernel_info {
> > +#ifdef CONFIG_ARM_64
> > +enum domain_type type;
> > +#endif
> > +
> > +struct domain *d;
> > +
> > +void *fdt; /* flat device tree */
> > +paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
> > +struct meminfo mem;
> > +
> > +/* kernel entry point */
> > +paddr_t entry;
> > +
> > +/* grant table region */
> > +paddr_t gnttab_start;
> > +paddr_t gnttab_size;
> > +
> > +/* boot blob load addresses */
> > +
Re: [Xen-devel] [PATCH v2 2/4] xen/arm: initialize access
On 17/10/2018 15:31, Stefano Stabellini wrote: Initialize variable *access before returning it back to the caller. It makes the code a bit nicer and it is a safety certification requirement. Same as previous patch. Signed-off-by: Stefano Stabellini CC: rcojoc...@bitdefender.com CC: Tamas K Lengyel --- Changes in v2: - improve comment - use p2m->default_access --- xen/arch/arm/mem_access.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c index ba4ec78..86f0882 100644 --- a/xen/arch/arm/mem_access.c +++ b/xen/arch/arm/mem_access.c @@ -47,6 +47,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn, }; ASSERT(p2m_is_locked(p2m)); +*access = p2m->default_access; /* If no setting was ever set, just return rwx. */ if ( !p2m->mem_access_enabled ) -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] xen/arm: initialize target
Hi,
On 17/10/2018 15:31, Stefano Stabellini wrote:
Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.
While I know why this is a certification requirement, it may not be the
case for other on the mailing list. Please write down at least the rule
number.
Also, it might also be good to start using a tag similar to coverity (I
am assuming the bug ID are uniq) for tracking what has been fixed.
Cheers,
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- improve comment
---
xen/arch/arm/vgic-v2.c | 2 +-
xen/arch/arm/vgic-v3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f6c11f1..0099fcf 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -379,6 +379,7 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
enum gic_sgi_mode sgi_mode;
struct sgi_target target;
+sgi_target_init();
irqmode = (sgir & GICD_SGI_TARGET_LIST_MASK) >>
GICD_SGI_TARGET_LIST_SHIFT;
virq = (sgir & GICD_SGI_INTID_MASK);
@@ -386,7 +387,6 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
switch ( irqmode )
{
case GICD_SGI_TARGET_LIST_VAL:
-sgi_target_init();
target.list = (sgir & GICD_SGI_TARGET_MASK) >> GICD_SGI_TARGET_SHIFT;
sgi_mode = SGI_TARGET_LIST;
break;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index efe824c..c14bcd8 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1474,6 +1474,7 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t
sgir)
enum gic_sgi_mode sgi_mode;
struct sgi_target target;
+sgi_target_init();
irqmode = (sgir >> ICH_SGI_IRQMODE_SHIFT) & ICH_SGI_IRQMODE_MASK;
virq = (sgir >> ICH_SGI_IRQ_SHIFT ) & ICH_SGI_IRQ_MASK;
@@ -1481,7 +1482,6 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
switch ( irqmode )
{
case ICH_SGI_TARGET_LIST:
-sgi_target_init();
/* We assume that only AFF1 is used in ICC_SGI1R_EL1. */
target.aff1 = (sgir >> ICH_SGI_AFFINITY_LEVEL(1)) & ICH_SGI_AFFx_MASK;
target.list = sgir & ICH_SGI_TARGETLIST_MASK;
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] xen/arm: initialize access
On 10/17/18 5:31 PM, Stefano Stabellini wrote: > Initialize variable *access before returning it back to the caller. > It makes the code a bit nicer and it is a safety certification > requirement. > > Signed-off-by: Stefano Stabellini > CC: rcojoc...@bitdefender.com > CC: Tamas K Lengyel Acked-by: Razvan Cojocaru Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 3/4] xen: introduce __symbol
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids comparisons between pointers pointing to
different objects. _stext, _etext, etc. are all pointers to different
objects from ANCI C point of view.
To work around potential C compiler issues (which have actually
been found, see the comment on top of RELOC_HIDE in Linux), and to help
with certifications, let's introduce some syntactic sugar to be used in
following patches.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
CC: wei.l...@citrix.com
---
Changes in v2:
- do not cast return to char*
- move to common header
---
xen/include/xen/compiler.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index ff6c0f5..850b0d0 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -99,6 +99,12 @@
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); })
+/*
+ * Use RELOC_HIDE with symbols such as _stext and _etext to avoid errors
+ * on comparing pointers to different objects
+ */
+#define __symbol(x) (RELOC_HIDE((unsigned long)(x), 0))
+
#ifdef __GCC_ASM_FLAG_OUTPUTS__
# define ASM_FLAG_OUT(yes, no) yes
#else
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 4/4] xen: use __symbol everywhere
Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
is only required when comparing pointers, but use it everywhere to avoid
confusion.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
Changes in v2:
- cast return of __symbol to char* when required
- define __pa as unsigned long in is_kernel* functions
---
xen/arch/arm/alternative.c | 6 +--
xen/arch/arm/arm32/livepatch.c | 2 +-
xen/arch/arm/arm64/livepatch.c | 2 +-
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/livepatch.c| 6 +--
xen/arch/arm/mm.c | 17
xen/arch/arm/setup.c| 8 ++--
xen/arch/x86/setup.c| 79 +++--
xen/arch/x86/tboot.c| 12 +++---
xen/arch/x86/x86_64/machine_kexec.c | 4 +-
xen/include/asm-arm/grant_table.h | 3 +-
xen/include/asm-arm/mm.h| 4 +-
xen/include/asm-x86/mm.h| 4 +-
xen/include/xen/kernel.h| 24 +--
14 files changed, 90 insertions(+), 83 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 52ed7ed..305b337 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -187,8 +187,8 @@ static int __apply_alternatives_multi_stop(void *unused)
{
int ret;
struct alt_region region;
-mfn_t xen_mfn = virt_to_mfn(_start);
-paddr_t xen_size = _end - _start;
+mfn_t xen_mfn = virt_to_mfn(__symbol(_start));
+paddr_t xen_size = __symbol(_end) - __symbol(_start);
unsigned int xen_order = get_order_from_bytes(xen_size);
void *xenmap;
@@ -206,7 +206,7 @@ static int __apply_alternatives_multi_stop(void *unused)
region.begin = __alt_instructions;
region.end = __alt_instructions_end;
-ret = __apply_alternatives(, xenmap - (void *)_start);
+ret = __apply_alternatives(, xenmap - (void *)__symbol(_start));
/* The patching is not expected to fail during boot. */
BUG_ON(ret != 0);
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a5..e71764c 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -56,7 +56,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
else
insn = 0xe1a0; /* mov r0, r0 */
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)__symbol(_start) + vmap_of_xen_text;
len = len / sizeof(uint32_t);
/* PATCH! */
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2247b92..4a31026 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -43,7 +43,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
/* Verified in livepatch_verify_distance. */
ASSERT(insn != AARCH64_BREAK_FAULT);
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)__symbol(_start) + vmap_of_xen_text;
len = len / sizeof(uint32_t);
/* PATCH! */
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f552154..40968d0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2090,7 +2090,7 @@ static void __init find_gnttab_region(struct domain *d,
* Only use the text section as it's always present and will contain
* enough space for a large grant table
*/
-kinfo->gnttab_start = __pa(_stext);
+kinfo->gnttab_start = __pa(__symbol(_stext));
kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
#ifdef CONFIG_ARM_32
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 279d52c..006dff8 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -26,8 +26,8 @@ int arch_livepatch_quiesce(void)
if ( vmap_of_xen_text )
return -EINVAL;
-text_mfn = virt_to_mfn(_start);
-text_order = get_order_from_bytes(_end - _start);
+text_mfn = virt_to_mfn(__symbol(_start));
+text_order = get_order_from_bytes(__symbol(_end) - __symbol(_start));
/*
* The text section is read-only. So re-map Xen to be able to patch
@@ -78,7 +78,7 @@ void arch_livepatch_revert(const struct livepatch_func *func)
uint32_t *new_ptr;
unsigned int len;
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)__symbol(_start) + vmap_of_xen_text;
len = livepatch_insn_len(func);
memcpy(new_ptr, func->opaque, len);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7a06a33..d9d3948 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -620,7 +620,7 @@ void __init setup_pagetables(unsigned long
boot_phys_offset, paddr_t xen_paddr)
int i;
/* Calculate virt-to-phys offset for the new location */
-phys_offset = xen_paddr - (unsigned long) _start;
[Xen-devel] [PATCH v2 2/4] xen/arm: initialize access
Initialize variable *access before returning it back to the caller. It makes the code a bit nicer and it is a safety certification requirement. Signed-off-by: Stefano Stabellini CC: rcojoc...@bitdefender.com CC: Tamas K Lengyel --- Changes in v2: - improve comment - use p2m->default_access --- xen/arch/arm/mem_access.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c index ba4ec78..86f0882 100644 --- a/xen/arch/arm/mem_access.c +++ b/xen/arch/arm/mem_access.c @@ -47,6 +47,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn, }; ASSERT(p2m_is_locked(p2m)); +*access = p2m->default_access; /* If no setting was ever set, just return rwx. */ if ( !p2m->mem_access_enabled ) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/4] xen/arm: initialize target
Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- improve comment
---
xen/arch/arm/vgic-v2.c | 2 +-
xen/arch/arm/vgic-v3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f6c11f1..0099fcf 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -379,6 +379,7 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
enum gic_sgi_mode sgi_mode;
struct sgi_target target;
+sgi_target_init();
irqmode = (sgir & GICD_SGI_TARGET_LIST_MASK) >> GICD_SGI_TARGET_LIST_SHIFT;
virq = (sgir & GICD_SGI_INTID_MASK);
@@ -386,7 +387,6 @@ static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
switch ( irqmode )
{
case GICD_SGI_TARGET_LIST_VAL:
-sgi_target_init();
target.list = (sgir & GICD_SGI_TARGET_MASK) >> GICD_SGI_TARGET_SHIFT;
sgi_mode = SGI_TARGET_LIST;
break;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index efe824c..c14bcd8 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1474,6 +1474,7 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t
sgir)
enum gic_sgi_mode sgi_mode;
struct sgi_target target;
+sgi_target_init();
irqmode = (sgir >> ICH_SGI_IRQMODE_SHIFT) & ICH_SGI_IRQMODE_MASK;
virq = (sgir >> ICH_SGI_IRQ_SHIFT ) & ICH_SGI_IRQ_MASK;
@@ -1481,7 +1482,6 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t
sgir)
switch ( irqmode )
{
case ICH_SGI_TARGET_LIST:
-sgi_target_init();
/* We assume that only AFF1 is used in ICC_SGI1R_EL1. */
target.aff1 = (sgir >> ICH_SGI_AFFINITY_LEVEL(1)) & ICH_SGI_AFFx_MASK;
target.list = sgir & ICH_SGI_TARGETLIST_MASK;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/4] misc safety certification fixes
Hi all, This short patch series fixes a few issues discovered by the safety certifications code scanner. The first two patches address simple variable initializations concerns. The third patch introduces a new macro that is used throughout the code in patch #4 to access _stext, _etext pointers and friends. Jan, Andrew, as you know my goal is to fix arm and common code. I think it would be best to do the same for the x86 code as well, but let me know if you think otherwise. Cheers, Stefano Stefano Stabellini (4): xen/arm: initialize target xen/arm: initialize access xen: introduce __symbol xen: use __symbol everywhere xen/arch/arm/alternative.c | 6 +-- xen/arch/arm/arm32/livepatch.c | 2 +- xen/arch/arm/arm64/livepatch.c | 2 +- xen/arch/arm/domain_build.c | 2 +- xen/arch/arm/livepatch.c| 6 +-- xen/arch/arm/mem_access.c | 1 + xen/arch/arm/mm.c | 17 xen/arch/arm/setup.c| 8 ++-- xen/arch/arm/vgic-v2.c | 2 +- xen/arch/arm/vgic-v3.c | 2 +- xen/arch/x86/setup.c| 79 +++-- xen/arch/x86/tboot.c| 12 +++--- xen/arch/x86/x86_64/machine_kexec.c | 4 +- xen/include/asm-arm/grant_table.h | 3 +- xen/include/asm-arm/mm.h| 4 +- xen/include/asm-x86/mm.h| 4 +- xen/include/xen/compiler.h | 6 +++ xen/include/xen/kernel.h| 24 +-- 18 files changed, 99 insertions(+), 85 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/6] xen/arm: zynqmp: eemi access control
Hi Stefano,
On 17/10/2018 15:03, Stefano Stabellini wrote:
On Tue, 16 Oct 2018, Julien Grall wrote:
Hi,
Sorry I forgot to answer to the rest of the e-mail.
On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
On 15/10/2018 08:25, Julien Grall wrote:
+ bool hwdom_access; /* HW domain gets access regardless. */
+};
+
+/*
+ * This table maps a node into a memory address.
+ * If a guest has access to the address, it has enough control
+ * over the node to grant it access to EEMI calls for that node.
+ */
+static const struct pm_access pm_node_access[] = {
[...]
+
+/*
+ * This table maps reset line IDs into a memory address.
+ * If a guest has access to the address, it has enough control
+ * over the affected node to grant it access to EEMI calls for
+ * resetting that node.
+ */
+#define XILPM_RESET_IDX(n) (n - XILPM_RESET_PCIE_CFG)
+static const struct pm_access pm_reset_access[] = {
[...]
+
+/*
+ * This table maps reset line IDs into a memory address.
+ * If a guest has access to the address, it has enough control
+ * over the affected node to grant it access to EEMI calls for
+ * resetting that node.
+ */
+static const struct {
+ paddr_t start;
+ paddr_t size;
+ uint32_t mask; /* Zero means no mask, i.e all bits. */
+ enum pm_node_id node;
+ bool hwdom_access;
+ bool readonly;
+} pm_mmio_access[] = {
Those 3 arrays contains a lot of hardcoded value. Can't any of this be
detected from the device-tree?
No, the information is not available on device tree unfortunately. >
I would be interested to know how this is going to work with upstream
Linux.
Do you hardcode all the values there as well?
Yes: the IDs are specified on an header file, see
include/linux/firmware/xlnx-zynqmp.h on the zynq/firmware branch of the
arm-soc tree. In addition to the IDs, we also have the memory addresses
in Xen to do the permission checks.
I am afraid this is not linux upstream. Can you point to the code in
Linus's
git or explain the state of the review?
It hasn't been pulled into Linux yet, I was told it has already been
reviewed and is queued in arm-soc for upstreaming at the next merge
window, which should be imminent.
Looking at that branch, I can see some DT bindings at least for the clock. I
also don't see any hardcoded value for device so far in that series. Is it
going to be sent separately?
If you look at include/linux/firmware/xlnx-zynqmp.h, you'll see some
hardcode values, specifically enum pm_api_id matches numerically the
enum by the same name this series introduces in
xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
I don't think we are talking the same things. I am talking about
pm_node_id/pm_node_reset (not pm_api_id). I don't see such code in Linux
at the moment and a bit surprised that no DT bindings will be used to
link the value with a device.
So my question stands, how Linux will use pm_node_id/pm_node_reset? Can
you point to code if that exists.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/6] xen/arm: zynqmp: eemi access control
On Tue, 16 Oct 2018, Julien Grall wrote:
> Hi,
>
> Sorry I forgot to answer to the rest of the e-mail.
>
> On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
> > On 15/10/2018 08:25, Julien Grall wrote:
> > > > > > + bool hwdom_access; /* HW domain gets access regardless. */
> > > > > > +};
> > > > > > +
> > > > > > +/*
> > > > > > + * This table maps a node into a memory address.
> > > > > > + * If a guest has access to the address, it has enough control
> > > > > > + * over the node to grant it access to EEMI calls for that node.
> > > > > > + */
> > > > > > +static const struct pm_access pm_node_access[] = {
> > > > >
> > > > > [...]
> > > > >
> > > > > > +
> > > > > > +/*
> > > > > > + * This table maps reset line IDs into a memory address.
> > > > > > + * If a guest has access to the address, it has enough control
> > > > > > + * over the affected node to grant it access to EEMI calls for
> > > > > > + * resetting that node.
> > > > > > + */
> > > > > > +#define XILPM_RESET_IDX(n) (n - XILPM_RESET_PCIE_CFG)
> > > > > > +static const struct pm_access pm_reset_access[] = {
> > > > >
> > > > > [...]
> > > > >
> > > > > > +
> > > > > > +/*
> > > > > > + * This table maps reset line IDs into a memory address.
> > > > > > + * If a guest has access to the address, it has enough control
> > > > > > + * over the affected node to grant it access to EEMI calls for
> > > > > > + * resetting that node.
> > > > > > + */
> > > > > > +static const struct {
> > > > > > + paddr_t start;
> > > > > > + paddr_t size;
> > > > > > + uint32_t mask; /* Zero means no mask, i.e all bits. */
> > > > > > + enum pm_node_id node;
> > > > > > + bool hwdom_access;
> > > > > > + bool readonly;
> > > > > > +} pm_mmio_access[] = {
> > > > >
> > > > > Those 3 arrays contains a lot of hardcoded value. Can't any of this be
> > > > > detected from the device-tree?
> > > >
> > > > No, the information is not available on device tree unfortunately. >
> > > >
> > > > > I would be interested to know how this is going to work with upstream
> > > > > Linux.
> > > > > Do you hardcode all the values there as well?
> > > >
> > > > Yes: the IDs are specified on an header file, see
> > > > include/linux/firmware/xlnx-zynqmp.h on the zynq/firmware branch of the
> > > > arm-soc tree. In addition to the IDs, we also have the memory addresses
> > > > in Xen to do the permission checks.
> > >
> > > I am afraid this is not linux upstream. Can you point to the code in
> > > Linus's
> > > git or explain the state of the review?
> >
> > It hasn't been pulled into Linux yet, I was told it has already been
> > reviewed and is queued in arm-soc for upstreaming at the next merge
> > window, which should be imminent.
>
> Looking at that branch, I can see some DT bindings at least for the clock. I
> also don't see any hardcoded value for device so far in that series. Is it
> going to be sent separately?
If you look at include/linux/firmware/xlnx-zynqmp.h, you'll see some
hardcode values, specifically enum pm_api_id matches numerically the
enum by the same name this series introduces in
xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> > > > > > +static bool pm_check_access(const struct pm_access *acl, struct
> > > > > > domain *d,
> > > > > > + uint32_t idx)
> > > > > > +{
> > > > > > + unsigned long mfn;
> > > > >
> > > > > mfn_t please. The code is not that nice but at least it add more
> > > > > safety
> > > > > in the
> > > > > code. Hopefully iommu_access_permitted will be converted to typesafe
> > > > > MFN
> > > > > soon.
> > > >
> > > > Yes, I can make this change without issues.
> > > >
> > > >
> > > > > > +
> > > > > > + if ( acl[idx].hwdom_access && is_hardware_domain(d) )
> > > > > > + return true;
> > > > > > +
> > > > > > + if ( !acl[idx].addr )
> > > > > > + return false;
> > > > > > +
> > > > > > + mfn = PFN_DOWN(acl[idx].addr);
> > > > >
> > > > > maddr_to_mfn(...);
> > > >
> > > > OK
> > > >
> > > >
> > > > > > + return iomem_access_permitted(d, mfn, mfn);
> > > > >
> > > > > Is the address something that a guest would be allowed to read/write
> > > > > directly?
> > > > > If not, then iomem_access_permitted(...) should not be used.
> > > >
> > > > Yes, the address would be something remapped to the guest using iomem.
> > >
> > > In the documentation at the beginning of the file you say that memory
> > > ranges
> > > are typically secure memory. So how a guest can access them directly?
> > >
> > > I probably need a bit more background here... What is the address
> > > correspond
> > > to at the end?
> >
> > The address corresponds to the MMIO region of the device. For instance,
> > MM_GEM0 is 0xff0b, which is the address of the network card. It is
> > accessible. The same goes for MM_CAN0, MM_TTC0, MM_SD0, and all the
> > others -- they are all accessible. These are the addresses used in this
> > check that should be remapped into
Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k
> -Original Message- > From: Andrew Cooper > Sent: 17 October 2018 14:24 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: George Dunlap ; Jan Beulich > ; Wei Liu > Subject: Re: [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order > to 4k > > On 16/10/18 15:41, Paul Durrant wrote: > > The P2M common code currently restricts the MMIO mapping order of any > > domain with IOMMU mappings, but that is not using shared tables, to 4k. > > This has been shown to have a huge performance cost when passing through > > a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the > guest > > boot time from ~20s to several minutes when iommu=no-sharept is > specified > > on the Xen command line. > > > > The limitation was added by commit c3c756bd "x86/p2m: use large pages > > for MMIO mappings" however the underlying implementations of p2m- > >set_entry > > for Intel and AMD are coded to cope with mapping orders higher than 4k, > > even though the IOMMU mapping function is itself currently limited to > 4k, > > so there is no real need to limit the order passed into the method. > > > > With this patch applied the VM boot time is restored to something > > reasonable. Not as fast as without iommu=no-sharept, but within a few > > seconds of it. > > > > NOTE: This patch takes the opportunity to shorten a couple of > 80 > > character lines in the code. > > > > Signed-off-by: Paul Durrant > > I'm afraid that it isn't needless. > > The fact that the underlying IOMMU functions can only work with 4k > pages, in combination with no -ERestart support, is precisely why you > must only ever pass a 4k order here. Otherwise we will genuinely wait > for the IOMMU to map/unmap 1G worth of 4k pages at a time, which the > security team has previously deemed is too long to wait for a single > operation. > Ok, I agree that there may be an issue with 1G but not for 2M. I have tested the patch and, as I said in my comment, the total cost of the all the domctls was barely different from when page sharing was turned on. > I'm afraid that the only safe option I see here is to make the p2m > operations support properly preemptible. > That's a lot of re-work. I agree it is the correct solution but without a patch to allow at least 2M mapping, a system without shared tables is unusable so I think such a patch is reasonable stop-gap. Paul > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 4/6] xen/arm: zynqmp: eemi access control
On Tue, 16 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
> > On 15/10/2018 08:25, Julien Grall wrote:
> > > Hi,
> > >
> > > On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
> > > > On Tue, 28 Aug 2018, Julien Grall wrote:
> > > > > On 11/08/18 01:01, Stefano Stabellini wrote:
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > @@ -23,6 +91,721 @@
> > > > > > #include
> > > > > > #include
> > > > > > +struct pm_access
> > > > > > +{
> > > > > > + paddr_t addr;
> > > > >
> > > > > It seems that the address will always page-aligned. So could we store
> > > > > a
> > > > > frame
> > > > > using mfn_t?
> > > >
> > > > Yes we could store just the frame. I started to make the change
> > > > suggested, and all the required corresponding changes to the
> > > > initializations below, for instance:
> > > >
> > > > [NODE_RPU] = { MM_RPU },
> > > >
> > > > needs to become:
> > > >
> > > > [NODE_RPU] = { _mfn(MM_RPU) },
> > > >
> > > > but when I tried to do that, I get a compilation error:
> > > >
> > > > xilinx-zynqmp-eemi.c:106:20: error: initializer element is not
> > > > constant
> > > > [NODE_RPU] = { _mfn(MM_RPU) },
> > > >
> > > > Unfortunately it is not possible to use mfn_t in static initializations,
> > > > because it is a static inline. I could do:
> > > >
> > >
> > > This is a bug in GCC older than 5.0.
> > >
> > > > [NODE_RPU] = { { MM_RPU } },
> > > >
> > > > which would work for DEBUG builds but wouldn't work for non-DEBUG
> > > > builds.
> > > >
> > > > I'll keep paddr_t for the next version of the series.
> > >
> > > What is the issue with that on non-debug build? We are using this
> > > construction in another place without any compiler issue.
> >
> > I modified the code as suggested again and tried with newer GCCs (both
> > 6.3.1 and 7.3.1) but I still get the same error:
> >
> > xilinx-zynqmp-eemi.c:105:20: error: initializer element is not constant
> > [NODE_RPU] = { _mfn(MM_RPU) },
>
> I actually misremembered the problem. _mfn is using a static inline helper
> which is not considered as a constant.
>
> The correct solution would be (mfn_t){ MM_RPU } but GCC 5.0 (and older) does
> not parse correctly the type cast. So we workaround by dropping the cast for
> the initializer.
>
> On your previous e-mail you said that { { MM_RPU } } would not work for debug.
> One solution would be to introduce _mfn_initializer(...) that would be
> implemented differently for debug and non-debug.
>
> I think such helper would be useful in other context as well.
OK, I'll do that___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] xen/arm: initialize access
On Tue, 16 Oct 2018, Tamas K Lengyel wrote: > On Mon, Oct 15, 2018 at 7:14 PM Stefano Stabellini > wrote: > > > > On Mon, 15 Oct 2018, Tamas K Lengyel wrote: > > > On Mon, Oct 15, 2018 at 3:57 AM Stefano Stabellini > > > wrote: > > > > > > > > Initialize variable *access before returning it back to the caller. > > > > > > > > Signed-off-by: Stefano Stabellini > > > > --- > > > > xen/arch/arm/mem_access.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c > > > > index ba4ec78..10ab308 100644 > > > > --- a/xen/arch/arm/mem_access.c > > > > +++ b/xen/arch/arm/mem_access.c > > > > @@ -47,6 +47,7 @@ static int __p2m_get_mem_access(struct domain *d, > > > > gfn_t gfn, > > > > }; > > > > > > > > ASSERT(p2m_is_locked(p2m)); > > > > +*access = XENMEM_access_n; > > > > > > Why XENMEM_access_n and why set this at all here? > > > > Hi Tamas, > > > > Yes, I missed an explanation. Initializing variables before passing them > > as parameter or as a return value to a function is a safety > > certification requirement. Also, it makes the code a bit nicer. > > > > In the specific case of this function, *access is initialized before > > returning in all cases but the return -ESRCH case. I thought the nicer > > way to make sure *access is always initialized, making the code more > > robust, would be to initialize *access at the beginning of the function > > with a restrictive value. > > Got it, thanks, Please use p2m->default_access for this instead to be > consistent with similar code at other spots. OK, no prob ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] add myself as reviewer for Xen support in Linux
It would be good for me to keep an eye on the patches that touch Xen support in Linux to try to spot changes that break Xen on ARM early on. Signed-off-by: Stefano Stabellini diff --git a/MAINTAINERS b/MAINTAINERS index 40082e4..0c1984e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16013,6 +16013,7 @@ F: arch/arm64/include/asm/xen/ XEN HYPERVISOR INTERFACE M: Boris Ostrovsky M: Juergen Gross +R: Stefano Stabellini L: xen-devel@lists.xenproject.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git S: Supported ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation
On 10/5/18 2:00 PM, Razvan Cojocaru wrote: > On 9/27/18 2:25 PM, George Dunlap wrote: >> The name of the "with_gla" flag is confusing; it has nothing to do >> with the existence or lack thereof of a faulting GLA, but rather where >> the fault originated. The npfec.kind value is always valid, and >> should thus be propagated, regardless of whether gla_valid is set or >> not. >> >> In particular, gla_valid will never be set on AMD systems; but >> npfec.kind will still be valid and should still be propagated. >> >> Signed-off-by: Alexandru Isaila >> Signed-off-by: George Dunlap > > Acked-by: Razvan Cojocaru Does this also need Tamas' ack to go in? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86/altp2m: fix display frozen when switching to a new view early
On 10/17/18 4:30 PM, Andrew Cooper wrote: > On 17/10/18 14:26, Razvan Cojocaru wrote: >> On 10/4/18 6:20 PM, Jan Beulich wrote: >>> Roger recently has posted a patch adding rangeset_merge(), which I think >>> is more general than your rangeset_copy(). That said, I'm in no way >>> convinced copying (and then keeping in sync) the range sets across the >>> altp2m-s is the best approach. It may well be that the optimal solution is >>> somewhere in the middle between sharing everything and copying >>> everything. >> Would it be possible to get Roger's patch into staging? >> >> https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01331.html >> >> It looks simple enough and it has already acked by Wei. > > Looks good enough to me. Pushed. Thanks! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86/altp2m: fix display frozen when switching to a new view early
On 17/10/18 14:26, Razvan Cojocaru wrote: > On 10/4/18 6:20 PM, Jan Beulich wrote: >> Roger recently has posted a patch adding rangeset_merge(), which I think >> is more general than your rangeset_copy(). That said, I'm in no way >> convinced copying (and then keeping in sync) the range sets across the >> altp2m-s is the best approach. It may well be that the optimal solution is >> somewhere in the middle between sharing everything and copying >> everything. > Would it be possible to get Roger's patch into staging? > > https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01331.html > > It looks simple enough and it has already acked by Wei. Looks good enough to me. Pushed. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86/altp2m: fix display frozen when switching to a new view early
On 10/4/18 6:20 PM, Jan Beulich wrote: > Roger recently has posted a patch adding rangeset_merge(), which I think > is more general than your rangeset_copy(). That said, I'm in no way > convinced copying (and then keeping in sync) the range sets across the > altp2m-s is the best approach. It may well be that the optimal solution is > somewhere in the middle between sharing everything and copying > everything. Would it be possible to get Roger's patch into staging? https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01331.html It looks simple enough and it has already acked by Wei. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k
On 16/10/18 15:41, Paul Durrant wrote: > The P2M common code currently restricts the MMIO mapping order of any > domain with IOMMU mappings, but that is not using shared tables, to 4k. > This has been shown to have a huge performance cost when passing through > a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest > boot time from ~20s to several minutes when iommu=no-sharept is specified > on the Xen command line. > > The limitation was added by commit c3c756bd "x86/p2m: use large pages > for MMIO mappings" however the underlying implementations of p2m->set_entry > for Intel and AMD are coded to cope with mapping orders higher than 4k, > even though the IOMMU mapping function is itself currently limited to 4k, > so there is no real need to limit the order passed into the method. > > With this patch applied the VM boot time is restored to something > reasonable. Not as fast as without iommu=no-sharept, but within a few > seconds of it. > > NOTE: This patch takes the opportunity to shorten a couple of > 80 > character lines in the code. > > Signed-off-by: Paul Durrant I'm afraid that it isn't needless. The fact that the underlying IOMMU functions can only work with 4k pages, in combination with no -ERestart support, is precisely why you must only ever pass a 4k order here. Otherwise we will genuinely wait for the IOMMU to map/unmap 1G worth of 4k pages at a time, which the security team has previously deemed is too long to wait for a single operation. I'm afraid that the only safe option I see here is to make the p2m operations support properly preemptible. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/svm: Remove the pdpe fields from struct vmcb
These fields have existed since the SVM code was first introduced.
The earliest reference I can find is c/s d1bd157fbc9 which is unforunately a
rebase & squash of a separate dev tree. Looking a the commit message, I'm
guessing it was introduced by:
> user:twol...@xen-trw1.site
> date:Tue Dec 13 19:49:53 2005 -0500
> files: ... xen/include/asm-x86/svm_vmcb.h ...
> description:
> Add SVM base files to repository.
Anyway, the AMD SDM has no mention of PDPE fields in the VMCB and marks this
part of the VMCB as reserved. The manual does explicitly say that 32bit PAE
paging may read the PDPE fields from memory rather from the CPU registers.
Chances are very good that this is a vestigial remnent of an early design.
Xen doesn't use the fields at all, except to copy them on virtual
vmentry/vmexit.
Signed-off-by: Andrew Cooper
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/hvm/svm/nestedsvm.c | 12
xen/include/asm-x86/hvm/svm/vmcb.h | 7 ++-
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 3f4f403..78a1016 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -636,12 +636,6 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct
cpu_user_regs *regs)
* sysenter_eip. These are handled via VMSAVE/VMLOAD emulation.
*/
-/* Page tables */
-n2vmcb->pdpe0 = ns_vmcb->pdpe0;
-n2vmcb->pdpe1 = ns_vmcb->pdpe1;
-n2vmcb->pdpe2 = ns_vmcb->pdpe2;
-n2vmcb->pdpe3 = ns_vmcb->pdpe3;
-
/* PAT */
if (!vcleanbit_set(np)) {
n2vmcb->_g_pat = ns_vmcb->_g_pat;
@@ -1177,12 +1171,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct
cpu_user_regs *regs)
/* CR2 */
ns_vmcb->_cr2 = n2vmcb->_cr2;
-/* Page tables */
-ns_vmcb->pdpe0 = n2vmcb->pdpe0;
-ns_vmcb->pdpe1 = n2vmcb->pdpe1;
-ns_vmcb->pdpe2 = n2vmcb->pdpe2;
-ns_vmcb->pdpe3 = n2vmcb->pdpe3;
-
/* PAT */
ns_vmcb->_g_pat = n2vmcb->_g_pat;
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
b/xen/include/asm-x86/hvm/svm/vmcb.h
index 3a514f8..48aed78 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -479,17 +479,14 @@ struct vmcb_struct {
u64 sysenter_esp;
u64 sysenter_eip;
u64 _cr2; /* cleanbit 9 */
-u64 pdpe0;
-u64 pdpe1;
-u64 pdpe2;
-u64 pdpe3;
+u64 res16[4];
u64 _g_pat; /* cleanbit 4 */
u64 _debugctlmsr; /* cleanbit 10 */
u64 _lastbranchfromip; /* cleanbit 10 */
u64 _lastbranchtoip;/* cleanbit 10 */
u64 _lastintfromip; /* cleanbit 10 */
u64 _lastinttoip; /* cleanbit 10 */
-u64 res16[301];
+u64 res17[301];
};
struct svm_domain {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi, I have started finding which patch introduced Armv8 Secondary CPUs issue. I just want to start PV vdevb before domainU debian rootfs mount. Is it possible? Thanks, Omkar B On Mon, Oct 8, 2018 at 4:00 PM Julien Grall wrote: > > > On 08/10/2018 10:12, Omkar Bolla wrote: > > Hi, > > Hi, > > > This is also okay, but problem here is I am using 4.8 stable xen > > because it is working on Hkey960(ArmV8) > > This is because you can't bring up secondary CPUs on the Hikey with Xen > 4.11 [1], right? It would be nice to find where the bug was introduced > because Xen 4.8 is out of support and does not contain the latest fixes > (such as Meltdown/Spectre). > > > Is there any other way to share buffer dynamically? > You would have to write your own PV drivers or port the series to Xen 4.8. > > Cheers, > > [1] > https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg21576.html > > -- > Julien Grall > -- This message contains confidential information and is intended only for the individual(s) named. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this mail and attached file/s is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 128824: tolerable FAIL - PUSHED
flight 128824 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/128824/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128688 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128688 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128688 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128688 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128688 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-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 windows-install fail never pass version targeted for testing: qemuu046936ed7179cfa413dfb2668b03d7e684bb7dbd baseline version: qemuua73549f99612f758dec0fdea6ae1c30b6c709a0b Last test of basis 128688 2018-10-13 06:30:21 Z4 days Testing same since 128824 2018-10-15 13:37:03 Z1 days1 attempts People who touched revisions under test: Daniel P. Berrangé Gerd Hoffmann Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass
[Xen-devel] Ping AMD maintainers? [PATCH] x86/svm: Fix svm_update_guest_efer() for domains using shadow paging
On 05/10/18 18:02, Andrew Cooper wrote:
> When using shadow paging, EFER.NX is a Xen controlled bit, and is required by
> the shadow pagefault handler to distinguish instruction fetches from data
> accesses.
>
> This can be observed by a guest which has NX and SMEP clear but SMAP active by
> attempting to execute code on a user mapping. The first attempt to build the
> target shadow will #PF so is handled by the shadow code, but when walking the
> the guest pagetables, the lack of PFEC_insn_fetch being signalled causes the
> shadow code to mistake the instruction fetch for a data fetch, and believe
> that it is a real guest fault. As a result, the guest receives #PF[-d-srP]
> for an action which should complete successfully.
>
> The suspicious-looking gymnastics with LME is actually a subtle corner case
> with shadow paging. When dropping out of Long Mode, a guests choice of LME
> and Xen's choice of CR0.PG cause hardware to operate in Long Mode, but the
> shadow code to operate in 2-on-3 mode.
>
> In addition to describing this corner case in the SVM side, extend the comment
> for the same fix on the VT-x side. (I have a suspicion that I've just worked
> out why VT-x doesn't tolerate LMA != LME when Unrestricted Guest is clear.)
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Tim Deegan
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
> CC: Jun Nakajima
> CC: Kevin Tian
>
> Unlike the VT-x side, there is no point playing with the conditional intercept
> of EFER reads. The SVME requirement means that only L1 hypervisors would
> benefit from accelerated reads.
> ---
> xen/arch/x86/hvm/svm/svm.c | 31 +--
> xen/arch/x86/hvm/vmx/vmx.c | 6 ++
> 2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index c98cfc2..2ab2c54 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -649,13 +649,32 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int
> cr, unsigned int flags)
> static void svm_update_guest_efer(struct vcpu *v)
> {
> struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
> -bool lma = v->arch.hvm.guest_efer & EFER_LMA;
> -uint64_t new_efer;
> +unsigned long guest_efer = v->arch.hvm.guest_efer,
> +xen_efer = read_efer();
>
> -new_efer = (v->arch.hvm.guest_efer | EFER_SVME) & ~EFER_LME;
> -if ( lma )
> -new_efer |= EFER_LME;
> -vmcb_set_efer(vmcb, new_efer);
> +if ( paging_mode_shadow(v->domain) )
> +{
> +/* EFER.NX is a Xen-owned bit and is not under guest control. */
> +guest_efer &= ~EFER_NX;
> +guest_efer |= xen_efer & EFER_NX;
> +
> +/*
> + * CR0.PG is a Xen-owned bit, and remains set even when the guest has
> + * logically disabled paging.
> + *
> + * LMA was calculated using the guest CR0.PG setting, but LME needs
> + * clearing to avoid interacting with Xen's CR0.PG setting. As
> writes
> + * to CR0 are intercepted, it is safe to leave LME clear at this
> + * point, and fix up both LME and LMA when CR0.PG is set.
> + */
> +if ( !(guest_efer & EFER_LMA) )
> +guest_efer &= ~EFER_LME;
> +}
> +
> +/* SVME must remain set in non-root mode. */
> +guest_efer |= EFER_SVME;
> +
> +vmcb_set_efer(vmcb, guest_efer);
>
> ASSERT(nestedhvm_enabled(v->domain) ||
> !(v->arch.hvm.guest_efer & EFER_SVME));
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index bf90e22..eea6330 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1666,6 +1666,12 @@ static void vmx_update_guest_efer(struct vcpu *v)
> * not tolerate the LME and LMA settings being different. As writes
> * to CR0 are intercepted, it is safe to leave LME clear at this
> * point, and fix up both LME and LMA when CR0.PG is set.
> + *
> + * Furthermore, when using shadow pagetables (subsumed by the
> + * Unrestricted Guest check), CR0.PG is a Xen-owned bit, and remains
> + * set even when the guest has logically disabled paging. LMA was
> + * calculated using the guest CR0.PG setting, but LME needs clearing
> + * to avoid interacting with Xen's CR0.PG setting.
> */
> if ( !(guest_efer & EFER_LMA) )
> guest_efer &= ~EFER_LME;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()
> -Original Message-
> From: Andrew Cooper
> Sent: 17 October 2018 12:20
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Jun Nakajima ; Kevin Tian
>
> Subject: Re: [PATCH] iommu / p2m: add a page_order parameter to
> iommu_map/unmap_page()
>
> On 17/10/18 09:19, Paul Durrant wrote:
> > diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> > index 55df18501e..b264a97bd8 100644
> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t
> gfn_, mfn_t mfn,
> > {
> > ASSERT(rc == 0);
> >
> > -if ( iommu_use_hap_pt(p2m->domain) )
> > -{
> > -if ( iommu_old_flags )
> > -amd_iommu_flush_pages(p2m->domain, gfn, page_order);
> > -}
> > -else if ( need_iommu_pt_sync(p2m->domain) )
> > -{
> > -dfn_t dfn = _dfn(gfn);
> > -
> > -if ( iommu_pte_flags )
> > -for ( i = 0; i < (1UL << page_order); i++ )
> > -{
> > -rc = iommu_map_page(p2m->domain, dfn_add(dfn, i),
> > -mfn_add(mfn, i),
> iommu_pte_flags);
> > -if ( unlikely(rc) )
> > -{
> > -while ( i-- )
> > -/* If statement to satisfy __must_check. */
> > -if ( iommu_unmap_page(p2m->domain,
> > - dfn_add(dfn, i)) )
> > -continue;
> > -
> > -break;
> > -}
> > -}
> > -else
> > -for ( i = 0; i < (1UL << page_order); i++ )
> > -{
> > -int ret = iommu_unmap_page(p2m->domain,
> > - dfn_add(dfn, i));
> > -
> > -if ( !rc )
> > -rc = ret;
> > -}
> > -}
> > +if ( need_iommu_pt_sync(p2m->domain) )
> > +rc = iommu_pte_flags ?
> > +iommu_map_page(d, _dfn(gfn), mfn, page_order,
> > + iommu_pte_flags) :
> > +iommu_unmap_page(d, _dfn(gfn), page_order);
> > +else if ( iommu_use_hap_pt(d) && iommu_old_flags )
> > +amd_iommu_flush_pages(p2m->domain, gfn, page_order);
>
> This logically reverses the
> iommu_use_hap_pt(d)/need_iommu_pt_sync(p2m->domain) conditions.
Yes it does, but I think this I ok as they will never both be true at the same
time. Doing it this way allowed me to get rid of the nested if.
>
> I'd be tempted confine this change to the else if (
> need_iommu_pt_sync(p2m->domain) ) block.
>
>
> Tangentially related, calling amd_iommu_flush_pages() is a laying
> violation here because this is supposedly common code. In reality, it
> is the NPT code, so might perhaps be better named as p2m-npt.c. George?
>
The boilerplate says:
/**
* arch/x86/mm/p2m-pt.c
*
* Implementation of p2m datastructures as pagetables, for use by
* NPT and shadow-pagetable code
*
so calling AMD IOMMU functions is not really a layering violation.
> > }
> >
> > /*
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index f1df1debc7..3fa559da01 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -718,24 +718,8 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned
> long gfn_l, unsigned long mfn,
> > p2m_access_t a;
> >
> > if ( !paging_mode_translate(p2m->domain) )
> > -{
> > -int rc = 0;
> > -
> > -if ( need_iommu_pt_sync(p2m->domain) )
> > -{
> > -dfn_t dfn = _dfn(mfn);
> > -
> > -for ( i = 0; i < (1 << page_order); i++ )
> > -{
> > -int ret = iommu_unmap_page(p2m->domain, dfn_add(dfn,
> i));
> > -
> > -if ( !rc )
> > -rc = ret;
> > -}
> > -}
> > -
> > -return rc;
> > -}
> > +return need_iommu_pt_sync(p2m->domain) ?
> > +iommu_unmap_page(p2m->domain, _dfn(mfn), page_order) : 0;
>
> TBH, I think this is harder to read than the non ternary alternative.
>
Ok. I'm not fussed either way.
> >
> > ASSERT(gfn_locked_by_me(p2m, gfn));
> > P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_l, mfn);
> > diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> > index 8b438ae4bc..40db9e7849 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -305,50 +305,71 @@ void iommu_domain_destroy(struct domain *d)
> > }
> >
> > int iommu_map_page(struct
Re: [Xen-devel] [PATCH] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()
On 17/10/18 09:19, Paul Durrant wrote:
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 55df18501e..b264a97bd8 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
> mfn_t mfn,
> {
> ASSERT(rc == 0);
>
> -if ( iommu_use_hap_pt(p2m->domain) )
> -{
> -if ( iommu_old_flags )
> -amd_iommu_flush_pages(p2m->domain, gfn, page_order);
> -}
> -else if ( need_iommu_pt_sync(p2m->domain) )
> -{
> -dfn_t dfn = _dfn(gfn);
> -
> -if ( iommu_pte_flags )
> -for ( i = 0; i < (1UL << page_order); i++ )
> -{
> -rc = iommu_map_page(p2m->domain, dfn_add(dfn, i),
> -mfn_add(mfn, i), iommu_pte_flags);
> -if ( unlikely(rc) )
> -{
> -while ( i-- )
> -/* If statement to satisfy __must_check. */
> -if ( iommu_unmap_page(p2m->domain,
> - dfn_add(dfn, i)) )
> -continue;
> -
> -break;
> -}
> -}
> -else
> -for ( i = 0; i < (1UL << page_order); i++ )
> -{
> -int ret = iommu_unmap_page(p2m->domain,
> - dfn_add(dfn, i));
> -
> -if ( !rc )
> -rc = ret;
> -}
> -}
> +if ( need_iommu_pt_sync(p2m->domain) )
> +rc = iommu_pte_flags ?
> +iommu_map_page(d, _dfn(gfn), mfn, page_order,
> + iommu_pte_flags) :
> +iommu_unmap_page(d, _dfn(gfn), page_order);
> +else if ( iommu_use_hap_pt(d) && iommu_old_flags )
> +amd_iommu_flush_pages(p2m->domain, gfn, page_order);
This logically reverses the
iommu_use_hap_pt(d)/need_iommu_pt_sync(p2m->domain) conditions.
I'd be tempted confine this change to the else if (
need_iommu_pt_sync(p2m->domain) ) block.
Tangentially related, calling amd_iommu_flush_pages() is a laying
violation here because this is supposedly common code. In reality, it
is the NPT code, so might perhaps be better named as p2m-npt.c. George?
> }
>
> /*
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index f1df1debc7..3fa559da01 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -718,24 +718,8 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned long
> gfn_l, unsigned long mfn,
> p2m_access_t a;
>
> if ( !paging_mode_translate(p2m->domain) )
> -{
> -int rc = 0;
> -
> -if ( need_iommu_pt_sync(p2m->domain) )
> -{
> -dfn_t dfn = _dfn(mfn);
> -
> -for ( i = 0; i < (1 << page_order); i++ )
> -{
> -int ret = iommu_unmap_page(p2m->domain, dfn_add(dfn, i));
> -
> -if ( !rc )
> -rc = ret;
> -}
> -}
> -
> -return rc;
> -}
> +return need_iommu_pt_sync(p2m->domain) ?
> +iommu_unmap_page(p2m->domain, _dfn(mfn), page_order) : 0;
TBH, I think this is harder to read than the non ternary alternative.
>
> ASSERT(gfn_locked_by_me(p2m, gfn));
> P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_l, mfn);
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 8b438ae4bc..40db9e7849 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -305,50 +305,71 @@ void iommu_domain_destroy(struct domain *d)
> }
>
> int iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
> - unsigned int flags)
> + unsigned int page_order, unsigned int flags)
> {
> const struct domain_iommu *hd = dom_iommu(d);
> -int rc;
> +unsigned long i;
>
> if ( !iommu_enabled || !hd->platform_ops )
> return 0;
>
> -rc = hd->platform_ops->map_page(d, dfn, mfn, flags);
> -if ( unlikely(rc) )
> +for ( i = 0; i < (1ul << page_order); i++ )
> {
> -if ( !d->is_shutting_down && printk_ratelimit() )
> -printk(XENLOG_ERR
> - "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn"
> failed: %d\n",
> - d->domain_id, dfn_x(dfn), mfn_x(mfn), rc);
> +int ignored, rc = hd->platform_ops->map_page(d, dfn_add(dfn, i),
> + mfn_add(mfn, i),
> + flags);
>
> -if ( !is_hardware_domain(d) )
> -domain_crash(d);
> +if ( unlikely(rc) )
> +{
> +while (i--)
Spaces, but
Re: [Xen-devel] [PATCH v2] arch/x86: Add registers to vm_event
On 17/10/18 12:11, Alexandru Stefan ISAILA wrote:
>
>>> +uint16_t sel;
>>> +union
>>> +{
>>> +uint64_t bytes;
>>> +struct
>>> +{
>>> +uint64_t base :32;
>> Better known as... ?
> Sorry I don't follow here
An aligned 32-bit bitfield of a uin64_t is more commonly known as uint32_t.
:)
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] arch/x86: Add registers to vm_event
On 17.10.2018 12:49, Andrew Cooper wrote:
> On 17/10/18 10:39, Alexandru Stefan ISAILA wrote:
>> This patch adds a couple of regs to the vm_event that are used by
>> the introspection. The base, limit and ar
>> bits are compressed into a uint64_t union so as not to enlarge the
>> vm_event.
>>
>> Signed-off-by: Alexandru Isaila
>>
>> ---
>> Changes since V1:
>> - Add helper function for packing
>> - Change packing logic
>> - Add sel to x86_selector_reg.
>> ---
>> xen/arch/x86/vm_event.c | 30 ++
>> xen/include/public/vm_event.h | 26 ++
>> 2 files changed, 44 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
>> index 15de43c3e6..3a29441c84 100644
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -122,11 +122,25 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
>> v->arch.monitor.next_interrupt_enabled = true;
>> }
>>
>> +static void vm_event_pack_segment_register(enum x86_segment segment,
>> + struct x86_selector_reg *reg)
>> +{
>> +struct segment_register seg;
>> +
>> +hvm_get_segment_register(current, segment, );
>> +reg->fields.base = seg.base;
>> +if ( seg.g )
>> +reg->fields.limit = seg.limit >> 12;
>> +else
>> +reg->fields.limit = seg.limit;
>
> I know I suggested this, but how about
>
> reg->fields.limit = seg.g ? seg.limit >> 12 : seg.limit;
>
> which is rather shorter, and probably easier to read.
OK, I will revise this on the next version
>
>> +reg->fields.ar = seg.attr;
>> +reg->sel = seg.sel;
>> +}
>> +
>> void vm_event_fill_regs(vm_event_request_t *req)
>> {
>> #ifdef CONFIG_HVM
>> const struct cpu_user_regs *regs = guest_cpu_user_regs();
>> -struct segment_register seg;
>> struct hvm_hw_cpu ctxt = {};
>> struct vcpu *curr = current;
>>
>> @@ -170,14 +184,14 @@ void vm_event_fill_regs(vm_event_request_t *req)
>> req->data.regs.x86.msr_star = ctxt.msr_star;
>> req->data.regs.x86.msr_lstar = ctxt.msr_lstar;
>>
>> -hvm_get_segment_register(curr, x86_seg_fs, );
>> -req->data.regs.x86.fs_base = seg.base;
>> -
>> -hvm_get_segment_register(curr, x86_seg_gs, );
>> -req->data.regs.x86.gs_base = seg.base;
>> +vm_event_pack_segment_register(x86_seg_fs, >data.regs.x86.fs);
>> +vm_event_pack_segment_register(x86_seg_gs, >data.regs.x86.gs);
>> +vm_event_pack_segment_register(x86_seg_cs, >data.regs.x86.cs);
>> +vm_event_pack_segment_register(x86_seg_ss, >data.regs.x86.ss);
>> +vm_event_pack_segment_register(x86_seg_ds, >data.regs.x86.ds);
>> +vm_event_pack_segment_register(x86_seg_es, >data.regs.x86.es);
>>
>> -hvm_get_segment_register(curr, x86_seg_cs, );
>> -req->data.regs.x86.cs_arbytes = seg.attr;
>> +req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
>> #endif
>> }
>>
>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
>> index 36e3f4685d..705e6f8a1c 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -29,7 +29,7 @@
>>
>> #include "xen.h"
>>
>> -#define VM_EVENT_INTERFACE_VERSION 0x0003
>> +#define VM_EVENT_INTERFACE_VERSION 0x0004
>>
>> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>>
>> @@ -157,6 +157,20 @@
>> #define VM_EVENT_X86_CR42
>> #define VM_EVENT_X86_XCR0 3
>>
>> +struct __attribute__((__packed__)) x86_selector_reg {
>
> This is a poor choice of name, because you are mixing two different
> pieces of information.
>
> sel is a selector value, whereas the union is a segment descriptor
> (architecturally speaking).
I will take sel out of the structure
>
>> +uint16_t sel;
>> +union
>> +{
>> +uint64_t bytes;
>> +struct
>> +{
>> +uint64_t base :32;
>
> Better known as... ?
Sorry I don't follow here
>
>> +uint64_t limit :20;
>> +uint64_t ar :12;
>> +} fields;
>> +};
>> +};
>> +
>> /*
>>* Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
>>* so as to not fill the vm_event ring buffer too quickly.
>> @@ -191,9 +205,13 @@ struct vm_event_regs_x86 {
>> uint64_t msr_efer;
>> uint64_t msr_star;
>> uint64_t msr_lstar;
>> -uint64_t fs_base;
>> -uint64_t gs_base;
>
> What's happened with fs_base and gs_base? You've replaced them with
> uint32_t's in x86_selector_reg, but they are 64bit fields in Long mode.
>
> ~Andrew
I will put fs_base and gs_base back in with 64bit
Alex
>
>> -uint32_t cs_arbytes;
>> +struct x86_selector_reg cs;
>> +struct x86_selector_reg ss;
>> +struct x86_selector_reg ds;
>> +struct x86_selector_reg es;
>> +struct x86_selector_reg fs;
>> +struct x86_selector_reg gs;
>> +uint64_t shadow_gs;
>> uint32_t _pad;
>> };
>>
>
[Xen-devel] [ovmf baseline-only test] 75437: trouble: blocked/broken
This run is configured for baseline tests only. flight 75437 ovmf real [real] http://osstest.xensource.com/osstest/logs/75437/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 4 host-install(4) broken baseline untested build-i3864 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested version targeted for testing: ovmf 25d310d9b6187ca2e770b0b959831416441ce271 baseline version: ovmf 6d665168b0b630924a8d535316d053723998d658 Last test of basis75433 2018-10-16 16:20:32 Z0 days Testing same since75437 2018-10-17 06:20:33 Z0 days1 attempts People who touched revisions under test: Hao Wu Ruiyu Ni Wonkyu Kim jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-amd64 host-install(4) broken-step build-i386 host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-amd64-xsm host-install(4) broken-step build-i386-xsm host-install(4) broken-step build-amd64-pvops host-install(4) Push not applicable. commit 25d310d9b6187ca2e770b0b959831416441ce271 Author: Ruiyu Ni Date: Tue Oct 16 12:40:13 2018 +0800 MdeModulePkg/UsbMass: Reject device whose block size is 0 or > 64K Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Star Zeng Reviewed-by: Star Zeng commit 8894c90d745109c4aea3998c09a8f2b1f10a6d04 Author: Hao Wu Date: Thu Sep 20 13:48:02 2018 +0800 MdeModulePkg/Bus/Ufs: Ensure device not return more data than expected This commit adds checks to make sure the UFS devices do not return more data than the driver expected. Cc: Ruiyu Ni Cc: Jiewen Yao Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu Reviewed-by: Star Zeng commit b2252bab12deeb0f5981cf390dc6499d1689b4a2 Author: Ruiyu Ni Date: Mon Sep 17 16:05:26 2018 +0800 MdeModulePkg/UsbBus: Deny when the string descriptor length is odd Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Jiewen Yao Cc: Star Zeng Reviewed-by: Star Zeng commit 6c46cbbd5e3e2db7f14c007482e062b90c73c70f Author: Ruiyu Ni Date: Thu Sep 13 16:09:10 2018 +0800 MdeModulePkg/UsbMouse: Don't access key codes when length is wrong Per USB HID spec, the buffer holding key codes should at least 3-byte long. Today's code assumes that the key codes buffer length is longer than 3-byte and unconditionally
Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> From those two options I'd prefer multiple xenstore keys as much
> cleaner. We do have them as an array in libxl already.
>
> So, let image/dmargs be actually a directory with entries like:
> - image/dmargs/000 = -xen-domid
> - image/dmargs/001 = 123
> - image/dmargs/002 = -nodefaults
>
> I wonder if there needs to be arguments count, or iterating until ENOENT
> is enough?
xenstore-read doesn't seem to provide an easy way for a shell script
to tell ENOENT apart from "everything is doomed". Here is its
(frankly, very poor) error handling:
char *val = xs_read(xsh, xth, argv[optind], );
if (val == NULL) {
warnx("couldn't read path %s", argv[optind]);
return 1;
}
It doesn't even print the errno value, let alone change the exit
status or provide a way to tolerate ENOENT without bulrbing to stderr.
If I were you I'd send a shell string but it's entirely up to you.
> > Yes. Or teaching qemu about libvchan.
>
> That's also an option. I'll see how hard it would be to add this to
> qemu.
Good luck.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] arch/x86: Add registers to vm_event
On 17/10/18 10:39, Alexandru Stefan ISAILA wrote:
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes since V1:
> - Add helper function for packing
> - Change packing logic
> - Add sel to x86_selector_reg.
> ---
> xen/arch/x86/vm_event.c | 30 ++
> xen/include/public/vm_event.h | 26 ++
> 2 files changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index 15de43c3e6..3a29441c84 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -122,11 +122,25 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
> v->arch.monitor.next_interrupt_enabled = true;
> }
>
> +static void vm_event_pack_segment_register(enum x86_segment segment,
> + struct x86_selector_reg *reg)
> +{
> +struct segment_register seg;
> +
> +hvm_get_segment_register(current, segment, );
> +reg->fields.base = seg.base;
> +if ( seg.g )
> +reg->fields.limit = seg.limit >> 12;
> +else
> +reg->fields.limit = seg.limit;
I know I suggested this, but how about
reg->fields.limit = seg.g ? seg.limit >> 12 : seg.limit;
which is rather shorter, and probably easier to read.
> +reg->fields.ar = seg.attr;
> +reg->sel = seg.sel;
> +}
> +
> void vm_event_fill_regs(vm_event_request_t *req)
> {
> #ifdef CONFIG_HVM
> const struct cpu_user_regs *regs = guest_cpu_user_regs();
> -struct segment_register seg;
> struct hvm_hw_cpu ctxt = {};
> struct vcpu *curr = current;
>
> @@ -170,14 +184,14 @@ void vm_event_fill_regs(vm_event_request_t *req)
> req->data.regs.x86.msr_star = ctxt.msr_star;
> req->data.regs.x86.msr_lstar = ctxt.msr_lstar;
>
> -hvm_get_segment_register(curr, x86_seg_fs, );
> -req->data.regs.x86.fs_base = seg.base;
> -
> -hvm_get_segment_register(curr, x86_seg_gs, );
> -req->data.regs.x86.gs_base = seg.base;
> +vm_event_pack_segment_register(x86_seg_fs, >data.regs.x86.fs);
> +vm_event_pack_segment_register(x86_seg_gs, >data.regs.x86.gs);
> +vm_event_pack_segment_register(x86_seg_cs, >data.regs.x86.cs);
> +vm_event_pack_segment_register(x86_seg_ss, >data.regs.x86.ss);
> +vm_event_pack_segment_register(x86_seg_ds, >data.regs.x86.ds);
> +vm_event_pack_segment_register(x86_seg_es, >data.regs.x86.es);
>
> -hvm_get_segment_register(curr, x86_seg_cs, );
> -req->data.regs.x86.cs_arbytes = seg.attr;
> +req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
> #endif
> }
>
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 36e3f4685d..705e6f8a1c 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -29,7 +29,7 @@
>
> #include "xen.h"
>
> -#define VM_EVENT_INTERFACE_VERSION 0x0003
> +#define VM_EVENT_INTERFACE_VERSION 0x0004
>
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
>
> @@ -157,6 +157,20 @@
> #define VM_EVENT_X86_CR42
> #define VM_EVENT_X86_XCR0 3
>
> +struct __attribute__((__packed__)) x86_selector_reg {
This is a poor choice of name, because you are mixing two different
pieces of information.
sel is a selector value, whereas the union is a segment descriptor
(architecturally speaking).
> +uint16_t sel;
> +union
> +{
> +uint64_t bytes;
> +struct
> +{
> +uint64_t base :32;
Better known as... ?
> +uint64_t limit :20;
> +uint64_t ar :12;
> +} fields;
> +};
> +};
> +
> /*
> * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
> * so as to not fill the vm_event ring buffer too quickly.
> @@ -191,9 +205,13 @@ struct vm_event_regs_x86 {
> uint64_t msr_efer;
> uint64_t msr_star;
> uint64_t msr_lstar;
> -uint64_t fs_base;
> -uint64_t gs_base;
What's happened with fs_base and gs_base? You've replaced them with
uint32_t's in x86_selector_reg, but they are 64bit fields in Long mode.
~Andrew
> -uint32_t cs_arbytes;
> +struct x86_selector_reg cs;
> +struct x86_selector_reg ss;
> +struct x86_selector_reg ds;
> +struct x86_selector_reg es;
> +struct x86_selector_reg fs;
> +struct x86_selector_reg gs;
> +uint64_t shadow_gs;
> uint32_t _pad;
> };
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 128849: all pass - PUSHED
flight 128849 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/128849/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 7559ab7830c3e1594cd73efd3f1acbb171036728 baseline version: xen 92666fdd6e0afab989b2d89759d9b43f2c645ae7 Last test of basis 128730 2018-10-14 09:18:20 Z3 days Testing same since 128849 2018-10-17 09:18:51 Z0 days1 attempts People who touched revisions under test: Adrian Pop Andrew Cooper Daniel De Graaf Elena Ufimtseva Ian Jackson Ian Jackson Jan Beulich Paul Durrant Razvan Cojocaru Roger Pau Monne Roger Pau Monné Tamas K Lengyel Tim Deegan Wei Liu Xin Li Xin Li jobs: coverity-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/xen.git 92666fdd6e..7559ab7830 7559ab7830c3e1594cd73efd3f1acbb171036728 -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] arch/x86: Add registers to vm_event
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
Changes since V1:
- Add helper function for packing
- Change packing logic
- Add sel to x86_selector_reg.
---
xen/arch/x86/vm_event.c | 30 ++
xen/include/public/vm_event.h | 26 ++
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 15de43c3e6..3a29441c84 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -122,11 +122,25 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
v->arch.monitor.next_interrupt_enabled = true;
}
+static void vm_event_pack_segment_register(enum x86_segment segment,
+ struct x86_selector_reg *reg)
+{
+struct segment_register seg;
+
+hvm_get_segment_register(current, segment, );
+reg->fields.base = seg.base;
+if ( seg.g )
+reg->fields.limit = seg.limit >> 12;
+else
+reg->fields.limit = seg.limit;
+reg->fields.ar = seg.attr;
+reg->sel = seg.sel;
+}
+
void vm_event_fill_regs(vm_event_request_t *req)
{
#ifdef CONFIG_HVM
const struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct segment_register seg;
struct hvm_hw_cpu ctxt = {};
struct vcpu *curr = current;
@@ -170,14 +184,14 @@ void vm_event_fill_regs(vm_event_request_t *req)
req->data.regs.x86.msr_star = ctxt.msr_star;
req->data.regs.x86.msr_lstar = ctxt.msr_lstar;
-hvm_get_segment_register(curr, x86_seg_fs, );
-req->data.regs.x86.fs_base = seg.base;
-
-hvm_get_segment_register(curr, x86_seg_gs, );
-req->data.regs.x86.gs_base = seg.base;
+vm_event_pack_segment_register(x86_seg_fs, >data.regs.x86.fs);
+vm_event_pack_segment_register(x86_seg_gs, >data.regs.x86.gs);
+vm_event_pack_segment_register(x86_seg_cs, >data.regs.x86.cs);
+vm_event_pack_segment_register(x86_seg_ss, >data.regs.x86.ss);
+vm_event_pack_segment_register(x86_seg_ds, >data.regs.x86.ds);
+vm_event_pack_segment_register(x86_seg_es, >data.regs.x86.es);
-hvm_get_segment_register(curr, x86_seg_cs, );
-req->data.regs.x86.cs_arbytes = seg.attr;
+req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
#endif
}
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 36e3f4685d..705e6f8a1c 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -29,7 +29,7 @@
#include "xen.h"
-#define VM_EVENT_INTERFACE_VERSION 0x0003
+#define VM_EVENT_INTERFACE_VERSION 0x0004
#if defined(__XEN__) || defined(__XEN_TOOLS__)
@@ -157,6 +157,20 @@
#define VM_EVENT_X86_CR42
#define VM_EVENT_X86_XCR0 3
+struct __attribute__((__packed__)) x86_selector_reg {
+uint16_t sel;
+union
+{
+uint64_t bytes;
+struct
+{
+uint64_t base :32;
+uint64_t limit :20;
+uint64_t ar :12;
+} fields;
+};
+};
+
/*
* Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
* so as to not fill the vm_event ring buffer too quickly.
@@ -191,9 +205,13 @@ struct vm_event_regs_x86 {
uint64_t msr_efer;
uint64_t msr_star;
uint64_t msr_lstar;
-uint64_t fs_base;
-uint64_t gs_base;
-uint32_t cs_arbytes;
+struct x86_selector_reg cs;
+struct x86_selector_reg ss;
+struct x86_selector_reg ds;
+struct x86_selector_reg es;
+struct x86_selector_reg fs;
+struct x86_selector_reg gs;
+uint64_t shadow_gs;
uint32_t _pad;
};
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 128850: regressions - trouble: blocked/broken
flight 128850 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/128850/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd broken build-amd64-freebsd 6 host-build-prep fail REGR. vs. 128497 Tests which did not succeed, but are not blocking: build-amd64-xen-freebsd 1 build-check(1) blocked n/a build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd a084607579c9e54938a8007138d3473c31f2ca3c baseline version: freebsd c0b412ce93b9d3ee750e5f262b50e64c52d300cc Last test of basis 128497 2018-10-08 09:19:52 Z9 days Failing since128582 2018-10-10 09:19:25 Z7 days4 attempts Testing same since 128850 2018-10-17 09:19:04 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae allanjude br brooks bz davidcs des egypcio emaste erj gjb glebius hselasky jhb jkim jtl kevans kib luporl markj mav mjg mw np nwhitehorn peter rmacklem shurd trasz tsoome yuripv jobs: build-amd64-freebsd-againblocked build-amd64-freebsd broken build-amd64-xen-freebsd blocked 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 broken-job build-amd64-freebsd broken Not pushing. (No revision log; it would be 2291 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 128822: regressions - FAIL
flight 128822 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128822/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail in 128696 REGR. vs. 128646 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail pass in 128696 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 128696 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128646 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128646 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128646 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128646 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128646 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-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-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 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-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 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-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop 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-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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
Re: [Xen-devel] [PATCH] xen: remove redundant 'default n' from Kconfig
On 16/10/2018 16:33, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
>
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
>
> config FOO
> bool
>
> config FOO
> bool
> default n
>
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: remove redundant 'default n' from Kconfig-s
Hi Bart,
On Tue, Oct 16, 2018 at 03:42:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
>
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
>
> config FOO
> bool
>
> config FOO
> bool
> default n
>
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> arch/x86/Kconfig |7 ---
> arch/x86/Kconfig.debug |1 -
> arch/x86/xen/Kconfig |1 -
> 3 files changed, 9 deletions(-)
looks good, no difference of allmodconfigs before and after.
But that close before the merge window and it not being urgent, I'll
queue it after the merge window.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()
The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M code to be sunstantially
simplified.
NOTE: This patch does not modify the underlying vendor IOMMU
implementations to deal with page orders of more than 4k.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Jun Nakajima
Cc: Kevin Tian
---
xen/arch/x86/mm.c | 4 ++-
xen/arch/x86/mm/p2m-ept.c | 30 ++---
xen/arch/x86/mm/p2m-pt.c| 47 ++-
xen/arch/x86/mm/p2m.c | 49
xen/arch/x86/x86_64/mm.c| 4 ++-
xen/common/grant_table.c| 7 ++--
xen/drivers/passthrough/iommu.c | 65 -
xen/drivers/passthrough/x86/iommu.c | 2 +-
xen/include/xen/iommu.h | 8 +++--
9 files changed, 80 insertions(+), 136 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c53bc86a68..f0ae016e7a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2794,9 +2794,11 @@ static int _get_page_type(struct page_info *page,
unsigned long type,
mfn_t mfn = page_to_mfn(page);
if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
+iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)),
+ PAGE_ORDER_4K);
else if ( type == PGT_writable_page )
iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
+ PAGE_ORDER_4K,
IOMMUF_readable |
IOMMUF_writable);
}
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 407e299e50..656c8dd3ac 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -880,33 +880,9 @@ out:
if ( iommu_use_hap_pt(d) )
rc = iommu_pte_flush(d, gfn, _entry->epte, order,
vtd_pte_present);
else if ( need_iommu_pt_sync(d) )
-{
-dfn_t dfn = _dfn(gfn);
-
-if ( iommu_flags )
-for ( i = 0; i < (1 << order); i++ )
-{
-rc = iommu_map_page(d, dfn_add(dfn, i),
-mfn_add(mfn, i), iommu_flags);
-if ( unlikely(rc) )
-{
-while ( i-- )
-/* If statement to satisfy __must_check. */
-if ( iommu_unmap_page(p2m->domain,
- dfn_add(dfn, i)) )
-continue;
-
-break;
-}
-}
-else
-for ( i = 0; i < (1 << order); i++ )
-{
-ret = iommu_unmap_page(d, dfn_add(dfn, i));
-if ( !rc )
-rc = ret;
-}
-}
+rc = iommu_flags ?
+iommu_map_page(d, _dfn(gfn), mfn, order, iommu_flags) :
+iommu_unmap_page(d, _dfn(gfn), order);
}
unmap_domain_page(table);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 55df18501e..b264a97bd8 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -477,10 +477,11 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
mfn_t mfn,
unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma,
int sve)
{
+struct domain *d = p2m->domain;
/* XXX -- this might be able to be faster iff current->domain == d */
void *table;
unsigned long gfn = gfn_x(gfn_);
-unsigned long i, gfn_remainder = gfn;
+unsigned long gfn_remainder = gfn;
l1_pgentry_t *p2m_entry, entry_content;
/* Intermediate table to free if we're replacing it with a superpage. */
l1_pgentry_t intermediate_entry = l1e_empty();
@@ -515,7 +516,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t
mfn,
t.gfn = gfn;
t.mfn = mfn_x(mfn);
t.p2mt = p2mt;
-t.d = p2m->domain->domain_id;
+t.d = d->domain_id;
t.order = page_order;
__trace_var(TRC_MEM_SET_P2M_ENTRY, 0, sizeof(t), );
@@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
mfn_t mfn,
{
ASSERT(rc == 0);
-if ( iommu_use_hap_pt(p2m->domain) )
-{
-if ( iommu_old_flags )
-
Re: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff to XCP-ng Project
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Alexander Schulz - XCP-ng Project Member > Sent: 16 October 2018 21:28 > To: xen-devel@lists.xenproject.org > Cc: Wei Liu ; Ian Jackson ; > c...@schulzalex.de > Subject: [Xen-devel] [PATCH] Reservation of PCI device range 0xc200-0xc2ff > to XCP-ng Project > > We are the XCP-ng project (https://xcp-ng.org) and want to distribute > our own PV-Tools (maybe also per windows updates) so we need an extra > range. > > We also registered a PCI-Device: > > "XCP-ng Project PCI Device for Windows Update" -> > https://pci-ids.ucw.cz/read/PC/5853/c200 > > Signed-off-by: Alexander Schulz LGTM. Reviewed-by: Paul Durrant > --- > docs/man/xen-pci-device-reservations.pod.7 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/docs/man/xen-pci-device-reservations.pod.7 > b/docs/man/xen-pci-device-reservations.pod.7 > index 049e47410f..1cd5a3e115 100644 > --- a/docs/man/xen-pci-device-reservations.pod.7 > +++ b/docs/man/xen-pci-device-reservations.pod.7 > @@ -41,6 +41,7 @@ multiple Xen vendors using conflicting IDs. > 0x0002| Citrix XenServer (grandfathered allocation for > XenServer 6.1) > 0xc000-0xc0ff | Citrix XenServer > 0xc100-0xc1ff | Citrix XenClient > + 0xc200-0xc2ff | XCP-ng Project (https://xcp-ng.org) >=head1 Notes > -- 2.17.1.windows.2 > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 128846: all pass - PUSHED
flight 128846 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128846/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b7dcf31402f410c53242839271ba3b94b619 baseline version: ovmf 25d310d9b6187ca2e770b0b959831416441ce271 Last test of basis 128845 2018-10-17 03:10:39 Z0 days Testing same since 128846 2018-10-17 06:10:55 Z0 days1 attempts People who touched revisions under test: Star Zeng 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 25d310d9b6..b7dcf3 b7dcf31402f410c53242839271ba3b94b619 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order to 4k
> -Original Message- > From: Roger Pau Monne > Sent: 16 October 2018 17:27 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; George Dunlap > ; Andrew Cooper ; Wei > Liu ; Jan Beulich > Subject: Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO > mapping order to 4k > > On Tue, Oct 16, 2018 at 03:41:55PM +0100, Paul Durrant wrote: > > The P2M common code currently restricts the MMIO mapping order of any > > domain with IOMMU mappings, but that is not using shared tables, to 4k. > > This has been shown to have a huge performance cost when passing through > > a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the > guest > > boot time from ~20s to several minutes when iommu=no-sharept is > specified > > on the Xen command line. > > > > The limitation was added by commit c3c756bd "x86/p2m: use large pages > > for MMIO mappings" however the underlying implementations of p2m- > >set_entry > > for Intel and AMD are coded to cope with mapping orders higher than 4k, > > even though the IOMMU mapping function is itself currently limited to > 4k, > > so there is no real need to limit the order passed into the method. > > > > With this patch applied the VM boot time is restored to something > > reasonable. Not as fast as without iommu=no-sharept, but within a few > > seconds of it. > > I guess the worry was that the loop in for example ept_set_entry to > perform the iommu mappings would take too long and trigger the > watchdog if for example a 1GB page is mapped? > > In any case we already allow to map higher order non-MMIO pages, which > should also trigger such issue? Indeed. It's no different at this level. AFAICT we map an extent of whatever order is handed to XENMEM_populate_physmap with no pre-empt checks so, if there is a problem, limiting the MMIO order does not seem to be the right way to deal with it. Paul > > Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V6] x86/altp2m: Add a subop for obtaining the mem access of a page
On 10/16/18 7:26 PM, George Dunlap wrote: > On 09/27/2018 08:58 AM, Razvan Cojocaru wrote: >> Currently there is a subop for setting the memaccess of a page, but not >> for consulting it. The new HVMOP_altp2m_get_mem_access adds this >> functionality. >> >> Both altp2m get/set mem access functions use the struct >> xen_hvm_altp2m_mem_access which has now dropped the `set' part and has >> been renamed from xen_hvm_altp2m_set_mem_access. >> >> Signed-off-by: Adrian Pop >> Signed-off-by: Razvan Cojocaru > > Sorry it took so long to get to this: > > Reviewed-by: George Dunlap No problem at all. Thanks! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
