[Xen-devel] [linux-5.4 test] 146923: regressions - FAIL
flight 146923 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146923/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 146876 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail pass in 146876 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 146121 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 146876 REGR. vs. 146121 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 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-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never 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-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass
[Xen-devel] [xen-unstable-smoke test] 146994: regressions - FAIL
flight 146994 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146994/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z1 days 15 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days9 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
[Xen-devel] [xen-unstable-smoke test] 146986: regressions - FAIL
flight 146986 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146986/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z1 days 14 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days8 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
[Xen-devel] [linux-4.4 test] 146915: regressions - FAIL
flight 146915 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146915/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 139698 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 139698 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 139698 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 139698 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxd6ccbff9be43dbb6113a6a3f107c3d066052097e baseline version: linuxdc16a7e5f36d65b25a1b66ade14356773ed52875 Last test of basis 139698 2019-08-04 07:48:30 Z 192 days Failing since139773 2019-08-06 16:40:26 Z 190 days 105 attempts Testing same since 146860 2020-02-11 11:18:03 Z1 days2 attempts 1072 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass
[Xen-devel] [linux-4.9 test] 146910: regressions - FAIL
flight 146910 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146910/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 142947 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 142947 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142893 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142947 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142947 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142947 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142947 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142947 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142947 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-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail 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 version targeted for testing: linux0e96b1eb0ea5e4e8cdcdde6f0c68f89dc1d08be7 baseline version: linux364ef83db0273acc89c6ba8ae1aebee70a133056 Last test of basis 142947 2019-10-20 03:26:28 Z 115 days Failing since143328 2019-10-29 08:51:20 Z 106 days7 attempts Testing same since 146858 2020-02-11 11:11:29 Z1 days2 attempts 1047 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass
[Xen-devel] [ovmf test] 146919: regressions - FAIL
flight 146919 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/146919/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767 version targeted for testing: ovmf c44e0a896cacce179a3291e5080e8573c909ce2a baseline version: ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb Last test of basis 145767 2020-01-08 00:39:09 Z 36 days Failing since145774 2020-01-08 02:50:20 Z 35 days 122 attempts Testing same since 146919 2020-02-12 04:15:45 Z0 days1 attempts People who touched revisions under test: Aaron Li Albecki, Mateusz Amol N Sukerkar Anthony PERARD Antoine Coeur Ard Biesheuvel Ashish Singhal Bob Feng Bret Barkelew Brian R Haug Eric Dong Fan, ZhijuX Felix Polyudov Guo Dong Hao A Wu Heng Luo Jason Voelz Jeff Brasen Jian J Wang Kinney, Michael D Krzysztof Koch Laszlo Ersek Leif Lindholm Li, Aaron Liming Gao Liu, Zhiguang Mateusz Albecki Matthew Carlson Michael D Kinney Michael Kubacki Pavana.K Philippe Mathieu-Daud? Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Pierre Gondois Sami Mujawar Sean Brogan Siyuan Fu Siyuan, Fu Steven Steven Shi Sudipto Paul Vitaly Cheptsov Vitaly Cheptsov via Groups.Io Wei6 Xu Xu, Wei6 Zhichao Gao Zhiguang Liu Zhiju.Fan 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 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4926 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 146980: regressions - FAIL
flight 146980 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146980/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z1 days 13 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days7 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
[Xen-devel] [OSSTEST PATCH] build: fix configuration of libvirt
libvirt.git commit 2621d48f00 removed the last traces of gnulib, which
also removed the '--no-git' option from autogen.sh. Unknown options are
now passed to the configure script, which quickly fails with
configure: error: unrecognized option: `--no-git'
Remove the gnulib handling from ts-libvirt-build, including the '--no-git'
option to autogen.sh. While at it remove configure options no longer
supported by the libvirt configure script.
Signed-off-by: Jim Fehlig
---
I have poor perl skills, but hopefully this fixes the latest build
failures of the libvirt test project, e.g.
http://logs.test-lab.xenproject.org/osstest/logs/146921/build-amd64-libvirt/6.ts-libvirt-build.log
ts-libvirt-build | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index e799f003..ac5afcf2 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -26,8 +26,7 @@ tsreadconfig();
selectbuildhost(\@ARGV);
builddirsprops();
-our %submodmap = qw(gnulib gnulib
-keycodemapdb keycodemapdb);
+our %submodmap = qw(keycodemapdb keycodemapdb);
our $submodules;
sub libvirtd_init ();
@@ -50,12 +49,6 @@ sub config() {
}
die "no xen prefix" unless $xenprefix;
-# Uses --no-git because otherwise autogen.sh will undo
-# submodulefixup's attempts to honour
-# revision_libvirt_gnulib. This in turn requires that we specify
-# --gnulib-srcdir, but ./autogen.sh doesn't propagate
-# --gnulib-srcdir to ./bootstap so we use GNULIB_SRCDIR directly.
-my $gnulib = submodule_find($submodules, "gnulib");
target_cmd_build($ho, 3600, $builddir, <{Path} \\
-../autogen.sh --no-git \\
- --with-libxl --without-xen --without-xenapi
--without-selinux \\
- --without-lxc --without-vbox --without-uml \\
+../autogen.sh \\
+ --with-libxl --without-selinux \\
+ --without-lxc --without-vbox \\
--without-qemu --without-openvz --without-vmware \\
--sysconfdir=/etc --localstatedir=/var #/
END
--
2.25.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 146905: regressions - FAIL
flight 146905 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-examine 8 reboot fail REGR. vs. 142849 test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 142849 test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl-credit1 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 142849 test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 142849 test-amd64-amd64-xl-credit2 23 leak-check/check fail REGR. vs. 142849 build-i3866 xen-build fail in 146857 REGR. vs. 142849 build-amd64 6 xen-build fail in 146857 REGR. vs. 142849 build-amd64-xsm 6 xen-build fail in 146857 REGR. vs. 142849 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 7 xen-boot fail pass in 146857 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1)blocked in 146857 n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-examine 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1)blocked in 146857 n/a build-i386-libvirt1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl1 build-check(1) blocked in 146857 n/a test-amd64-amd64-libvirt 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 146857 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 146857 n/a build-amd64-libvirt 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked in 146857 n/a test-amd64-i386-libvirt 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-pygrub 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-xsm1 build-check(1) blocked in 146857 n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked in 146857 n/a test-amd64-i386-examine 1 build-check(1) blocked in 146857 n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 146857 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1)blocked in 146857 n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked in 146857 n/a
[Xen-devel] [xen-unstable-smoke test] 146976: regressions - FAIL
flight 146976 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146976/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z1 days 12 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days6 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
Re: [Xen-devel] [PATCH 1/3] x86/smp: unify header includes in smp.h
On Wed, Feb 12, 2020 at 05:49:47PM +0100, Roger Pau Monne wrote: > Unify the two adjacent header includes that are both gated with ifndef > __ASSEMBLY__. > > No functional change intended. > > Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86/hyperv: skeleton for L0 assisted TLB flush
On Wed, Feb 12, 2020 at 06:09:24PM +0100, Roger Pau Monné wrote:
> On Wed, Feb 12, 2020 at 04:09:17PM +, Wei Liu wrote:
> > Implement a basic hook for L0 assisted TLB flush. The hook needs to
> > check if prerequisites are met. If they are not met, it returns an error
> > number to fall back to native flushes.
> >
> > Introduce a new variable to indicate if hypercall page is ready.
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/guest/hyperv/Makefile | 1 +
> > xen/arch/x86/guest/hyperv/hyperv.c | 17
> > xen/arch/x86/guest/hyperv/private.h | 4 +++
> > xen/arch/x86/guest/hyperv/tlb.c | 41 +
> > 4 files changed, 63 insertions(+)
> > create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
> >
> > diff --git a/xen/arch/x86/guest/hyperv/Makefile
> > b/xen/arch/x86/guest/hyperv/Makefile
> > index 68170109a9..18902c33e9 100644
> > --- a/xen/arch/x86/guest/hyperv/Makefile
> > +++ b/xen/arch/x86/guest/hyperv/Makefile
> > @@ -1 +1,2 @@
> > obj-y += hyperv.o
> > +obj-y += tlb.o
> > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> > b/xen/arch/x86/guest/hyperv/hyperv.c
> > index b7044f7193..1cdc88e27c 100644
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> > DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> > DEFINE_PER_CPU_READ_MOSTLY(uint32_t, hv_vp_index);
> >
> > +static bool __read_mostly hv_hcall_page_ready;
> > +
> > static uint64_t generate_guest_id(void)
> > {
> > union hv_guest_os_id id = {};
> > @@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
> > BUG_ON(!hypercall_msr.enable);
> >
> > set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
> > +
> > +hv_hcall_page_ready = true;
>
> I guess filling the hypercall page in the probe function like it's
> done for Xen is too early for HyperV, and hence you need this
> safeguard?
Yes that's too early.
Keep in mind that Hyper-V's hypercall page is an overlay page which is
not backed by real memory from Xen's PoV. Xen can't fill in a stub
there. Xen needs to wait until other infrastructures to go live before
setting up a hypercall page, while in the mean time, it will / may need
to flush TLB.
>
> TBH, maybe it would be best (and safer) to prevent using any hooks
> until setup has been called, and hence this check could be pulled into
> the generic hook?
"Prevent" is too vague a term here. We can't stop code from executing in
parallel. In some situation there is no way to fail gracefully.
There is only this hook at the moment that requires such special care
afaict, and this is largely due to Hyper-V's idiosyncrasy. Others are
called only in setup / teardown path which can easily be reasoned about.
Wei.
>
> Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 11/12] xen: Update sched clock offset to avoid system instability in hibernation
Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
for xen")' fixes xen guest time handling during migration. A similar issue
is seen during PM hibernation when system runs CPU intensive workload.
Post resume pvclock resets the value to 0 however, xen sched_clock_offset
is never updated. System instability is seen during resume from hibernation
when system is under heavy CPU load. Since xen_sched_clock_offset is not
updated, system does not see the monotonic clock value and the scheduler
would then think that heavy CPU hog tasks need more time in CPU, causing
the system to freeze
Signed-off-by: Anchal Agarwal
---
Changes Since V2:
* New patch to update sched clock offset during hibernation to avoid
hungups during resume when running a CPU intensive workload
---
arch/x86/xen/suspend.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index dae0f74f5390..7e5275944810 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -105,6 +105,8 @@ static int xen_syscore_suspend(void)
xen_save_steal_clock(cpu);
}
+ xen_save_sched_clock_offset();
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
@@ -126,6 +128,12 @@ static void xen_syscore_resume(void)
pvclock_resume();
+ /*
+* Restore xen_sched_clock_offset during resume to maintain
+* monotonic clock value
+*/
+ xen_restore_sched_clock_offset();
+
/* Nonboot CPUs will be resumed when they're brought up */
xen_restore_steal_clock(smp_processor_id());
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 12/12] PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA
From: Aleksei Besogonov
The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all the data is
written out) in the validation of the swap signature in
mark_swapfiles().
Before this patch, the command line processing was the only place where
swsusp_resume_block was set.
Signed-off-by: Aleksei Besogonov
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
Changes since V2: None
---
kernel/power/user.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 77438954cc2b..d396e313cb7b 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -374,8 +374,12 @@ static long snapshot_ioctl(struct file *filp, unsigned int
cmd,
if (swdev) {
offset = swap_area.offset;
data->swap = swap_type_of(swdev, offset, NULL);
- if (data->swap < 0)
+ if (data->swap < 0) {
error = -ENODEV;
+ } else {
+ swsusp_resume_device = swdev;
+ swsusp_resume_block = offset;
+ }
} else {
data->swap = -1;
error = -EINVAL;
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 08/12] xen/time: introduce xen_{save, restore}_steal_clock
From: Munehisa Kamata
Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated idle
and steal time accounting. This breaks userspace tools which read
/proc/stat.
top - 08:05:35 up 2:12, 3 users, load average: 0.00, 0.07, 0.23
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,30100.0%id, 0.0%wa, 0.0%hi,
0.0%si,-1253874204672.0%st
This can actually happen when a Xen PVHVM guest gets restored from
hibernation, because such a restored guest is just a fresh domain from
Xen perspective and the time information in runstate info starts over
from scratch.
This patch introduces xen_save_steal_clock() which saves current values
in runstate info into per-cpu variables. Its couterpart,
xen_restore_steal_clock(), sets offset if it found the current values in
runstate info are smaller than previous ones. xen_steal_clock() is also
modified to use the offset to ensure that scheduler only sees
monotonically increasing number.
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
Changes since V2:
* separated the previously merged patches
* In V2, introduction of save/restore steal clock and usage in
hibernation code was merged in a single patch
---
drivers/xen/time.c| 29 -
include/xen/xen-ops.h | 2 ++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 0968859c29d0..3560222cc0dd 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -23,6 +23,9 @@ static DEFINE_PER_CPU(struct vcpu_runstate_info,
xen_runstate);
static DEFINE_PER_CPU(u64[4], old_runstate_time);
+static DEFINE_PER_CPU(u64, xen_prev_steal_clock);
+static DEFINE_PER_CPU(u64, xen_steal_clock_offset);
+
/* return an consistent snapshot of 64-bit time/counter value */
static u64 get64(const u64 *p)
{
@@ -149,7 +152,7 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
-u64 xen_steal_clock(int cpu)
+static u64 __xen_steal_clock(int cpu)
{
struct vcpu_runstate_info state;
@@ -157,6 +160,30 @@ u64 xen_steal_clock(int cpu)
return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
}
+u64 xen_steal_clock(int cpu)
+{
+ return __xen_steal_clock(cpu) + per_cpu(xen_steal_clock_offset, cpu);
+}
+
+void xen_save_steal_clock(int cpu)
+{
+ per_cpu(xen_prev_steal_clock, cpu) = xen_steal_clock(cpu);
+}
+
+void xen_restore_steal_clock(int cpu)
+{
+ u64 steal_clock = __xen_steal_clock(cpu);
+
+ if (per_cpu(xen_prev_steal_clock, cpu) > steal_clock) {
+ /* Need to update the offset */
+ per_cpu(xen_steal_clock_offset, cpu) =
+ per_cpu(xen_prev_steal_clock, cpu) - steal_clock;
+ } else {
+ /* Avoid unnecessary steal clock warp */
+ per_cpu(xen_steal_clock_offset, cpu) = 0;
+ }
+}
+
void xen_setup_runstate_info(int cpu)
{
struct vcpu_register_runstate_memory_area area;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 3b3992b5b0c2..12b3f4474a05 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -37,6 +37,8 @@ void xen_time_setup_guest(void);
void xen_manage_runstate_time(int action);
void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
u64 xen_steal_clock(int cpu);
+void xen_save_steal_clock(int cpu);
+void xen_restore_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 10/12] xen: Introduce wrapper for save/restore sched clock offset
Introduce wrappers for save/restore xen_sched_clock_offset to be
used by PM hibernation code to avoid system instability during resume.
Signed-off-by: Anchal Agarwal
---
Changes since V2:
* Dropped marking tsc unstable during hibernation patch
* Fixed issue with xen_sched_clock_offset during suspend/resume
* On further interrogation and testing, the issue wasn't with tsc
being stable/unstable
---
arch/x86/xen/time.c| 15 +--
arch/x86/xen/xen-ops.h | 2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 8cf632dda605..eeb6d3d2eaab 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -379,12 +379,23 @@ static const struct pv_time_ops xen_time_ops __initconst
= {
static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
static u64 xen_clock_value_saved;
+/*This is needed to maintain a monotonic clock value during PM hibernation */
+void xen_save_sched_clock_offset(void)
+{
+ xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+}
+
+void xen_restore_sched_clock_offset(void)
+{
+ xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+}
+
void xen_save_time_memory_area(void)
{
struct vcpu_register_time_memory_area t;
int ret;
- xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+ xen_save_sched_clock_offset();
if (!xen_clock)
return;
@@ -426,7 +437,7 @@ void xen_restore_time_memory_area(void)
out:
/* Need pvclock_resume() before using xen_clocksource_read(). */
pvclock_resume();
- xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+ xen_restore_sched_clock_offset();
}
static void xen_setup_vsyscall_time_info(void)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index d84c357994bd..9f49124df033 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -72,6 +72,8 @@ void xen_save_time_memory_area(void);
void xen_restore_time_memory_area(void);
void xen_init_time_ops(void);
void xen_hvm_init_time_ops(void);
+void xen_save_sched_clock_offset(void);
+void xen_restore_sched_clock_offset(void);
irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 07/12] genirq: Shutdown irq chips in suspend/resume during hibernation
There are no pm handlers for the legacy devices, so during tear down
stale event channel <> IRQ mapping may still remain in the image and
resume may fail. To avoid adding much code by implementing handlers for
legacy devices, add a new irq_chip flag IRQCHIP_SHUTDOWN_ON_SUSPEND which
when enabled on an irq-chip e.g xen-pirq, it will let core suspend/resume
irq code to shutdown and restart the active irqs. PM suspend/hibernation
code will rely on this.
Without this, in PM hibernation, information about the event channel
remains in hibernation image, but there is no guarantee that the same
event channel numbers are assigned to the devices when restoring the
system. This may cause conflict like the following and prevent some
devices from being restored correctly.
Signed-off-by: Anchal Agarwal
Suggested-by: Thomas Gleixner
---
Changes since V2:
* Its new patch to fix shutdown/restore pirqs during hibernation
* Removed previous 2 patches to shutdown/restore pirqs in xen code
---
drivers/xen/events/events_base.c | 1 +
include/linux/irq.h | 2 ++
kernel/irq/chip.c| 2 +-
kernel/irq/internals.h | 1 +
kernel/irq/pm.c | 31 ++-
5 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 6c8843968a52..e44f27b45bef 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1620,6 +1620,7 @@ static struct irq_chip xen_pirq_chip __read_mostly = {
.irq_set_affinity = set_affinity_irq,
.irq_retrigger = retrigger_dynirq,
+ .flags = IRQCHIP_SHUTDOWN_ON_SUSPEND,
};
static struct irq_chip xen_percpu_chip __read_mostly = {
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fb301cf29148..2873a579fd9d 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -511,6 +511,7 @@ struct irq_chip {
* IRQCHIP_EOI_THREADED: Chip requires eoi() on unmask in threaded mode
* IRQCHIP_SUPPORTS_LEVEL_MSI Chip can provide two doorbells for Level MSIs
* IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root irqchips
+ * IRQCHIP_SHUTDOWN_ON_SUSPEND: Shutdown non wake irqs in the suspend path
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
@@ -522,6 +523,7 @@ enum {
IRQCHIP_EOI_THREADED= (1 << 6),
IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7),
IRQCHIP_SUPPORTS_NMI= (1 << 8),
+ IRQCHIP_SHUTDOWN_ON_SUSPEND = (1 << 9),
};
#include
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b76703b2c0af..a1e8df5193ba 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -233,7 +233,7 @@ __irq_startup_managed(struct irq_desc *desc, struct cpumask
*aff, bool force)
}
#endif
-static int __irq_startup(struct irq_desc *desc)
+int __irq_startup(struct irq_desc *desc)
{
struct irq_data *d = irq_desc_get_irq_data(desc);
int ret = 0;
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 3924fbe829d4..11c7c55bda63 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -80,6 +80,7 @@ extern void __enable_irq(struct irq_desc *desc);
extern int irq_activate(struct irq_desc *desc);
extern int irq_activate_and_startup(struct irq_desc *desc, bool resend);
extern int irq_startup(struct irq_desc *desc, bool resend, bool force);
+extern int __irq_startup(struct irq_desc *desc);
extern void irq_shutdown(struct irq_desc *desc);
extern void irq_shutdown_and_deactivate(struct irq_desc *desc);
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 8f557fa1f4fe..dc48a25f1756 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -85,16 +85,25 @@ static bool suspend_device_irq(struct irq_desc *desc)
}
desc->istate |= IRQS_SUSPENDED;
- __disable_irq(desc);
-
/*
-* Hardware which has no wakeup source configuration facility
-* requires that the non wakeup interrupts are masked at the
-* chip level. The chip implementation indicates that with
-* IRQCHIP_MASK_ON_SUSPEND.
+* Some irq chips (e.g. XEN PIRQ) require a full shutdown on suspend
+* as some of the legacy drivers(e.g. floppy) do nothing during the
+* suspend path
*/
- if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
- mask_irq(desc);
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_SHUTDOWN_ON_SUSPEND) {
+ irq_shutdown(desc);
+ } else {
+ __disable_irq(desc);
+
+ /*
+ * Hardware which has no wakeup source configuration facility
+ * requires that the non wakeup interrupts are masked at the
+ * chip level. The chip implementation indicates that with
+ * IRQCHIP_MASK_ON_SUSPEND.
+ */
+ if (irq_desc_get_chip(desc)->flags &
[Xen-devel] [RFC PATCH v3 09/12] x86/xen: save and restore steal clock
From: Munehisa Kamata
Save steal clock values of all present CPUs in the system core ops
suspend callbacks. Also, restore a boot CPU's steal clock in the system
core resume callback. For non-boot CPUs, restore after they're brought
up, because runstate info for non-boot CPUs are not active until then.
Signed-off-by: Munehisa Kamata
Signed-off-by: Anchal Agarwal
---
Changes since V2:
* Separate patch to add save/restore call to suspend/resume code
---
arch/x86/xen/suspend.c | 13 -
arch/x86/xen/time.c| 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 784c4484100b..dae0f74f5390 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -91,12 +91,20 @@ void xen_arch_suspend(void)
static int xen_syscore_suspend(void)
{
struct xen_remove_from_physmap xrfp;
- int ret;
+ int cpu, ret;
/* Xen suspend does similar stuffs in its own logic */
if (xen_suspend_mode_is_xen_suspend())
return 0;
+ for_each_present_cpu(cpu) {
+ /*
+* Nonboot CPUs are already offline, but the last copy of
+* runstate info is still accessible.
+*/
+ xen_save_steal_clock(cpu);
+ }
+
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
@@ -118,6 +126,9 @@ static void xen_syscore_resume(void)
pvclock_resume();
+ /* Nonboot CPUs will be resumed when they're brought up */
+ xen_restore_steal_clock(smp_processor_id());
+
gnttab_resume();
}
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index befbdd8b17f0..8cf632dda605 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -537,6 +537,9 @@ static void xen_hvm_setup_cpu_clockevents(void)
{
int cpu = smp_processor_id();
xen_setup_runstate_info(cpu);
+ if (cpu)
+ xen_restore_steal_clock(cpu);
+
/*
* xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence
* doing it xen_hvm_cpu_notify (which gets called by smp_init during
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
events, need to implement these xenbus_driver callbacks.
The freeze handler stops a block-layer queue and disconnect the
frontend from the backend while freeing ring_info and associated resources.
The restore handler re-allocates ring_info and re-connect to the
backend, so the rest of the kernel can continue to use the block device
transparently. Also, the handlers are used for both PM suspend and
hibernation so that we can keep the existing suspend/resume callbacks for
Xen suspend without modification. Before disconnecting from backend,
we need to prevent any new IO from being queued and wait for existing
IO to complete. Freeze/unfreeze of the queues will guarantee that there
are no requests in use on the shared ring.
Note:For older backends,if a backend doesn't have commit'12ea729645ace'
xen/blkback: unmap all persistent grants when frontend gets disconnected,
the frontend may see massive amount of grant table warning when freeing
resources.
[ 36.852659] deferring g.e. 0xf9 (pfn 0x)
[ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use!
In this case, persistent grants would need to be disabled.
[Anchal Changelog: Removed timeout/request during blkfront freeze.
Fixed major part of the code to work with blk-mq]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
Changes since V2: None
---
drivers/block/xen-blkfront.c | 119 ---
1 file changed, 112 insertions(+), 7 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 478120233750..d715ed3cb69a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -47,6 +47,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -79,6 +81,8 @@ enum blkif_state {
BLKIF_STATE_DISCONNECTED,
BLKIF_STATE_CONNECTED,
BLKIF_STATE_SUSPENDED,
+ BLKIF_STATE_FREEZING,
+ BLKIF_STATE_FROZEN
};
struct grant {
@@ -220,6 +224,7 @@ struct blkfront_info
struct list_head requests;
struct bio_list bio_list;
struct list_head info_list;
+ struct completion wait_backend_disconnected;
};
static unsigned int nr_minors;
@@ -261,6 +266,7 @@ static DEFINE_SPINLOCK(minor_lock);
static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
static void blkfront_gather_backend_features(struct blkfront_info *info);
static int negotiate_mq(struct blkfront_info *info);
+static void __blkif_free(struct blkfront_info *info);
static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
{
@@ -995,6 +1001,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16
sector_size,
info->sector_size = sector_size;
info->physical_sector_size = physical_sector_size;
blkif_set_queue_limits(info);
+ init_completion(>wait_backend_disconnected);
return 0;
}
@@ -1218,6 +1225,8 @@ static void xlvbd_release_gendisk(struct blkfront_info
*info)
/* Already hold rinfo->ring_lock. */
static inline void kick_pending_request_queues_locked(struct
blkfront_ring_info *rinfo)
{
+ if (unlikely(rinfo->dev_info->connected == BLKIF_STATE_FREEZING))
+ return;
if (!RING_FULL(>ring))
blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
}
@@ -1341,8 +1350,6 @@ static void blkif_free_ring(struct blkfront_ring_info
*rinfo)
static void blkif_free(struct blkfront_info *info, int suspend)
{
- unsigned int i;
-
/* Prevent new requests being issued until we fix things up. */
info->connected = suspend ?
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
@@ -1350,6 +1357,13 @@ static void blkif_free(struct blkfront_info *info, int
suspend)
if (info->rq)
blk_mq_stop_hw_queues(info->rq);
+ __blkif_free(info);
+}
+
+static void __blkif_free(struct blkfront_info *info)
+{
+ unsigned int i;
+
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(>rinfo[i]);
@@ -1553,8 +1567,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
struct blkfront_ring_info *rinfo = (struct blkfront_ring_info *)dev_id;
struct blkfront_info *info = rinfo->dev_info;
- if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
- return IRQ_HANDLED;
+ if (unlikely(info->connected != BLKIF_STATE_CONNECTED)) {
+ if (info->connected != BLKIF_STATE_FREEZING)
+ return IRQ_HANDLED;
+ }
spin_lock_irqsave(>ring_lock, flags);
again:
@@ -2020,6 +2036,7 @@ static int blkif_recover(struct blkfront_info *info)
struct bio *bio;
unsigned int segs;
+ bool frozen = info->connected == BLKIF_STATE_FROZEN;
[Xen-devel] [RFC PATCH v3 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Signed-off-by: Anchal Agarwal
---
Changes since V2: None
---
arch/x86/xen/enlighten_hvm.c | 7 +++
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index e138f7de52d2..75b1ec7a0fcd 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -27,6 +27,13 @@
static unsigned long shared_info_pfn;
+void xen_hvm_map_shared_info(void)
+{
+ xen_hvm_init_shared_info();
+ if (shared_info_pfn)
+ HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+}
+
void xen_hvm_init_shared_info(void)
{
struct xen_add_to_physmap xatp;
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 45a441c33d6d..d84c357994bd 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -56,6 +56,7 @@ void xen_enable_syscall(void);
void xen_vcpu_restore(void);
void xen_callback_vector(void);
+void xen_hvm_map_shared_info(void);
void xen_hvm_init_shared_info(void);
void xen_unplug_emulated_devices(void);
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 05/12] xen-netfront: add callbacks for PM suspend and hibernation support
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
frontend state and let the xenbus handler to re-allocate the resources
and re-connect to the backend. This can be performed transparently to
the rest of the system. The handlers are used for both PM suspend and
hibernation so that we can keep the existing suspend/resume callbacks
for Xen suspend without modification. Freezing netfront devices is
normally expected to finish within a few hundred milliseconds, but it
can rarely take more than 5 seconds and hit the hard coded timeout,
it would depend on backend state which may be congested and/or have
complex configuration. While it's rare case, longer default timeout
seems a bit more reasonable here to avoid hitting the timeout.
Also, make it configurable via module parameter so that we can cover
broader setups than what we know currently.
[Anchal changelog: Variable name fix and checkpatch.pl fixes]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
Changes since V2: None
---
drivers/net/xen-netfront.c | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 482c6c8b0fb7..65edcdd6e05f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -56,6 +57,12 @@
#include
#include
+enum netif_freeze_state {
+ NETIF_FREEZE_STATE_UNFROZEN,
+ NETIF_FREEZE_STATE_FREEZING,
+ NETIF_FREEZE_STATE_FROZEN,
+};
+
/* Module parameters */
#define MAX_QUEUES_DEFAULT 8
static unsigned int xennet_max_queues;
@@ -63,6 +70,12 @@ module_param_named(max_queues, xennet_max_queues, uint,
0644);
MODULE_PARM_DESC(max_queues,
"Maximum number of queues per virtual interface");
+static unsigned int netfront_freeze_timeout_secs = 10;
+module_param_named(freeze_timeout_secs,
+ netfront_freeze_timeout_secs, uint, 0644);
+MODULE_PARM_DESC(freeze_timeout_secs,
+"timeout when freezing netfront device in seconds");
+
static const struct ethtool_ops xennet_ethtool_ops;
struct netfront_cb {
@@ -160,6 +173,10 @@ struct netfront_info {
struct netfront_stats __percpu *tx_stats;
atomic_t rx_gso_checksum_fixup;
+
+ int freeze_state;
+
+ struct completion wait_backend_disconnected;
};
struct netfront_rx_info {
@@ -721,6 +738,21 @@ static int xennet_close(struct net_device *dev)
return 0;
}
+static int xennet_disable_interrupts(struct net_device *dev)
+{
+ struct netfront_info *np = netdev_priv(dev);
+ unsigned int num_queues = dev->real_num_tx_queues;
+ unsigned int queue_index;
+ struct netfront_queue *queue;
+
+ for (queue_index = 0; queue_index < num_queues; ++queue_index) {
+ queue = >queues[queue_index];
+ disable_irq(queue->tx_irq);
+ disable_irq(queue->rx_irq);
+ }
+ return 0;
+}
+
static void xennet_move_rx_slot(struct netfront_queue *queue, struct sk_buff
*skb,
grant_ref_t ref)
{
@@ -1301,6 +1333,8 @@ static struct net_device *xennet_create_dev(struct
xenbus_device *dev)
np->queues = NULL;
+ init_completion(>wait_backend_disconnected);
+
err = -ENOMEM;
np->rx_stats = netdev_alloc_pcpu_stats(struct netfront_stats);
if (np->rx_stats == NULL)
@@ -1794,6 +1828,50 @@ static int xennet_create_queues(struct netfront_info
*info,
return 0;
}
+static int netfront_freeze(struct xenbus_device *dev)
+{
+ struct netfront_info *info = dev_get_drvdata(>dev);
+ unsigned long timeout = netfront_freeze_timeout_secs * HZ;
+ int err = 0;
+
+ xennet_disable_interrupts(info->netdev);
+
+ netif_device_detach(info->netdev);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FREEZING;
+
+ /* Kick the backend to disconnect */
+ xenbus_switch_state(dev, XenbusStateClosing);
+
+ /* We don't want to move forward before the frontend is diconnected
+* from the backend cleanly.
+*/
+ timeout = wait_for_completion_timeout(>wait_backend_disconnected,
+ timeout);
+ if (!timeout) {
+ err = -EBUSY;
+ xenbus_dev_error(dev, err, "Freezing timed out;"
+"the device may become inconsistent state");
+ return err;
+ }
+
+ /* Tear down queues */
+ xennet_disconnect_backend(info);
+ xennet_destroy_queues(info);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FROZEN;
+
+ return err;
+}
+
+static int
[Xen-devel] [RFC PATCH v3 02/12] xenbus: add freeze/thaw/restore callbacks support
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
respectively, and only suspend and resume callbacks are supported at
driver level. To support PM suspend and PM hibernation, modify the bus
level PM callbacks to invoke not only device driver's suspend/resume but
also freeze/thaw/restore.
Note that we'll use freeze/restore callbacks even for PM suspend whereas
suspend/resume callbacks are normally used in the case, becausae the
existing xenbus device drivers already have suspend/resume callbacks
specifically designed for Xen suspend. So we can allow the device
drivers to keep the existing callbacks wihtout modification.
[Anchal Changelog: Refactored the callbacks code]
Signed-off-by: Agarwal Anchal
Signed-off-by: Munehisa Kamata
---
Changes since V2: None
---
drivers/xen/xenbus/xenbus_probe.c | 99 +--
include/xen/xenbus.h | 3 +
2 files changed, 84 insertions(+), 18 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 5b471889d723..0fa868c2 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -597,27 +598,44 @@ int xenbus_dev_suspend(struct device *dev)
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
-
+ bool xen_suspend = xen_suspend_mode_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
if (dev->driver == NULL)
return 0;
drv = to_xenbus_driver(dev->driver);
- if (drv->suspend)
- err = drv->suspend(xdev);
- if (err)
- pr_warn("suspend %s failed: %i\n", dev_name(dev), err);
+
+ if (xen_suspend) {
+ if (drv->suspend)
+ err = drv->suspend(xdev);
+ } else {
+ if (drv->freeze) {
+ err = drv->freeze(xdev);
+ if (!err) {
+ free_otherend_watch(xdev);
+ free_otherend_details(xdev);
+ return 0;
+ }
+ }
+ }
+
+ if (err) {
+ pr_warn("%s %s failed: %i\n", xen_suspend ?
+ "suspend" : "freeze", dev_name(dev), err);
+ return err;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(xenbus_dev_suspend);
int xenbus_dev_resume(struct device *dev)
{
- int err;
+ int err = 0;
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
-
+ bool xen_suspend = xen_suspend_mode_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
if (dev->driver == NULL)
@@ -625,24 +643,32 @@ int xenbus_dev_resume(struct device *dev)
drv = to_xenbus_driver(dev->driver);
err = talk_to_otherend(xdev);
if (err) {
- pr_warn("resume (talk_to_otherend) %s failed: %i\n",
+ pr_warn("%s (talk_to_otherend) %s failed: %i\n",
+ xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
- xdev->state = XenbusStateInitialising;
+ if (xen_suspend) {
+ xdev->state = XenbusStateInitialising;
+ if (drv->resume)
+ err = drv->resume(xdev);
+ } else {
+ if (drv->restore)
+ err = drv->restore(xdev);
+ }
- if (drv->resume) {
- err = drv->resume(xdev);
- if (err) {
- pr_warn("resume %s failed: %i\n", dev_name(dev), err);
- return err;
- }
+ if (err) {
+ pr_warn("%s %s failed: %i\n",
+ xen_suspend ? "resume" : "restore",
+ dev_name(dev), err);
+ return err;
}
err = watch_otherend(xdev);
if (err) {
- pr_warn("resume (watch_otherend) %s failed: %d.\n",
+ pr_warn("%s (watch_otherend) %s failed: %d.\n",
+ xen_suspend ? "resume" : "restore",
dev_name(dev), err);
return err;
}
@@ -653,8 +679,45 @@ EXPORT_SYMBOL_GPL(xenbus_dev_resume);
int xenbus_dev_cancel(struct device *dev)
{
- /* Do nothing */
- DPRINTK("cancel");
+ int err = 0;
+ struct xenbus_driver *drv;
+ struct xenbus_device *xdev
+ = container_of(dev, struct xenbus_device, dev);
+ bool xen_suspend =
[Xen-devel] [RFC PATCH v3 01/12] xen/manage: keep track of the on-going suspend mode
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later modes
which are xen toolstack assisted and image creation/storage is in
control of hypervisor/host machine.
To differentiate between Xen suspend and PM hibernation, keep track
of the on-going suspend mode by mainly using a new PM notifier.
Introduce simple functions which help to know the on-going suspend mode
so that other Xen-related code can behave differently according to the
current suspend mode.
Since Xen suspend doesn't have corresponding PM event, its main logic
is modfied to acquire pm_mutex and set the current mode.
Though, acquirng pm_mutex is still right thing to do, we may
see deadlock if PM hibernation is interrupted by Xen suspend.
PM hibernation depends on xenwatch thread to process xenbus state
transactions, but the thread will sleep to wait pm_mutex which is
already held by PM hibernation context in the scenario. Xen shutdown
code may need some changes to avoid the issue.
[Anchal Changelog: Merged patch xen/manage: introduce helper function
to know the on-going suspend mode into this one for better readability]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
Changes since V2: None
---
drivers/xen/manage.c | 73 +++
include/xen/xen-ops.h | 3 ++
2 files changed, 76 insertions(+)
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index cd046684e0d1..0b30ab522b77 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,31 @@ enum shutdown_state {
/* Ignore multiple shutdown requests. */
static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
+enum suspend_modes {
+ NO_SUSPEND = 0,
+ XEN_SUSPEND,
+ PM_SUSPEND,
+ PM_HIBERNATION,
+};
+
+/* Protected by pm_mutex */
+static enum suspend_modes suspend_mode = NO_SUSPEND;
+
+bool xen_suspend_mode_is_xen_suspend(void)
+{
+ return suspend_mode == XEN_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_suspend(void)
+{
+ return suspend_mode == PM_SUSPEND;
+}
+
+bool xen_suspend_mode_is_pm_hibernation(void)
+{
+ return suspend_mode == PM_HIBERNATION;
+}
+
struct suspend_info {
int cancelled;
};
@@ -99,6 +125,10 @@ static void do_suspend(void)
int err;
struct suspend_info si;
+ lock_system_sleep();
+
+ suspend_mode = XEN_SUSPEND;
+
shutting_down = SHUTDOWN_SUSPEND;
err = freeze_processes();
@@ -162,6 +192,10 @@ static void do_suspend(void)
thaw_processes();
out:
shutting_down = SHUTDOWN_INVALID;
+
+ suspend_mode = NO_SUSPEND;
+
+ unlock_system_sleep();
}
#endif /* CONFIG_HIBERNATE_CALLBACKS */
@@ -387,3 +421,42 @@ int xen_setup_shutdown_event(void)
EXPORT_SYMBOL_GPL(xen_setup_shutdown_event);
subsys_initcall(xen_setup_shutdown_event);
+
+static int xen_pm_notifier(struct notifier_block *notifier,
+ unsigned long pm_event, void *unused)
+{
+ switch (pm_event) {
+ case PM_SUSPEND_PREPARE:
+ suspend_mode = PM_SUSPEND;
+ break;
+ case PM_HIBERNATION_PREPARE:
+ case PM_RESTORE_PREPARE:
+ suspend_mode = PM_HIBERNATION;
+ break;
+ case PM_POST_SUSPEND:
+ case PM_POST_RESTORE:
+ case PM_POST_HIBERNATION:
+ /* Set back to the default */
+ suspend_mode = NO_SUSPEND;
+ break;
+ default:
+ pr_warn("Receive unknown PM event 0x%lx\n", pm_event);
+ return -EINVAL;
+ }
+
+ return 0;
+};
+
+static struct notifier_block xen_pm_notifier_block = {
+ .notifier_call = xen_pm_notifier
+};
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
+
+ return register_pm_notifier(_pm_notifier_block);
+}
+
+subsys_initcall(xen_setup_pm_notifier);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index d89969aa9942..6c36e161dfd1 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -40,6 +40,9 @@ u64 xen_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
+bool xen_suspend_mode_is_xen_suspend(void);
+bool xen_suspend_mode_is_pm_suspend(void);
+bool xen_suspend_mode_is_pm_hibernation(void);
extern unsigned long *xen_contiguous_bitmap;
#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH v3 00/12] Enable PM hibernation on guest VMs
Hello,
I am sending out a v3 version of series of patches that implements guest
PM hibernation.
These guests are running on xen hypervisor. The patches had been tested
against mainstream kernel. EC2 instance hibernation feature is provided
to the AWS EC2 customers. PM hibernation uses swap space carved out within
the guest[or can be a separate partition], where hibernation image is
stored and restored from.
Doing guest hibernation does not involve any support from hypervisor and
this way guest has complete control over its state. Infrastructure
restrictions for saving up guest state can be overcome by guest initiated
hibernation.
This series includes some improvements over RFC series sent last year:
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg00823.html
Changelog v3:
1. Feedback from V2
2. Introduced 2 new patches for xen sched clock offset fix
3. Fixed pirq shutdown/restore in generic irq subsystem
4. Split save/restore steal clock patches into 2 for better readability
Changelog v2:
1. Removed timeout/request present on the ring in xen-blkfront during blkfront
freeze
2. Fixed restoring of PIRQs which was apparently working for 4.9 kernels but
not for
newer kernel. [Legacy irqs were no longer restored after hibernation introduced
with
this commit "020db9d3c1dc0"]
3. Merged couple of related patches to make the code more coherent and readable
4. Code refactoring
5. Sched clock fix when hibernating guest is under heavy CPU load
Note: Under very rare circumstances we see resume failures with KASLR enabled
only
on xen instances. We are roughly seeing 3% failures [>1000 runs] when testing
with
various instance sizes and some workload running on each instance. I am
currently
investigating the issue as to confirm if its a xen issue or kernel issue.
However, it should not hold back anyone from reviewing/accepting these patches.
Testing done:
All testing is done for multiple hibernation cycle for 5.4 kernel on EC2.
Testing How to:
---
Example:
Set up a file-backed swap space. Swap file size>=Total memory on the system
sudo dd if=/dev/zero of=/swap bs=$(( 1024 * 1024 )) count=4096 # 4096MiB
sudo chmod 600 /swap
sudo mkswap /swap
sudo swapon /swap
Update resume device/resume offset in grub if using swap file:
resume=/dev/xvda1 resume_offset=200704
Execute:
sudo pm-hibernate
OR
echo disk > /sys/power/state && echo reboot > /sys/power/disk
Compute resume offset code:
"
#!/usr/bin/env python
import sys
import array
import fcntl
#swap file
f = open(sys.argv[1], 'r')
buf = array.array('L', [0])
#FIBMAP
ret = fcntl.ioctl(f.fileno(), 0x01, buf)
print buf[0]
"
Aleksei Besogonov (1):
PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA
Anchal Agarwal (4):
x86/xen: Introduce new function to map HYPERVISOR_shared_info on
Resume
genirq: Shutdown irq chips in suspend/resume during hibernation
xen: Introduce wrapper for save/restore sched clock offset
xen: Update sched clock offset to avoid system instability in
hibernation
Munehisa Kamata (7):
xen/manage: keep track of the on-going suspend mode
xenbus: add freeze/thaw/restore callbacks support
x86/xen: add system core suspend and resume callbacks
xen-netfront: add callbacks for PM suspend and hibernation support
xen-blkfront: add callbacks for PM suspend and hibernation
xen/time: introduce xen_{save,restore}_steal_clock
x86/xen: save and restore steal clock
arch/x86/xen/enlighten_hvm.c | 8 ++
arch/x86/xen/suspend.c| 72 ++
arch/x86/xen/time.c | 18 -
arch/x86/xen/xen-ops.h| 3 +
drivers/block/xen-blkfront.c | 119 --
drivers/net/xen-netfront.c| 98 +++-
drivers/xen/events/events_base.c | 1 +
drivers/xen/manage.c | 73 ++
drivers/xen/time.c| 29 +++-
drivers/xen/xenbus/xenbus_probe.c | 99 -
include/linux/irq.h | 2 +
include/xen/xen-ops.h | 8 ++
include/xen/xenbus.h | 3 +
kernel/irq/chip.c | 2 +-
kernel/irq/internals.h| 1 +
kernel/irq/pm.c | 31 +---
kernel/power/user.c | 6 +-
17 files changed, 533 insertions(+), 40 deletions(-)
--
2.24.1.AMZN
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 146921: regressions - FAIL
flight 146921 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/146921/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt c4a78d00f8d00ef4ab84c3110ffb6975ed680554 baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 26 days Failing since146211 2020-01-18 04:18:52 Z 25 days 26 attempts Testing same since 146921 2020-02-12 04:24:03 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Boris Fiuczynski Christian Ehrhardt Daniel Henrique Barboza Daniel P. Berrangé Dario Faggioli Erik Skultety Han Han Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Marek Marczykowski-Górecki Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Richard W.M. Jones Sahid Orentino Ferdjaoui Stefan Berger Stefan Berger Thomas Huth zhenwei pi 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 fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd 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
[Xen-devel] [qemu-mainline test] 146922: regressions - FAIL
flight 146922 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/146922/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-buildfail REGR. vs. 144861 build-arm64-xsm 6 xen-buildfail REGR. vs. 144861 build-armhf 6 xen-buildfail REGR. vs. 144861 build-amd64-xsm 6 xen-buildfail REGR. vs. 144861 build-i386-xsm6 xen-buildfail REGR. vs. 144861 build-amd64 6 xen-buildfail REGR. vs. 144861 build-i3866 xen-buildfail REGR. vs. 144861 Tests which did not succeed, but are not blocking: 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-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 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 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 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-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1
Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.
On 12/02/2020 22:36, Stefano Stabellini wrote: On Wed, 12 Feb 2020, Andrei Cherechesu wrote: (XEN) DOM1: [ 3.883482] sdhci: Secure Digital Host Controller Interface driver (XEN) DOM1: [ 3.891021] sdhci: Copyright(c) Pierre Ossman (XEN) DOM1: [ 3.896389] sdhci-pltfm: SDHCI platform and OF driver helper (XEN) DOM1: [ 3.903298] Unhandled fault at 0xff800800d048 (XEN) DOM1: [ 3.909021] Mem abort info: (XEN) DOM1: [ 3.912863] ESR = 0x9600 (XEN) DOM1: [ 3.917019] Exception class = DABT (current EL), IL = 32 bits (XEN) DOM1: [ 3.924115] SET = 0, FnV = 0 (XEN) DOM1: [ 3.928206] EA = 0, S1PTW = 0 (XEN) DOM1: [ 3.932457] Data abort info: (XEN) DOM1: [ 3.936514] ISV = 0, ISS = 0x (XEN) DOM1: [ 3.941398] CM = 0, WnR = 0 (XEN) DOM1: [ 3.945481] swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval) (XEN) DOM1: [ 3.953532] [ff800800d048] pgd=bfffe803, pud=bfffe803, pmd=bfffd803, pte=00e8402f0f07 (XEN) DOM1: [ 3.965278] Internal error: ttbr address size fault: 9600 [#1] PREEMPT SMP (XEN) DOM1: [ 3.973546] Modules linked in: (XEN) DOM1: [ 3.977709] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) (XEN) DOM1: [ 3.985525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.59-rt24+g00334f2 #1 (XEN) DOM1: [ 3.993855] pstate: 6005 (nZCv daif -PAN -UAO) (XEN) DOM1: [ 3.999755] pc : 0xff80083ac864 (XEN) DOM1: [ 4.004354] lr : 0xff80083ac810 (XEN) DOM1: [ 4.008955] sp : ff800800bba0 (XEN) DOM1: [ 4.013382] x29: ff800800bba0 x28: (XEN) DOM1: [ 4.019805] x27: ff800864f068 x26: ff80086ba000 (XEN) DOM1: [ 4.026228] x25: ffc031564980 x24: ff800856e0c0 (XEN) DOM1: [ 4.032651] x23: ffc03e8eec00 x22: ffc03e8eec10 (XEN) DOM1: [ 4.039074] x21: ffc03e8bf500 x20: ffc03e8bf800 (XEN) DOM1: [ 4.045497] x19: x18: (XEN) DOM1: [ 4.051921] x17: x16: (XEN) DOM1: [ 4.058344] x15: ff8008678548 x14: (XEN) DOM1: [ 4.064767] x13: 0018 x12: 0101010101010101 (XEN) DOM1: [ 4.071190] x11: 0020 x10: 0101010101010101 (XEN) DOM1: [ 4.077613] x9 : x8 : ffc031564c00 (XEN) DOM1: [ 4.084036] x7 : x6 : 003f (XEN) DOM1: [ 4.090459] x5 : 0002 x4 : ffc03e83b4c0 (XEN) DOM1: [ 4.096883] x3 : x2 : (XEN) DOM1: [ 4.103306] x1 : ffc03e8bf000 x0 : ff800800d048 (XEN) DOM1: [ 4.109729] Call trace: (XEN) DOM1: [ 4.113290] 0xff80083ac864 (XEN) DOM1: [ 4.117541] 0xff800832e3b8 (XEN) DOM1: [ 4.121795] 0xff800832c49c (XEN) DOM1: [ 4.126047] 0xff800832c6bc (XEN) DOM1: [ 4.130301] 0xff800832c808 (XEN) DOM1: [ 4.134554] 0xff800832a208 (XEN) DOM1: [ 4.138807] 0xff800832bd38 (XEN) DOM1: [ 4.143060] 0xff800832b5d8 (XEN) DOM1: [ 4.147314] 0xff800832d1f0 (XEN) DOM1: [ 4.151567] 0xff800832e318 (XEN) DOM1: [ 4.155820] 0xff800861d5f8 (XEN) DOM1: [ 4.160073] 0xff800808397c (XEN) DOM1: [ 4.164326] 0xff8008600db4 (XEN) DOM1: [ 4.168580] 0xff80085078c0 (XEN) DOM1: [ 4.172833] 0xff8008084c30 (XEN) DOM1: [ 4.177091] Code: b9000ea0 d5033e9f f9400ea0 91012000 (b91f) (XEN) DOM1: [ 4.184298] ---[ end trace 7dc5f6b878cccbfa ]--- (XEN) DOM1: [ 4.191546] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b I uploaded on pastebin.com the u-boot env settings [0], my device passthrough partial dts [1], and the whole log of boot messages from xen, Dom0 and DomU [2]. I don't know for sure what caused the kernel panic you are seeing, This is mostly likely because Linux is trying to access a region that is not mapped in stage-2. You can rebuild Xen with debug enabled and you should see a message "traps.c:..." telling the exact physical address accessed. In general I would recommend to build Xen with debug enabled during development as the hypervisor will give you more information of what's going on. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 146973: regressions - FAIL
flight 146973 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146973/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z1 days 11 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days5 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.
On Wed, 12 Feb 2020, Andrei Cherechesu wrote: > Hello, > > > I applied your direct-map patch, Stefano, on top of RELEASE-4.13.0 > Xen. FYI I am working on a direct-map patch series but it is still work-in-progress: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git direct-map-1 There are a few fixes on top of the original direct-map patch I sent. > I also took your advice and used the Imagebuilder tool to setup my > u-boot environment. I modified the tool to allow SDCard booting and > tweaked the parameters a little to fit our platforms, also introducing > support to add “direct-map” parameter in specific /chosen/DomU node > and “xen,passthrough” in the host dts. The tool is very helpful and > allows me to quickly change the u-boot environment without manually > entering all the fdt formatting commands. That's great to hear :-) For your information, if you have any changes that are worth upstreaming, I'd be happy to take patches for imagebuilder. The mailing list for that is viryaos-disc...@lists.sourceforge.net. > The dom0less booting is successful, Good! I know it is not easy to setup a dom0less system. I am trying to build tools and features to make it easier going forward. > however, when I try to passthrough any device (I tried with ethernet > card and uSDHC) I get a kernel panic in DomU when it tries to probe > the driver, because of an unhandled > > fault: > > (XEN) DOM1: [ 3.883482] sdhci: Secure Digital Host Controller Interface > driver > (XEN) DOM1: [ 3.891021] sdhci: Copyright(c) Pierre Ossman > (XEN) DOM1: [ 3.896389] sdhci-pltfm: SDHCI platform and OF driver helper > (XEN) DOM1: [ 3.903298] Unhandled fault at 0xff800800d048 > (XEN) DOM1: [ 3.909021] Mem abort info: > (XEN) DOM1: [ 3.912863] ESR = 0x9600 > (XEN) DOM1: [ 3.917019] Exception class = DABT (current EL), IL = 32 bits > (XEN) DOM1: [ 3.924115] SET = 0, FnV = 0 > (XEN) DOM1: [ 3.928206] EA = 0, S1PTW = 0 > (XEN) DOM1: [ 3.932457] Data abort info: > (XEN) DOM1: [ 3.936514] ISV = 0, ISS = 0x > (XEN) DOM1: [ 3.941398] CM = 0, WnR = 0 > (XEN) DOM1: [ 3.945481] swapper pgtable: 4k pages, 39-bit VAs, pgdp = > (ptrval) > (XEN) DOM1: [ 3.953532] [ff800800d048] pgd=bfffe803, > pud=bfffe803, pmd=bfffd803, pte=00e8402f0f07 > (XEN) DOM1: [ 3.965278] Internal error: ttbr address size fault: 9600 > [#1] PREEMPT SMP > (XEN) DOM1: [ 3.973546] Modules linked in: > (XEN) DOM1: [ 3.977709] Process swapper/0 (pid: 1, stack limit = > 0x(ptrval)) > (XEN) DOM1: [ 3.985525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.19.59-rt24+g00334f2 #1 > (XEN) DOM1: [ 3.993855] pstate: 6005 (nZCv daif -PAN -UAO) > (XEN) DOM1: [ 3.999755] pc : 0xff80083ac864 > (XEN) DOM1: [ 4.004354] lr : 0xff80083ac810 > (XEN) DOM1: [ 4.008955] sp : ff800800bba0 > (XEN) DOM1: [ 4.013382] x29: ff800800bba0 x28: > (XEN) DOM1: [ 4.019805] x27: ff800864f068 x26: ff80086ba000 > (XEN) DOM1: [ 4.026228] x25: ffc031564980 x24: ff800856e0c0 > (XEN) DOM1: [ 4.032651] x23: ffc03e8eec00 x22: ffc03e8eec10 > (XEN) DOM1: [ 4.039074] x21: ffc03e8bf500 x20: ffc03e8bf800 > (XEN) DOM1: [ 4.045497] x19: x18: > (XEN) DOM1: [ 4.051921] x17: x16: > (XEN) DOM1: [ 4.058344] x15: ff8008678548 x14: > (XEN) DOM1: [ 4.064767] x13: 0018 x12: 0101010101010101 > (XEN) DOM1: [ 4.071190] x11: 0020 x10: 0101010101010101 > (XEN) DOM1: [ 4.077613] x9 : x8 : ffc031564c00 > (XEN) DOM1: [ 4.084036] x7 : x6 : 003f > (XEN) DOM1: [ 4.090459] x5 : 0002 x4 : ffc03e83b4c0 > (XEN) DOM1: [ 4.096883] x3 : x2 : > (XEN) DOM1: [ 4.103306] x1 : ffc03e8bf000 x0 : ff800800d048 > (XEN) DOM1: [ 4.109729] Call trace: > (XEN) DOM1: [ 4.113290] 0xff80083ac864 > (XEN) DOM1: [ 4.117541] 0xff800832e3b8 > (XEN) DOM1: [ 4.121795] 0xff800832c49c > (XEN) DOM1: [ 4.126047] 0xff800832c6bc > (XEN) DOM1: [ 4.130301] 0xff800832c808 > (XEN) DOM1: [ 4.134554] 0xff800832a208 > (XEN) DOM1: [ 4.138807] 0xff800832bd38 > (XEN) DOM1: [ 4.143060] 0xff800832b5d8 > (XEN) DOM1: [ 4.147314] 0xff800832d1f0 > (XEN) DOM1: [ 4.151567] 0xff800832e318 > (XEN) DOM1: [ 4.155820] 0xff800861d5f8 > (XEN) DOM1: [ 4.160073] 0xff800808397c > (XEN) DOM1: [ 4.164326] 0xff8008600db4 > (XEN) DOM1: [ 4.168580] 0xff80085078c0 > (XEN) DOM1: [ 4.172833] 0xff8008084c30 > (XEN) DOM1: [ 4.177091] Code: b9000ea0 d5033e9f f9400ea0 91012000 > (b91f) > (XEN) DOM1: [ 4.184298] ---[ end trace 7dc5f6b878cccbfa ]--- > (XEN) DOM1: [
Re: [Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask
On 12/02/2020 17:49, Roger Pau Monne wrote: Hello, Hi Roger, Commit: 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 x86/smp: use APIC ALLBUT destination shorthand when possible There is a more subtle problem introduced by this patch. I thought I would mention it here just in case this affect the approach you have chosen in this series. get_cpu_maps() is used by stop_machine_run() to serialize the callers. If the latter fails to acquire the lock, it will bail out. Unfortunately, rcu_barrier() is implemented using stop_machine_run() and will be turned to pretty much a NOP if the latter fails (e.g the lock cannot be acquired). This means that the rcu_barrier() will not do the expected job and potentially introduce unknown issues (e.g use-after-free...). Before your patch, it would have been pretty hard to hit the problem above. After, you can race more easily with rcu_barrier() as sending IPI is pretty common. Sadly, I don't have a suggestion yet how to fix this problem. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 146968: regressions - FAIL
flight 146968 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z0 days 10 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
[Xen-devel] [linux-linus test] 146904: regressions - FAIL
flight 146904 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/146904/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 133580 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 133580 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 133580 test-amd64-amd64-xl-credit1 12 guest-start fail REGR. vs. 133580 test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133580 build-i386-pvops 6 kernel-build fail REGR. vs. 133580 test-arm64-arm64-xl-credit2 12 guest-start fail REGR. vs. 133580 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 133580 test-armhf-armhf-xl-credit1 12 guest-start fail REGR. vs. 133580 test-armhf-armhf-xl-credit2 12 guest-start fail REGR. vs. 133580 test-arm64-arm64-xl-xsm 15 guest-stop fail in 146850 REGR. vs. 133580 build-i386-xsm6 xen-build fail in 146850 REGR. vs. 133580 build-amd64-xsm 6 xen-build fail in 146850 REGR. vs. 133580 build-amd64 6 xen-build fail in 146850 REGR. vs. 133580 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl 16 guest-start/debian.repeat fail in 146850 pass in 146904 test-arm64-arm64-xl-xsm 12 guest-startfail pass in 146850 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 12 guest-start fail REGR. vs. 133580 test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1)blocked in 146850 n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-pair 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked in 146850 n/a build-amd64-libvirt 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-libvirt 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-pygrub 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1)blocked in 146850 n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 146850 n/a test-amd64-amd64-examine 1 build-check(1) blocked in 146850 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a
[Xen-devel] [xen-unstable-smoke test] 146963: regressions - FAIL
flight 146963 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146963/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z1 days Failing since146893 2020-02-11 20:01:02 Z0 days9 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
Re: [Xen-devel] [PATCH 4/4] x86/hyperv: L0 assisted TLB flush
On Wed, Feb 12, 2020 at 04:09:18PM +, Wei Liu wrote:
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
>
> Pick the most efficient hypercalls available.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hyperv/Makefile | 1 +
> xen/arch/x86/guest/hyperv/private.h | 9 ++
> xen/arch/x86/guest/hyperv/tlb.c | 172 +++-
> xen/arch/x86/guest/hyperv/util.c| 72
> 4 files changed, 253 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/x86/guest/hyperv/util.c
>
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> index 18902c33e9..0e39410968 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1,2 +1,3 @@
> obj-y += hyperv.o
> obj-y += tlb.o
> +obj-y += util.o
> diff --git a/xen/arch/x86/guest/hyperv/private.h
> b/xen/arch/x86/guest/hyperv/private.h
> index 78e52f74ce..311f060495 100644
> --- a/xen/arch/x86/guest/hyperv/private.h
> +++ b/xen/arch/x86/guest/hyperv/private.h
> @@ -24,12 +24,21 @@
>
> #include
> #include
> +#include
>
> DECLARE_PER_CPU(void *, hv_input_page);
> DECLARE_PER_CPU(void *, hv_vp_assist);
> DECLARE_PER_CPU(uint32_t, hv_vp_index);
>
> +static inline uint32_t hv_vp_index(int cpu)
unsigned int for cpu.
> +{
> +return per_cpu(hv_vp_index, cpu);
> +}
> +
> int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
> unsigned int flags);
>
> +/* Returns number of banks, -ev if error */
> +int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
> +
> #endif /* __XEN_HYPERV_PRIVIATE_H__ */
> diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
> index 48f527229e..99b789d9e9 100644
> --- a/xen/arch/x86/guest/hyperv/tlb.c
> +++ b/xen/arch/x86/guest/hyperv/tlb.c
> @@ -19,15 +19,185 @@
> * Copyright (c) 2020 Microsoft.
> */
>
> +#include
> #include
> #include
>
> +#include
> +#include
> +#include
> +
> #include "private.h"
>
> +/*
> + * It is possible to encode up to 4096 pages using the lower 12 bits
> + * in an element of gva_list
> + */
> +#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
> +#define ORDER_TO_BYTES(order) ((1ul << (order)) * PAGE_SIZE)
There are already some conversion functions in xen/mm.h
(get_order_from_{bytes/pages}), maybe you could add a
get_bytes_from_order helper there?
> +
> +static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
> + unsigned int order)
> +{
> +unsigned long start = (unsigned long)va;
> +unsigned long end = start + ORDER_TO_BYTES(order) - 1;
> +unsigned int n = 0;
> +
> +do {
> +unsigned long remain = end > start ? end - start : 0;
I don't think you can get here with end == start?
As that's the condition of the loop, and order 0 is going to set
end = start + 4096 - 1.
> +
> +gva_list[n] = start & PAGE_MASK;
> +
> +/*
> + * Use lower 12 bits to encode the number of additional pages
> + * to flush
> + */
> +if ( remain >= HV_TLB_FLUSH_UNIT )
> +{
> +gva_list[n] |= ~PAGE_MASK;
> +start += HV_TLB_FLUSH_UNIT;
> +}
> +else if ( remain )
> +{
> +gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
> +start = end;
> +}
> +
> +n++;
> +} while ( start < end );
> +
> +return n;
> +}
> +
> +static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
> + unsigned int flags)
> +{
> +struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
> +int nr_banks;
> +unsigned int max_gvas;
> +unsigned int order = flags & FLUSH_ORDER_MASK;
> +uint64_t ret;
> +
> +ASSERT(flush);
> +ASSERT(!local_irq_is_enabled());
Can you turn this into an if condition with ASSERT_UNREACHABLE and
return ~0ULL? (as I think that signals an error).
> +
> +if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
> +return ~0ULL;
> +
> +flush->address_space = 0;
> +flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
> +if ( !(flags & FLUSH_TLB_GLOBAL) )
> +flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
> +
> +flush->hv_vp_set.valid_bank_mask = 0;
> +flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
> +
> +nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
> +if ( nr_banks < 0 )
> +return ~0ULL;
> +
> +max_gvas =
> +(PAGE_SIZE - sizeof(*flush) - nr_banks *
> + sizeof(flush->hv_vp_set.bank_contents[0])) /
> +sizeof(uint64_t); /* gva is represented as uint64_t */
> +
> +/*
> + * Flush the entire address space if va is NULL or if there is not
> + *
Re: [Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask
On 12/02/2020 18:01, Roger Pau Monné wrote: > On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote: >> On 12/02/2020 17:49, Roger Pau Monne wrote: >>> Hello, >>> >>> Commit: >>> >>> 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 >>> x86/smp: use APIC ALLBUT destination shorthand when possible >>> >>> Introduced a bogus usage of the scratch cpumask: it was used in a >>> function that could be called from interrupt context, and hence using >>> the scratch cpumask there is not safe. Patch #2 is a fix for that usage. >>> >>> Patch #3 adds some debug infrastructure to make sure the scratch cpumask >>> is used in the right context, and hence should prevent further missuses. >>> >>> Thanks, Roger. >> >> Hi Roger, >> >> Do you still want me to test the "panic" patch ? >> Or test this series instead ? > > I've been able to trigger this myself, so if you can give a try to the > series in order to assert it fixes your issue that would be great. > > Thanks. > Sure, compiling now, will report back tomorrow morning. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86/hyperv: skeleton for L0 assisted TLB flush
On Wed, Feb 12, 2020 at 04:09:17PM +, Wei Liu wrote:
> Implement a basic hook for L0 assisted TLB flush. The hook needs to
> check if prerequisites are met. If they are not met, it returns an error
> number to fall back to native flushes.
>
> Introduce a new variable to indicate if hypercall page is ready.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/guest/hyperv/Makefile | 1 +
> xen/arch/x86/guest/hyperv/hyperv.c | 17
> xen/arch/x86/guest/hyperv/private.h | 4 +++
> xen/arch/x86/guest/hyperv/tlb.c | 41 +
> 4 files changed, 63 insertions(+)
> create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
>
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> index 68170109a9..18902c33e9 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1 +1,2 @@
> obj-y += hyperv.o
> +obj-y += tlb.o
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> b/xen/arch/x86/guest/hyperv/hyperv.c
> index b7044f7193..1cdc88e27c 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
> DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
> DEFINE_PER_CPU_READ_MOSTLY(uint32_t, hv_vp_index);
>
> +static bool __read_mostly hv_hcall_page_ready;
> +
> static uint64_t generate_guest_id(void)
> {
> union hv_guest_os_id id = {};
> @@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
> BUG_ON(!hypercall_msr.enable);
>
> set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
> +
> +hv_hcall_page_ready = true;
I guess filling the hypercall page in the probe function like it's
done for Xen is too early for HyperV, and hence you need this
safeguard?
TBH, maybe it would be best (and safer) to prevent using any hooks
until setup has been called, and hence this check could be pulled into
the generic hook?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask
On Wed, Feb 12, 2020 at 05:53:39PM +0100, Sander Eikelenboom wrote: > On 12/02/2020 17:49, Roger Pau Monne wrote: > > Hello, > > > > Commit: > > > > 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 > > x86/smp: use APIC ALLBUT destination shorthand when possible > > > > Introduced a bogus usage of the scratch cpumask: it was used in a > > function that could be called from interrupt context, and hence using > > the scratch cpumask there is not safe. Patch #2 is a fix for that usage. > > > > Patch #3 adds some debug infrastructure to make sure the scratch cpumask > > is used in the right context, and hence should prevent further missuses. > > > > Thanks, Roger. > > Hi Roger, > > Do you still want me to test the "panic" patch ? > Or test this series instead ? I've been able to trigger this myself, so if you can give a try to the series in order to assert it fixes your issue that would be great. Thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/4] x86/hypervisor: pass flags to hypervisor_flush_tlb
On Wed, Feb 12, 2020 at 04:09:16PM +, Wei Liu wrote: > Hyper-V's L0 assisted flush has fine-grained control over what gets > flushed. We need all the flags available to make the best decisions > possible. > > No functional change because Xen's implementation doesn't care about > what is passed to it. While it's certainly fine to pass a flags field with more information, the flush flags for Xen can also contain FLUSH_CACHE, FLUSH_VCPU_STATE or FLUSH_ROOT_PGTBL, can you add an assert that those never get passed to the flush hook? IMO we should define a mask with FLUSH_TLB, FLUSH_TLB_GLOBAL, FLUSH_VA_VALID and FLUSH_ORDER_MASK and assert that those are the only valid flags to be used for the hypervisor assisted flush hook. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask
On 12/02/2020 17:49, Roger Pau Monne wrote: > Hello, > > Commit: > > 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 > x86/smp: use APIC ALLBUT destination shorthand when possible > > Introduced a bogus usage of the scratch cpumask: it was used in a > function that could be called from interrupt context, and hence using > the scratch cpumask there is not safe. Patch #2 is a fix for that usage. > > Patch #3 adds some debug infrastructure to make sure the scratch cpumask > is used in the right context, and hence should prevent further missuses. > > Thanks, Roger. Hi Roger, Do you still want me to test the "panic" patch ? Or test this series instead ? -- Sander > Roger Pau Monne (3): > x86/smp: unify header includes in smp.h > x86/smp: use a dedicated scratch cpumask in send_IPI_mask > x86: add accessors for scratch cpu mask > > xen/arch/x86/io_apic.c| 6 -- > xen/arch/x86/irq.c| 13 ++--- > xen/arch/x86/mm.c | 30 +- > xen/arch/x86/msi.c| 4 +++- > xen/arch/x86/smp.c| 14 +- > xen/arch/x86/smpboot.c| 33 - > xen/include/asm-x86/smp.h | 15 +++ > 7 files changed, 94 insertions(+), 21 deletions(-) > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] x86/hyperv: misc cleanup
On Wed, Feb 12, 2020 at 04:09:15PM +, Wei Liu wrote: > Change hv_vp_index to use uint32_t because that is what is defined in TLFS. > > Add "_addr" suffix to hv_do_rep_hypercall's parameters. Being of type paddr_t I'm unsure the _addr suffix adds any value to the name. > > Signed-off-by: Wei Liu LGTM (and I'm certainly not going to oppose to the _addr suffix): Reviewed-by: Roger Pau Monné Thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/3] x86/smp: use a dedicated scratch cpumask in send_IPI_mask
Using scratch_cpumask in send_IPI_mak is not safe because it can be
called from interrupt context, and hence Xen would have to make sure
all the users of the scratch cpumask disable interrupts while using
it.
Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while using.
Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when
possible')
Reported-by: Sander Eikelenboom
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/smp.c | 14 +-
xen/arch/x86/smpboot.c | 9 -
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 9bc925616a..384c3ba924 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -59,6 +59,7 @@ static void send_IPI_shortcut(unsigned int shortcut, int
vector,
apic_write(APIC_ICR, cfg);
}
+DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
/*
* send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
* excluding the local CPU. @cpumask may be empty.
@@ -67,7 +68,8 @@ static void send_IPI_shortcut(unsigned int shortcut, int
vector,
void send_IPI_mask(const cpumask_t *mask, int vector)
{
bool cpus_locked = false;
-cpumask_t *scratch = this_cpu(scratch_cpumask);
+cpumask_t *scratch = this_cpu(send_ipi_cpumask);
+unsigned long flags;
/*
* This can only be safely used when no CPU hotplug or unplug operations
@@ -81,7 +83,15 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
local_irq_is_enabled() && (cpus_locked = get_cpu_maps()) &&
(park_offline_cpus ||
cpumask_equal(_online_map, _present_map)) )
+{
+/*
+ * send_IPI_mask can be called from interrupt context, and hence we
+ * need to disable interrupts in order to protect the per-cpu
+ * send_ipi_cpumask while being used.
+ */
+local_irq_save(flags);
cpumask_or(scratch, mask, cpumask_of(smp_processor_id()));
+}
else
{
if ( cpus_locked )
@@ -89,6 +99,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
put_cpu_maps();
cpus_locked = false;
}
+local_irq_save(flags);
cpumask_clear(scratch);
}
@@ -97,6 +108,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
else
alternative_vcall(genapic.send_IPI_mask, mask, vector);
+local_irq_restore(flags);
if ( cpus_locked )
put_cpu_maps();
}
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index e83e4564a4..82e89201b3 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -57,6 +57,9 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
static cpumask_t scratch_cpu0mask;
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, send_ipi_cpumask);
+static cpumask_t send_ipi_cpu0mask;
+
cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
@@ -930,6 +933,8 @@ static void cpu_smpboot_free(unsigned int cpu, bool remove)
FREE_CPUMASK_VAR(per_cpu(cpu_core_mask, cpu));
if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
FREE_CPUMASK_VAR(per_cpu(scratch_cpumask, cpu));
+if ( per_cpu(send_ipi_cpumask, cpu) != _ipi_cpu0mask )
+FREE_CPUMASK_VAR(per_cpu(send_ipi_cpumask, cpu));
}
cleanup_cpu_root_pgt(cpu);
@@ -1034,7 +1039,8 @@ static int cpu_smpboot_alloc(unsigned int cpu)
if ( !(cond_zalloc_cpumask_var(_cpu(cpu_sibling_mask, cpu)) &&
cond_zalloc_cpumask_var(_cpu(cpu_core_mask, cpu)) &&
- cond_alloc_cpumask_var(_cpu(scratch_cpumask, cpu))) )
+ cond_alloc_cpumask_var(_cpu(scratch_cpumask, cpu)) &&
+ cond_alloc_cpumask_var(_cpu(send_ipi_cpumask, cpu))) )
goto out;
rc = 0;
@@ -1175,6 +1181,7 @@ void __init smp_prepare_boot_cpu(void)
cpumask_set_cpu(cpu, _present_map);
#if NR_CPUS > 2 * BITS_PER_LONG
per_cpu(scratch_cpumask, cpu) = _cpu0mask;
+per_cpu(send_ipi_cpumask, cpu) = _ipi_cpu0mask;
#endif
get_cpu_info()->use_pv_cr3 = false;
--
2.25.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] x86/smp: unify header includes in smp.h
Unify the two adjacent header includes that are both gated with ifndef __ASSEMBLY__. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/include/asm-x86/smp.h | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h index 1aa55d41e1..92d69a5ea0 100644 --- a/xen/include/asm-x86/smp.h +++ b/xen/include/asm-x86/smp.h @@ -5,13 +5,10 @@ * We need the APIC definitions automatically as part of 'smp.h' */ #ifndef __ASSEMBLY__ +#include #include #include #include -#endif - -#ifndef __ASSEMBLY__ -#include #include #endif -- 2.25.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/3] x86: fixes/improvements for scratch cpumask
Hello, Commit: 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 x86/smp: use APIC ALLBUT destination shorthand when possible Introduced a bogus usage of the scratch cpumask: it was used in a function that could be called from interrupt context, and hence using the scratch cpumask there is not safe. Patch #2 is a fix for that usage. Patch #3 adds some debug infrastructure to make sure the scratch cpumask is used in the right context, and hence should prevent further missuses. Thanks, Roger. Roger Pau Monne (3): x86/smp: unify header includes in smp.h x86/smp: use a dedicated scratch cpumask in send_IPI_mask x86: add accessors for scratch cpu mask xen/arch/x86/io_apic.c| 6 -- xen/arch/x86/irq.c| 13 ++--- xen/arch/x86/mm.c | 30 +- xen/arch/x86/msi.c| 4 +++- xen/arch/x86/smp.c| 14 +- xen/arch/x86/smpboot.c| 33 - xen/include/asm-x86/smp.h | 15 +++ 7 files changed, 94 insertions(+), 21 deletions(-) -- 2.25.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] x86: add accessors for scratch cpu mask
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nested usage of the scratch mask and usage
in interrupt context.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/io_apic.c| 6 --
xen/arch/x86/irq.c| 13 ++---
xen/arch/x86/mm.c | 30 +-
xen/arch/x86/msi.c| 4 +++-
xen/arch/x86/smpboot.c| 24
xen/include/asm-x86/smp.h | 10 ++
6 files changed, 72 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index e98e08e9c8..4ee261b632 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2236,10 +2236,11 @@ int io_apic_set_pci_routing (int ioapic, int pin, int
irq, int edge_level, int a
entry.vector = vector;
if (cpumask_intersects(desc->arch.cpu_mask, TARGET_CPUS)) {
-cpumask_t *mask = this_cpu(scratch_cpumask);
+cpumask_t *mask = get_scratch_cpumask();
cpumask_and(mask, desc->arch.cpu_mask, TARGET_CPUS);
SET_DEST(entry, logical, cpu_mask_to_apicid(mask));
+put_scratch_cpumask();
} else {
printk(XENLOG_ERR "IRQ%d: no target CPU (%*pb vs %*pb)\n",
irq, CPUMASK_PR(desc->arch.cpu_mask), CPUMASK_PR(TARGET_CPUS));
@@ -2433,10 +2434,11 @@ int ioapic_guest_write(unsigned long physbase, unsigned
int reg, u32 val)
if ( cpumask_intersects(desc->arch.cpu_mask, TARGET_CPUS) )
{
-cpumask_t *mask = this_cpu(scratch_cpumask);
+cpumask_t *mask = get_scratch_cpumask();
cpumask_and(mask, desc->arch.cpu_mask, TARGET_CPUS);
SET_DEST(rte, logical, cpu_mask_to_apicid(mask));
+put_scratch_cpumask();
}
else
{
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index cc2eb8e925..7ecf5376e3 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -196,7 +196,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
{
unsigned int cpu, old_vector, irq = desc->irq;
unsigned int vector = desc->arch.vector;
-cpumask_t *tmp_mask = this_cpu(scratch_cpumask);
+cpumask_t *tmp_mask = get_scratch_cpumask();
BUG_ON(!valid_irq_vector(vector));
@@ -223,7 +223,10 @@ static void _clear_irq_vector(struct irq_desc *desc)
trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, tmp_mask);
if ( likely(!desc->arch.move_in_progress) )
+{
+put_scratch_cpumask();
return;
+}
/* If we were in motion, also clear desc->arch.old_vector */
old_vector = desc->arch.old_vector;
@@ -236,6 +239,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
per_cpu(vector_irq, cpu)[old_vector] = ~irq;
}
+put_scratch_cpumask();
release_old_vec(desc);
desc->arch.move_in_progress = 0;
@@ -1152,10 +1156,11 @@ static void irq_guest_eoi_timer_fn(void *data)
break;
case ACKTYPE_EOI:
-cpu_eoi_map = this_cpu(scratch_cpumask);
+cpu_eoi_map = get_scratch_cpumask();
cpumask_copy(cpu_eoi_map, action->cpu_eoi_map);
spin_unlock_irq(>lock);
on_selected_cpus(cpu_eoi_map, set_eoi_ready, desc, 0);
+put_scratch_cpumask();
return;
}
@@ -2531,12 +2536,12 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
unsigned int irq;
static int warned;
struct irq_desc *desc;
+cpumask_t *affinity = get_scratch_cpumask();
for ( irq = 0; irq < nr_irqs; irq++ )
{
bool break_affinity = false, set_affinity = true;
unsigned int vector;
-cpumask_t *affinity = this_cpu(scratch_cpumask);
if ( irq == 2 )
continue;
@@ -2640,6 +2645,8 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
irq, CPUMASK_PR(affinity));
}
+put_scratch_cpumask();
+
/* That doesn't seem sufficient. Give it 1ms. */
local_irq_enable();
mdelay(1);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9b33829084..bded19717b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1271,7 +1271,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
(l1e_owner == pg_owner) )
{
struct vcpu *v;
-cpumask_t *mask = this_cpu(scratch_cpumask);
+cpumask_t *mask = get_scratch_cpumask();
cpumask_clear(mask);
@@ -1288,6 +1288,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
if ( !cpumask_empty(mask) )
flush_tlb_mask(mask);
+put_scratch_cpumask();
}
#endif /* CONFIG_PV_LDT_PAGING */
put_page(page);
@@ -2912,7 +2913,7 @@ static int _get_page_type(struct page_info *page,
unsigned long type,
[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Bug not present: dacb80f9757c011161cec6609f39837c9ea8caa8 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146964/ commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/146964.bisection-summary --basis-template=146882 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build Searching for failure / basis pass: 146950 fail [host=laxton0] / 146882 [host=rochester0] 146871 [host=rochester0] 146838 [host=laxton1] 146835 [host=rochester1] 146832 [host=rochester0] 146767 ok. Failure / basis pass flights: 146950 / 146767 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544 Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#72dbcf0c065037dddb591a072c4f8f16fe888ea8-af09b7d79cb8ae7498882e61efec75486eb69544 Loaded 5001 nodes in revision graph Searching for test results: 146767 pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8 146832 [host=rochester0] 146835 [host=rochester1] 146838 [host=laxton1] 146871 [host=rochester0] 146882 [host=rochester0] 146893 [host=rochester1] 146899 [host=rochester0] 146909 [host=rochester1] 146964 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 146947 [host=laxton1] 146918 [host=laxton1] 146935 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544 146948 [host=laxton1] 146925 [host=laxton1] 146949 pass 933ebad2470a169504799a1d95b8e410bd9847ef 72dbcf0c065037dddb591a072c4f8f16fe888ea8 146951 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544 146952 pass 933ebad2470a169504799a1d95b8e410bd9847ef 3dd724dff085e13ad520f8e35aea717db2ff07d0 146928 [host=laxton1] 146953 pass 933ebad2470a169504799a1d95b8e410bd9847ef 4e9929f5bde62e19653a4c7f5792648f56ef35ab 146954 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 146955 pass 933ebad2470a169504799a1d95b8e410bd9847ef 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c 146939 [host=laxton1] 146940 [host=laxton1] 146956 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8 146941 [host=laxton1] 146942 [host=laxton1] 146957 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 146958 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8 146950 fail 933ebad2470a169504799a1d95b8e410bd9847ef af09b7d79cb8ae7498882e61efec75486eb69544 146959 fail 933ebad2470a169504799a1d95b8e410bd9847ef 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 146961 pass 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8 Searching for interesting versions Result found: flight 146767 (pass), for basis pass Result found: flight 146935 (fail), for basis failure Repro found: flight 146949 (pass), for basis pass Repro found: flight 146950 (fail), for basis failure 0 revisions at 933ebad2470a169504799a1d95b8e410bd9847ef dacb80f9757c011161cec6609f39837c9ea8caa8 No revisions left to test, checking graph state. Result found: flight 146956 (pass), for last pass Result found: flight 146957 (fail), for first failure Repro found: flight 146958 (pass), for last pass Repro found: flight 146959 (fail), for first failure Repro found: flight 146961 (pass),
[Xen-devel] [PATCH 1/4] x86/hyperv: misc cleanup
Change hv_vp_index to use uint32_t because that is what is defined in TLFS.
Add "_addr" suffix to hv_do_rep_hypercall's parameters.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 2 +-
xen/arch/x86/guest/hyperv/private.h | 2 +-
xen/include/asm-x86/guest/hyperv-hcall.h | 5 +++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 70f4cd5ae0..b7044f7193 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -31,7 +31,7 @@
struct ms_hyperv_info __read_mostly ms_hyperv;
DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
-DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
+DEFINE_PER_CPU_READ_MOSTLY(uint32_t, hv_vp_index);
static uint64_t generate_guest_id(void)
{
diff --git a/xen/arch/x86/guest/hyperv/private.h
b/xen/arch/x86/guest/hyperv/private.h
index 956eff831f..eb14ea43e5 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -26,6 +26,6 @@
DECLARE_PER_CPU(void *, hv_input_page);
DECLARE_PER_CPU(void *, hv_vp_assist);
-DECLARE_PER_CPU(unsigned int, hv_vp_index);
+DECLARE_PER_CPU(uint32_t, hv_vp_index);
#endif /* __XEN_HYPERV_PRIVIATE_H__ */
diff --git a/xen/include/asm-x86/guest/hyperv-hcall.h
b/xen/include/asm-x86/guest/hyperv-hcall.h
index 4d3b131b3a..3396caccdd 100644
--- a/xen/include/asm-x86/guest/hyperv-hcall.h
+++ b/xen/include/asm-x86/guest/hyperv-hcall.h
@@ -61,7 +61,8 @@ static inline uint64_t hv_do_fast_hypercall(uint16_t code,
static inline uint64_t hv_do_rep_hypercall(uint16_t code, uint16_t rep_count,
uint16_t varhead_size,
- paddr_t input, paddr_t output)
+ paddr_t input_addr,
+ paddr_t output_addr)
{
uint64_t control = code;
uint64_t status;
@@ -71,7 +72,7 @@ static inline uint64_t hv_do_rep_hypercall(uint16_t code,
uint16_t rep_count,
control |= (uint64_t)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
do {
-status = hv_do_hypercall(control, input, output);
+status = hv_do_hypercall(control, input_addr, output_addr);
if ( (status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS )
break;
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/4] x86/hyperv: skeleton for L0 assisted TLB flush
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/Makefile | 1 +
xen/arch/x86/guest/hyperv/hyperv.c | 17
xen/arch/x86/guest/hyperv/private.h | 4 +++
xen/arch/x86/guest/hyperv/tlb.c | 41 +
4 files changed, 63 insertions(+)
create mode 100644 xen/arch/x86/guest/hyperv/tlb.c
diff --git a/xen/arch/x86/guest/hyperv/Makefile
b/xen/arch/x86/guest/hyperv/Makefile
index 68170109a9..18902c33e9 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1 +1,2 @@
obj-y += hyperv.o
+obj-y += tlb.o
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index b7044f7193..1cdc88e27c 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -33,6 +33,8 @@ DEFINE_PER_CPU_READ_MOSTLY(void *, hv_input_page);
DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
DEFINE_PER_CPU_READ_MOSTLY(uint32_t, hv_vp_index);
+static bool __read_mostly hv_hcall_page_ready;
+
static uint64_t generate_guest_id(void)
{
union hv_guest_os_id id = {};
@@ -119,6 +121,8 @@ static void __init setup_hypercall_page(void)
BUG_ON(!hypercall_msr.enable);
set_fixmap_x(FIX_X_HYPERV_HCALL, mfn << PAGE_SHIFT);
+
+hv_hcall_page_ready = true;
}
static int setup_hypercall_pcpu_arg(void)
@@ -199,11 +203,24 @@ static void __init e820_fixup(struct e820map *e820)
panic("Unable to reserve Hyper-V hypercall range\n");
}
+static int flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int flags)
+{
+if ( !(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) )
+return -EOPNOTSUPP;
+
+if ( !hv_hcall_page_ready || !this_cpu(hv_input_page) )
+return -ENXIO;
+
+return hyperv_flush_tlb(mask, va, flags);
+}
+
static const struct hypervisor_ops __initdata ops = {
.name = "Hyper-V",
.setup = setup,
.ap_setup = ap_setup,
.e820_fixup = e820_fixup,
+.flush_tlb = flush_tlb,
};
/*
diff --git a/xen/arch/x86/guest/hyperv/private.h
b/xen/arch/x86/guest/hyperv/private.h
index eb14ea43e5..78e52f74ce 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -22,10 +22,14 @@
#ifndef __XEN_HYPERV_PRIVIATE_H__
#define __XEN_HYPERV_PRIVIATE_H__
+#include
#include
DECLARE_PER_CPU(void *, hv_input_page);
DECLARE_PER_CPU(void *, hv_vp_assist);
DECLARE_PER_CPU(uint32_t, hv_vp_index);
+int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int flags);
+
#endif /* __XEN_HYPERV_PRIVIATE_H__ */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
new file mode 100644
index 00..48f527229e
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -0,0 +1,41 @@
+/**
+ * arch/x86/guest/hyperv/tlb.c
+ *
+ * Support for TLB management using hypercalls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see
[Xen-devel] [PATCH 4/4] x86/hyperv: L0 assisted TLB flush
Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/Makefile | 1 +
xen/arch/x86/guest/hyperv/private.h | 9 ++
xen/arch/x86/guest/hyperv/tlb.c | 172 +++-
xen/arch/x86/guest/hyperv/util.c| 72
4 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/x86/guest/hyperv/util.c
diff --git a/xen/arch/x86/guest/hyperv/Makefile
b/xen/arch/x86/guest/hyperv/Makefile
index 18902c33e9..0e39410968 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1,2 +1,3 @@
obj-y += hyperv.o
obj-y += tlb.o
+obj-y += util.o
diff --git a/xen/arch/x86/guest/hyperv/private.h
b/xen/arch/x86/guest/hyperv/private.h
index 78e52f74ce..311f060495 100644
--- a/xen/arch/x86/guest/hyperv/private.h
+++ b/xen/arch/x86/guest/hyperv/private.h
@@ -24,12 +24,21 @@
#include
#include
+#include
DECLARE_PER_CPU(void *, hv_input_page);
DECLARE_PER_CPU(void *, hv_vp_assist);
DECLARE_PER_CPU(uint32_t, hv_vp_index);
+static inline uint32_t hv_vp_index(int cpu)
+{
+return per_cpu(hv_vp_index, cpu);
+}
+
int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
unsigned int flags);
+/* Returns number of banks, -ev if error */
+int cpumask_to_vpset(struct hv_vpset *vpset, const cpumask_t *mask);
+
#endif /* __XEN_HYPERV_PRIVIATE_H__ */
diff --git a/xen/arch/x86/guest/hyperv/tlb.c b/xen/arch/x86/guest/hyperv/tlb.c
index 48f527229e..99b789d9e9 100644
--- a/xen/arch/x86/guest/hyperv/tlb.c
+++ b/xen/arch/x86/guest/hyperv/tlb.c
@@ -19,15 +19,185 @@
* Copyright (c) 2020 Microsoft.
*/
+#include
#include
#include
+#include
+#include
+#include
+
#include "private.h"
+/*
+ * It is possible to encode up to 4096 pages using the lower 12 bits
+ * in an element of gva_list
+ */
+#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
+#define ORDER_TO_BYTES(order) ((1ul << (order)) * PAGE_SIZE)
+
+static unsigned int fill_gva_list(uint64_t *gva_list, const void *va,
+ unsigned int order)
+{
+unsigned long start = (unsigned long)va;
+unsigned long end = start + ORDER_TO_BYTES(order) - 1;
+unsigned int n = 0;
+
+do {
+unsigned long remain = end > start ? end - start : 0;
+
+gva_list[n] = start & PAGE_MASK;
+
+/*
+ * Use lower 12 bits to encode the number of additional pages
+ * to flush
+ */
+if ( remain >= HV_TLB_FLUSH_UNIT )
+{
+gva_list[n] |= ~PAGE_MASK;
+start += HV_TLB_FLUSH_UNIT;
+}
+else if ( remain )
+{
+gva_list[n] |= (remain - 1) >> PAGE_SHIFT;
+start = end;
+}
+
+n++;
+} while ( start < end );
+
+return n;
+}
+
+static uint64_t flush_tlb_ex(const cpumask_t *mask, const void *va,
+ unsigned int flags)
+{
+struct hv_tlb_flush_ex *flush = this_cpu(hv_input_page);
+int nr_banks;
+unsigned int max_gvas;
+unsigned int order = flags & FLUSH_ORDER_MASK;
+uint64_t ret;
+
+ASSERT(flush);
+ASSERT(!local_irq_is_enabled());
+
+if ( !(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED) )
+return ~0ULL;
+
+flush->address_space = 0;
+flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+if ( !(flags & FLUSH_TLB_GLOBAL) )
+flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+
+flush->hv_vp_set.valid_bank_mask = 0;
+flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
+
+nr_banks = cpumask_to_vpset(>hv_vp_set, mask);
+if ( nr_banks < 0 )
+return ~0ULL;
+
+max_gvas =
+(PAGE_SIZE - sizeof(*flush) - nr_banks *
+ sizeof(flush->hv_vp_set.bank_contents[0])) /
+sizeof(uint64_t); /* gva is represented as uint64_t */
+
+/*
+ * Flush the entire address space if va is NULL or if there is not
+ * enough space for gva_list.
+ */
+if ( !va || (ORDER_TO_BYTES(order) / HV_TLB_FLUSH_UNIT) > max_gvas )
+ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX, 0,
+ nr_banks, virt_to_maddr(flush), 0);
+else
+{
+uint64_t *gva_list = (uint64_t *)flush + sizeof(*flush) + nr_banks;
+unsigned int gvas = fill_gva_list(gva_list, va, order);
+
+ret = hv_do_rep_hypercall(HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX,
+ gvas, nr_banks, virt_to_maddr(flush), 0);
+}
+
+return ret;
+}
+
int hyperv_flush_tlb(const cpumask_t *mask, const void *va,
unsigned int flags)
{
-return -EOPNOTSUPP;
+unsigned long irq_flags;
+struct
[Xen-devel] [PATCH 0/4] Xen on Hyper-V: Implement L0 assisted TLB flush
Hi all This seris is based on Roger's L0 assisted flush series. I have done some testing against a Linux on Hyper-V in a 32-vcpu VM. All builds were done with -j32. Building Xen on Linux: real0m45.376s user2m28.156s sys 0m51.672s Building Xen on Linux on Xen on Hyper-V, no assisted flush: real3m8.762s user10m46.787s sys 30m14.492s Building Xen on Linux on Xen on Hyper-V, with assisted flush: real0m44.369s user3m16.231s sys 3m3.330s Building Linux x86_64_defconfig on Linux: real0m59.698s user21m14.014s sys 2m58.742s Building Linux x86_64_defconfig on Linux on Xen on Hyper-V, no assisted flush: real2m6.284s user31m18.706s sys 20m31.106s Building Linux x86_64_defconfig on Linux on Xen on Hyper-V, with assisted flush: real1m38.968s user28m40.398s sys 11m20.151s There are various degrees of improvement depending on the workload. Xen can perhaps be optmised a bit more because it currently doesn't pass the address space id (cr3) to Hyper-V, but that requires reworking TLB flush APIs within Xen. Wei. Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monné Cc: Michael Kelley Cc: Paul Durrant Wei Liu (4): x86/hyperv: misc cleanup x86/hypervisor: pass flags to hypervisor_flush_tlb x86/hyperv: skeleton for L0 assisted TLB flush x86/hyperv: L0 assisted TLB flush xen/arch/x86/guest/hyperv/Makefile | 2 + xen/arch/x86/guest/hyperv/hyperv.c | 19 +- xen/arch/x86/guest/hyperv/private.h | 15 +- xen/arch/x86/guest/hyperv/tlb.c | 211 +++ xen/arch/x86/guest/hyperv/util.c | 72 xen/arch/x86/guest/hypervisor.c | 4 +- xen/arch/x86/guest/xen/xen.c | 2 +- xen/arch/x86/smp.c | 2 +- xen/include/asm-x86/guest/hyperv-hcall.h | 5 +- xen/include/asm-x86/guest/hypervisor.h | 10 +- 10 files changed, 329 insertions(+), 13 deletions(-) create mode 100644 xen/arch/x86/guest/hyperv/tlb.c create mode 100644 xen/arch/x86/guest/hyperv/util.c -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/4] x86/hypervisor: pass flags to hypervisor_flush_tlb
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hypervisor.c| 4 ++--
xen/arch/x86/guest/xen/xen.c | 2 +-
xen/arch/x86/smp.c | 2 +-
xen/include/asm-x86/guest/hypervisor.h | 10 +-
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 47e938e287..2724fd9bad 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -75,10 +75,10 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
}
int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order)
+ unsigned int flags)
{
if ( ops.flush_tlb )
-return alternative_call(ops.flush_tlb, mask, va, order);
+return alternative_call(ops.flush_tlb, mask, va, flags);
return -ENOSYS;
}
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 5d3427a713..0eb1115c4d 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -324,7 +324,7 @@ static void __init e820_fixup(struct e820map *e820)
pv_shim_fixup_e820(e820);
}
-static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int flags)
{
return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
}
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 9bc925616a..2df21e396a 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -260,7 +260,7 @@ void flush_area_mask(const cpumask_t *mask, const void *va,
unsigned int flags)
if ( cpu_has_hypervisor &&
!(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
FLUSH_ORDER_MASK)) &&
- !hypervisor_flush_tlb(mask, va, flags & FLUSH_ORDER_MASK) )
+ !hypervisor_flush_tlb(mask, va, flags) )
{
if ( tlb_clk_enabled )
tlb_clk_enabled = false;
diff --git a/xen/include/asm-x86/guest/hypervisor.h
b/xen/include/asm-x86/guest/hypervisor.h
index 432e57c2a0..48d54735d2 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -35,7 +35,7 @@ struct hypervisor_ops {
/* Fix up e820 map */
void (*e820_fixup)(struct e820map *e820);
/* L0 assisted TLB flush */
-int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
order);
+int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int
flags);
};
#ifdef CONFIG_GUEST
@@ -48,11 +48,11 @@ void hypervisor_e820_fixup(struct e820map *e820);
/*
* L0 assisted TLB flush.
* mask: cpumask of the dirty vCPUs that should be flushed.
- * va: linear address to flush, or NULL for global flushes.
- * order: order of the linear address pointed by va.
+ * va: linear address to flush, or NULL for entire address space.
+ * flags: flags for flushing, including the order of va.
*/
int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order);
+ unsigned int flags);
#else
@@ -65,7 +65,7 @@ static inline int hypervisor_ap_setup(void) { return 0; }
static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
static inline void hypervisor_e820_fixup(struct e820map *e820) {}
static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
- unsigned int order)
+ unsigned int flags)
{
return -ENOSYS;
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] xsm: add Kconfig option for denied string
On 12/02/2020 09:32, Jan Beulich wrote: > On 11.02.2020 14:42, Sergey Dyasli wrote: >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -228,6 +228,14 @@ choice >> bool "SILO" if XSM_SILO >> endchoice >> >> +config XSM_DENIED_STRING >> +string "xen_version hypercall denied information replacement string" >> +default "" >> +depends on XSM > > Why would this string want to be configurable only in XSM- > enabled builds? For some reason I assumed that xsm_xen_version() is a no-op when CONFIG_XSM is undefined. I can now see that it doesn't depend on any config in which case the dependency (and #ifdef) should indeed be removed. -- Thanks, Sergey ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 146950: regressions - FAIL
flight 146950 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146950/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z0 days Failing since146893 2020-02-11 20:01:02 Z0 days8 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
Re: [Xen-devel] reported memory usage does not match real memory usage
Am Wed, 12 Feb 2020 11:53:25 +0100
schrieb Olaf Hering :
> Is there a formula to calculate that amount of extra memory, is this behavior
> documented somewhere?
With the script below, the formula may look like this:
- each vcpu needs 1MB extra memory
- each GB of a HVM domU memory needs 8MB extra memory
- each HVM domU needs 2MB extra memory
I assume these 8MB per GB is needed for the EPT page tables.
In case this extra memory is indeed some obvious static value, it would be
better to allocate it from the value specified in 'memory=' to make sure a domU
uses (almost) exactly the value that was configured.
Olaf
domU='hvm'
free_memory='125551'
for memory in {1024..102400}
do
test "$(( ${memory} % (4*1024) ))" = "0" || continue
xl destroy "${domU}" &> /dev/null
while test "`xl info | awk '/^free_memory/{print $3}'`" -lt
"${free_memory}"
do
sleep 0.2
done
xl create -q -f '/netshare/domU.cfg' "name='${domU}'"
"memory='${memory}'" "vcpus='1'"
while sleep 0.1
do
state="`xl list "${domU}" | awk "/^"${domU}'/{print $5}'`"
case "${state}" in
r?) break ;;
?b) break ;;
*) ;;
esac
done
actual_free_memory="`xl info | awk '/^free_memory/{print $3}'`"
domU_used_memory="$(( ${free_memory} - ${actual_free_memory} ))"
extra_memory="$(( ${domU_used_memory} - ${memory} ))"
echo "${memory}/$((${memory}/1024)) ${domU_used_memory}
${extra_memory}: $${memory}/1024)*8)+2))"
done
pgpsycC_ck6PO.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.
[[ Sorry. Needed to send another mail because I forgot to add xen-devel lists to CC. ]] Hello, I applied your direct-map patch, Stefano, on top of RELEASE-4.13.0 Xen. I also took your advice and used the Imagebuilder tool to setup my u-boot environment. I modified the tool to allow SDCard booting and tweaked the parameters a little to fit our platforms, also introducing support to add "direct-map" parameter in specific /chosen/DomU node and "xen,passthrough" in the host dts. The tool is very helpful and allows me to quickly change the u-boot environment without manually entering all the fdt formatting commands. The dom0less booting is successful, however, when I try to passthrough any device (I tried with ethernet card and uSDHC) I get a kernel panic in DomU when it tries to probe the driver, because of an unhandled fault: (XEN) DOM1: [3.883482] sdhci: Secure Digital Host Controller Interface driver (XEN) DOM1: [3.891021] sdhci: Copyright(c) Pierre Ossman (XEN) DOM1: [3.896389] sdhci-pltfm: SDHCI platform and OF driver helper (XEN) DOM1: [3.903298] Unhandled fault at 0xff800800d048 (XEN) DOM1: [3.909021] Mem abort info: (XEN) DOM1: [3.912863] ESR = 0x9600 (XEN) DOM1: [3.917019] Exception class = DABT (current EL), IL = 32 bits (XEN) DOM1: [3.924115] SET = 0, FnV = 0 (XEN) DOM1: [3.928206] EA = 0, S1PTW = 0 (XEN) DOM1: [3.932457] Data abort info: (XEN) DOM1: [3.936514] ISV = 0, ISS = 0x (XEN) DOM1: [3.941398] CM = 0, WnR = 0 (XEN) DOM1: [3.945481] swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval) (XEN) DOM1: [3.953532] [ff800800d048] pgd=bfffe803, pud=bfffe803, pmd=bfffd803, pte=00e8402f0f07 (XEN) DOM1: [3.965278] Internal error: ttbr address size fault: 9600 [#1] PREEMPT SMP (XEN) DOM1: [3.973546] Modules linked in: (XEN) DOM1: [3.977709] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) (XEN) DOM1: [3.985525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.59-rt24+g00334f2 #1 (XEN) DOM1: [3.993855] pstate: 6005 (nZCv daif -PAN -UAO) (XEN) DOM1: [3.999755] pc : 0xff80083ac864 (XEN) DOM1: [4.004354] lr : 0xff80083ac810 (XEN) DOM1: [4.008955] sp : ff800800bba0 (XEN) DOM1: [4.013382] x29: ff800800bba0 x28: (XEN) DOM1: [4.019805] x27: ff800864f068 x26: ff80086ba000 (XEN) DOM1: [4.026228] x25: ffc031564980 x24: ff800856e0c0 (XEN) DOM1: [4.032651] x23: ffc03e8eec00 x22: ffc03e8eec10 (XEN) DOM1: [4.039074] x21: ffc03e8bf500 x20: ffc03e8bf800 (XEN) DOM1: [4.045497] x19: x18: (XEN) DOM1: [4.051921] x17: x16: (XEN) DOM1: [4.058344] x15: ff8008678548 x14: (XEN) DOM1: [4.064767] x13: 0018 x12: 0101010101010101 (XEN) DOM1: [4.071190] x11: 0020 x10: 0101010101010101 (XEN) DOM1: [4.077613] x9 : x8 : ffc031564c00 (XEN) DOM1: [4.084036] x7 : x6 : 003f (XEN) DOM1: [4.090459] x5 : 0002 x4 : ffc03e83b4c0 (XEN) DOM1: [4.096883] x3 : x2 : (XEN) DOM1: [4.103306] x1 : ffc03e8bf000 x0 : ff800800d048 (XEN) DOM1: [4.109729] Call trace: (XEN) DOM1: [4.113290] 0xff80083ac864 (XEN) DOM1: [4.117541] 0xff800832e3b8 (XEN) DOM1: [4.121795] 0xff800832c49c (XEN) DOM1: [4.126047] 0xff800832c6bc (XEN) DOM1: [4.130301] 0xff800832c808 (XEN) DOM1: [4.134554] 0xff800832a208 (XEN) DOM1: [4.138807] 0xff800832bd38 (XEN) DOM1: [4.143060] 0xff800832b5d8 (XEN) DOM1: [4.147314] 0xff800832d1f0 (XEN) DOM1: [4.151567] 0xff800832e318 (XEN) DOM1: [4.155820] 0xff800861d5f8 (XEN) DOM1: [4.160073] 0xff800808397c (XEN) DOM1: [4.164326] 0xff8008600db4 (XEN) DOM1: [4.168580] 0xff80085078c0 (XEN) DOM1: [4.172833] 0xff8008084c30 (XEN) DOM1: [4.177091] Code: b9000ea0 d5033e9f f9400ea0 91012000 (b91f) (XEN) DOM1: [4.184298] ---[ end trace 7dc5f6b878cccbfa ]--- (XEN) DOM1: [4.191546] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b I uploaded on pastebin.com the u-boot env settings [0], my device passthrough partial dts [1], and the whole log of boot messages from xen, Dom0 and DomU [2]. I also modified the guest address layout and mapped the PL011 UART and GICv3 addresses to match the physical ones, as well as setting the GUEST_GNTTAB_BASE and GUEST_MAGIC_BASE to addresses before our board's RAM start address. I updated the GUEST_RAM0_BASE and GUEST_RAM0_SIZE to match the physical ones. Maybe you could check if I did anything wrong, because I couldn't figure it out. [0] https://pastebin.com/As6PgVFf [1] https://pastebin.com/j0NS4x5Z [2]
[Xen-devel] [xen-unstable-smoke test] 146935: regressions - FAIL
flight 146935 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/146935/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882 build-arm64-xsm 6 xen-buildfail REGR. vs. 146882 build-armhf 6 xen-buildfail REGR. vs. 146882 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen af09b7d79cb8ae7498882e61efec75486eb69544 baseline version: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c Last test of basis 146882 2020-02-11 16:00:54 Z0 days Failing since146893 2020-02-11 20:01:02 Z0 days7 attempts Testing same since 146935 2020-02-12 11:06:10 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné jobs: build-arm64-xsm fail build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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 Not pushing. commit af09b7d79cb8ae7498882e61efec75486eb69544 Author: Juergen Gross Date: Wed Feb 12 10:55:06 2020 +0100 xen: remove empty softirq_init() softirq_init() is empty since Xen 4.1. Remove it together with its call sites. Signed-off-by: Juergen Gross Acked-by: Andrew Cooper commit 66b282bbb1aa64a3d7a6f7d705cf10ba844cd611 Author: Jan Beulich Date: Wed Feb 12 10:54:08 2020 +0100 AMD/IOMMU: drop redundant code The level 1 special exit path is unnecessary in iommu_pde_from_dfn() - the subsequent code takes care of this case quite fine. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 6827bea2b3b99153821b8b7446bdced27f720188 Author: Jan Beulich Date: Wed Feb 12 10:52:20 2020 +0100 dom0-build: fix build with clang5 With non-empty CONFIG_DOM0_MEM clang5 produces dom0_build.c:344:24: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^ ~~ dom0_build.c:344:24: note: use '&' for a bitwise operation if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ^~ & dom0_build.c:344:24: note: remove constant to silence this warning if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] ) ~^ 1 error generated. Obviously neither of the two suggestions are an option here. Oddly enough swapping the operands of the && helps, while e.g. casting or parenthesizing doesn't. Another workable variant looks to be the use of !! on the constant. Signed-off-by: Jan Beulich Acked-by: Julien Grall Acked-by: Roger Pau Monné commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9 Author: Andrew Cooper Date: Wed Feb 5 15:25:21 2020 + tools/libxl: Combine legacy CPUID handling logic While we are in the process of overhauling boot time CPUID/MSR handling, the existing logic is going to have to remain in roughly this form for backwards compatibility. Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a single libxl__cpuid_legacy() to reduce the complexity for callers. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson commit dacb80f9757c011161cec6609f39837c9ea8caa8 Author: Andrew
[Xen-devel] [PATCH v2 fixed 13/16] numa: Teach ram block notifiers about resizable ram blocks
We want to actually resize ram blocks (make everything between
used_length and max_length inaccessible) - however, not all ram block
notifiers will support that. Let's teach the notifier that ram blocks
are indeed resizable, but keep using max_size in the existing notifiers.
Supply the max_size when adding and removing ram blocks. Also, notify on
resizes. Introduce a way to detect if any registered notifier does not
support resizes - ram_block_notifiers_support_resize() - which we can later
use to fallback to legacy handling if a registered notifier (esp., SEV and
HAX) does not support actual resizes.
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: "Dr. David Alan Gilbert"
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: "Michael S. Tsirkin"
Cc: xen-devel@lists.xenproject.org
Cc: Igor Mammedov
Signed-off-by: David Hildenbrand
---
exec.c | 13 +++--
hw/core/numa.c | 34 +-
hw/i386/xen/xen-mapcache.c | 7 ---
include/exec/ramlist.h | 14 ++
target/i386/hax-mem.c | 5 +++--
target/i386/sev.c | 18 ++
util/vfio-helpers.c| 17 +
7 files changed, 76 insertions(+), 32 deletions(-)
diff --git a/exec.c b/exec.c
index fc65c4f7ca..f2d30479b8 100644
--- a/exec.c
+++ b/exec.c
@@ -2139,6 +2139,8 @@ static void qemu_ram_apply_settings(void *host, size_t
length)
*/
int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
{
+const ram_addr_t oldsize = block->used_length;
+
assert(block);
newsize = HOST_PAGE_ALIGN(newsize);
@@ -2167,6 +2169,11 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize,
Error **errp)
block->used_length = newsize;
cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
DIRTY_CLIENTS_ALL);
+
+if (block->host) {
+ram_block_notify_resized(block->host, oldsize, newsize);
+}
+
memory_region_set_size(block->mr, newsize);
if (block->resized) {
block->resized(block->idstr, newsize, block->host);
@@ -2319,7 +2326,8 @@ static void ram_block_add(RAMBlock *new_block, Error
**errp)
if (new_block->host) {
qemu_ram_apply_settings(new_block->host, new_block->max_length);
-ram_block_notify_add(new_block->host, new_block->max_length);
+ram_block_notify_add(new_block->host, new_block->used_length,
+ new_block->max_length);
}
}
@@ -2502,7 +2510,8 @@ void qemu_ram_free(RAMBlock *block)
}
if (block->host) {
-ram_block_notify_remove(block->host, block->max_length);
+ram_block_notify_remove(block->host, block->used_length,
+block->max_length);
}
qemu_mutex_lock_ramlist();
diff --git a/hw/core/numa.c b/hw/core/numa.c
index 6599c69e05..5b20dc726d 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -902,11 +902,12 @@ void query_numa_node_mem(NumaNodeMem node_mem[],
MachineState *ms)
static int ram_block_notify_add_single(RAMBlock *rb, void *opaque)
{
const ram_addr_t max_size = qemu_ram_get_max_length(rb);
+const ram_addr_t size = qemu_ram_get_used_length(rb);
void *host = qemu_ram_get_host_addr(rb);
RAMBlockNotifier *notifier = opaque;
if (host) {
-notifier->ram_block_added(notifier, host, max_size);
+notifier->ram_block_added(notifier, host, size, max_size);
}
return 0;
}
@@ -923,20 +924,43 @@ void ram_block_notifier_remove(RAMBlockNotifier *n)
QLIST_REMOVE(n, next);
}
-void ram_block_notify_add(void *host, size_t size)
+void ram_block_notify_add(void *host, size_t size, size_t max_size)
{
RAMBlockNotifier *notifier;
QLIST_FOREACH(notifier, _list.ramblock_notifiers, next) {
-notifier->ram_block_added(notifier, host, size);
+notifier->ram_block_added(notifier, host, size, max_size);
}
}
-void ram_block_notify_remove(void *host, size_t size)
+void ram_block_notify_remove(void *host, size_t size, size_t max_size)
{
RAMBlockNotifier *notifier;
QLIST_FOREACH(notifier, _list.ramblock_notifiers, next) {
-notifier->ram_block_removed(notifier, host, size);
+notifier->ram_block_removed(notifier, host, size, max_size);
}
}
+
+void ram_block_notify_resized(void *host, size_t old_size, size_t new_size)
+{
+RAMBlockNotifier *notifier;
+
+QLIST_FOREACH(notifier, _list.ramblock_notifiers, next) {
+if (notifier->ram_block_resized) {
+notifier->ram_block_resized(notifier, host, old_size, new_size);
+}
+}
+}
+
+bool ram_block_notifiers_support_resize(void)
+{
+RAMBlockNotifier *notifier;
+
+QLIST_FOREACH(notifier, _list.ramblock_notifiers, next) {
+if (!notifier->ram_block_resized) {
+return false;
+}
+}
+return true;
+}
diff --git
[Xen-devel] [linux-4.19 test] 146901: regressions - FAIL
flight 146901 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/146901/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 13 guest-start.2 fail REGR. vs. 142932 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 142880 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142932 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail 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-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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux357668399cf70ccdc0ee8967bff3448d0f4f9ae1 baseline version: linuxc3038e718a19fc596f7b1baba0f83d5146dc7784 Last test of basis 142932 2019-10-19 23:17:10 Z 115 days Failing since143326 2019-10-29 08:49:29 Z 106 days7 attempts Testing same since 146901 2020-02-11 22:13:48 Z0 days1 attempts 1769 people touched revisions
Re: [Xen-devel] Core Scheduling "lock == schedule_lock" assertion failure
On 12.02.20 12:21, Sergey Dyasli wrote:
Hi Juergen,
Recently our testing has found a host crash which is reproducible.
Do you have any idea what might be going on here?
Oh, nice catch!
The problem is that get_cpu_idle_time() is calling vcpu_runstate_get()
for an idle vcpu. This is fragile as idle vcpus are sometimes assigned
temporarily to normal scheduling units, thus the ASSERT() in the unlock
function is failing when the assignment of the idle vcpu is modified
under the feet of vcpu_runstate_get() and the unit it has been assigned
to before is already scheduled on another cpu.
The patch is rather easy, though. Can you try it, please?
Juergen
>From 0236aee221409fa826a81395f2f3e8b15d5128de Mon Sep 17 00:00:00 2001
From: Juergen Gross
To: xen-devel@lists.xenproject.org
Cc: George Dunlap
Cc: Dario Faggioli
Date: Wed, 12 Feb 2020 13:04:16 +0100
Subject: [PATCH] xen/sched: fix get_cpu_idle_time() with core scheduling
get_cpu_idle_time() is calling vcpu_runstate_get() for an idle vcpu.
With core scheduling active this is fragile, as idle vcpus are assigned
to other scheduling units temporarily, and that assignment is changed
in some cases without holding the scheduling lock, and
vcpu_runstate_get() is using v->sched_unit as parameter for
unit_schedule_[un]lock_irq(), resulting in an ASSERT() triggering in
unlock in case v->sched_unit has changed meanwhile.
Fix that by using a local unit variable holding the correct unit.
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 2e43f8029f..de5a6b1a57 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -308,17 +308,26 @@ void vcpu_runstate_get(const struct vcpu *v,
{
spinlock_t *lock;
s_time_t delta;
+struct sched_unit *unit;
rcu_read_lock(_res_rculock);
-lock = likely(v == current) ? NULL : unit_schedule_lock_irq(v->sched_unit);
+/*
+ * Be careful in case of an idle vcpu: the assignment to a unit might
+ * change even with the scheduling lock held, so be sure to use the
+ * correct unit for locking in order to avoid triggering an ASSERT() in
+ * the unlock function.
+ */
+unit = is_idle_vcpu(v) ? get_sched_res(v->processor)->sched_unit_idle
+ : v->sched_unit;
+lock = likely(v == current) ? NULL : unit_schedule_lock_irq(unit);
memcpy(runstate, >runstate, sizeof(*runstate));
delta = NOW() - runstate->state_entry_time;
if ( delta > 0 )
runstate->time[runstate->state] += delta;
if ( unlikely(lock != NULL) )
-unit_schedule_unlock_irq(lock, v->sched_unit);
+unit_schedule_unlock_irq(lock, unit);
rcu_read_unlock(_res_rculock);
}
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64-libvirt
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: dacb80f9757c011161cec6609f39837c9ea8caa8
Bug not present: 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146934/
commit dacb80f9757c011161cec6609f39837c9ea8caa8
Author: Andrew Cooper
Date: Wed Jan 8 12:53:49 2020 +
tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from the API
These functions should never have been exposed. They don't have external
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and
leave
an equivalent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build
--summary-out=tmp/146934.bisection-summary --basis-template=146882
--blessings=real,real-bisect xen-unstable-smoke build-amd64-libvirt
libvirt-build
Searching for failure / basis pass:
146928 fail [host=albana0] / 146882 [host=chardonnay0] 146838 ok.
Failure / basis pass flights: 146928 / 146838
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Basis pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
3dd724dff085e13ad520f8e35aea717db2ff07d0
Generating revisions with ./adhoc-revtuple-generator
git://xenbits.xen.org/libvirt.git#a1cd25b919509be2645dbe6f952d5263e0d4e4e5-a1cd25b919509be2645dbe6f952d5263e0d4e4e5
https://git.savannah.gnu.org/git/gnulib.git/#611869be9f1083e53305446d90a2909fc89914ef-611869be9f1083e53305446d90a2909fc89914ef
https://gitlab.com/keycodemap/keycodemapdb.git#317d3eeb963a515e15a63fa356d8ebcda7041a51-317d3eeb963a515e15a63fa356d8ebcda7041a51
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484\
fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
git://xenbits.xen.org/xen.git#3dd724dff085e13ad520f8e35aea717db2ff07d0-1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Loaded 5001 nodes in revision graph
Searching for test results:
146838 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
3dd724dff085e13ad520f8e35aea717db2ff07d0
146871 []
146882 [host=chardonnay0]
146893 fail a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146898 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
3dd724dff085e13ad520f8e35aea717db2ff07d0
146899 fail a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
317d3eeb963a515e15a63fa356d8ebcda7041a51
d0d8ad39ecb51cd7497cd524484fe09f50876798
933ebad2470a169504799a1d95b8e410bd9847ef
1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
146913 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5
611869be9f1083e53305446d90a2909fc89914ef
[Xen-devel] [xen-unstable test] 146896: tolerable FAIL - PUSHED
flight 146896 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/146896/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 146796 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146787 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 146787 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 146787 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 146787 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 146787 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 146787 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 146787 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 146787 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 146796 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 146796 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 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-libvirt 13 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-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c baseline version: xen 72dbcf0c065037dddb591a072c4f8f16fe888ea8 Last test of basis 146829 2020-02-10 12:13:21 Z1 days Failing since146839 2020-02-11 01:06:54 Z1 days3 attempts Testing same since 146896 2020-02-11 21:36:58 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Christian Lindig
[Xen-devel] Core Scheduling "lock == schedule_lock" assertion failure
Hi Juergen, Recently our testing has found a host crash which is reproducible. Do you have any idea what might be going on here? (XEN) [175654.165126] Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' failed at ...ild/BUILD/xen-4.13.1/xen/include/xen/sched-if.h:269 (XEN) [175654.165133] [ Xen-4.13.1-9.0.3-d x86_64 debug=y Not tainted ] (XEN) [175654.165136] CPU:28 (XEN) [175654.165138] RIP:e008:[] vcpu_runstate_get+0x11e/0x14f (XEN) [175654.165146] RFLAGS: 00010083 CONTEXT: hypervisor (d0v4) (XEN) [175654.165151] rax: 83403ff0d340 rbx: 83807cc97ac8 rcx: 0006 (XEN) [175654.165154] rdx: 006fbf942000 rsi: 83400f8e1cd8 rdi: 107898e2 (XEN) [175654.165158] rbp: 83807cc97ab8 rsp: 83807cc97a88 r8: deadbeefdeadf00d (XEN) [175654.165160] r9: deadbeefdeadf00d r10: r11: (XEN) [175654.165164] r12: 83400fa6f000 r13: 83400f8c9778 r14: 82d0805c8008 (XEN) [175654.165167] r15: 832e30854ae0 cr0: 80050033 cr4: 00362660 (XEN) [175654.165170] cr3: 002130811000 cr2: 88817f50b728 (XEN) [175654.165172] fsb: 7f40a40da740 gsb: 88831d30 gss: (XEN) [175654.165175] ds: es: fs: gs: ss: e010 cs: e008 (XEN) [175654.165179] Xen code around (vcpu_runstate_get+0x11e/0x14f): (XEN) [175654.165181] 04 10 4c 3b 68 10 74 02 <0f> 0b 4c 89 ef e8 7e 5d 00 00 48 8d 05 41 9d 38 (XEN) [175654.165192] Xen stack trace from rsp=83807cc97a88: (XEN) [175654.165194]83807cc97aa8 83400fa75a60 83807cc97da0 (XEN) [175654.165199]0230 83807cc97fff 83807cc97af8 82d08023d41f (XEN) [175654.165204]0001 9fc1ac1cb2f4 4840c423acdc 5780e7f9735a (XEN) [175654.165207] 83807cc97c98 82d0802ea9f7 (XEN) [175654.165211] 9fc1ac1c6b99 00050007 83807cc97c10 (XEN) [175654.165215]83807cc97bb0 0020 (XEN) [175654.165251] (XEN) [175654.165254] (XEN) [175654.165258]82d0805c8038 82d0805c74a0 aa00 (XEN) [175654.165263] (XEN) [175654.165266] (XEN) [175654.165269] (XEN) [175654.165273] (XEN) [175654.165276] (XEN) [175654.165279] (XEN) [175654.165283]83400f813000 83807cc97d98 82d0805cda80 (XEN) [175654.165287]0230 83807cc97fff 83807cc97cc8 82d08026d99b (XEN) [175654.165291]83807cc97ef8 83400f813000 82d0805cda80 0230 (XEN) [175654.165295]83807cc97e48 82d080244573 7f40a40e6000 0206 (XEN) [175654.165300]82004006c000 82e08a815e80 (XEN) [175654.165304] Xen call trace: (XEN) [175654.165306][] R vcpu_runstate_get+0x11e/0x14f (XEN) [175654.165310][] F get_cpu_idle_time+0x4d/0x53 (XEN) [175654.165315][] F pmstat_get_cx_stat+0x82/0x8e7 (XEN) [175654.165319][] F do_get_pm_info+0x27b/0x2d4 (XEN) [175654.165322][] F do_sysctl+0x633/0x14e0 (XEN) [175654.165327][] F pv_hypercall+0x1f5/0x567 (XEN) [175654.165330][] F lstar_enter+0x112/0x120 (XEN) [175654.165332] (XEN) [175654.550916] (XEN) [175654.553243] (XEN) [175654.559449] Panic on CPU 28: (XEN) [175654.563328] Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' failed at ...ild/BUILD/xen-4.13.1/xen/include/xen/sched-if (XEN) [175654.581847] (XEN) [175654.584173] Reboot in five seconds... (XEN) [175654.588925] Executing kexec image on cpu28 (XEN) [175654.594987] Shot down all CPUs The state of the sibling was: PCPU 29 Host state: RIP:e008:[] Ring 0 RFLAGS: 00040002 AC IOPL0 rax: 83400f8c91e4 rbx: 001d rcx: 83400f8c91f4 rdx: 83400f8c9104 rsi: 83400f8c9094 rdi: 0004 rbp: 83807cc89f28 rsp: 83807cc89f28 r8: r9: r10: r11: r12: r13: r14: 83807cc8 r15: cr0: 80050033 PG
[Xen-devel] [xen-unstable-smoke test] 146928: regressions - FAIL
flight 146928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-xsm 6 xen-buildfail REGR. vs. 146882
build-armhf 6 xen-buildfail REGR. vs. 146882
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
version targeted for testing:
xen 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
baseline version:
xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
Last test of basis 146882 2020-02-11 16:00:54 Z0 days
Testing same since 146893 2020-02-11 20:01:02 Z0 days6 attempts
People who touched revisions under test:
Andrew Cooper
Ian Jackson
jobs:
build-arm64-xsm fail
build-amd64 pass
build-armhf fail
build-amd64-libvirt fail
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-amd64-libvirt 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
Not pushing.
commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Author: Andrew Cooper
Date: Wed Feb 5 15:25:21 2020 +
tools/libxl: Combine legacy CPUID handling logic
While we are in the process of overhauling boot time CPUID/MSR handling, the
existing logic is going to have to remain in roughly this form for backwards
compatibility.
Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a
single
libxl__cpuid_legacy() to reduce the complexity for callers.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
commit dacb80f9757c011161cec6609f39837c9ea8caa8
Author: Andrew Cooper
Date: Wed Jan 8 12:53:49 2020 +
tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from the API
These functions should never have been exposed. They don't have external
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivalent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] reported memory usage does not match real memory usage
I was made aware of the fact that Xen apparently loses memory as soon as domUs are started. In my testing HVM domUs occupy much more memory than what was configured for them. The expected memory footprint for a PV domU seems to match the value in the domU config file. My test host has 128GB and 8 cpus, dom0 is started with a fixed amount of memory. Before any domU is started, 1.4G are already "lost". It seems for each HVM a certain amount of extra memory must be available. For a 100G HVM domU another 809M is required. With just 1 vcpu instead of 8 the amount of extra memory is reduced to 802M. With 32 vcpus it increases to 834M. Apparently each vcpu needs 1M extra memory. Is there a formula to calculate that amount of extra memory, is this behavior documented somewhere? Olaf (XEN) System RAM: 131062MB (134208492kB) xl info | grep -i mem total_memory : 131062 free_memory: 125551 xen_commandline: loglvl=all guest_loglvl=all smt=1 console=com1 com1=57600 dom0_mem=4G 131062M - 125551M = 5511M used for just dom0 5511M - 4096M = 1415M lost? pv domU, pvgrub2, mem=1024, vcpu=1 free_memory: 124527 125551M - 124527M = 1024M, matches expectation pv domU, pvgrub2, mem=65536, vcpu=8 free_memory: 58990 124527M - 58990M = 65537M 65537M - 65536M = 1M extra? fv domU, mem=32768, vcpu=8 free_memory: 25957 58990M - 25957M = 33033M 33033M - 32768M = 256M extra? stop all domUs free_memory: 125551 fv domU, mem=102400, vcpu=8 free_memory: 22342 125551M - 22342M = 103209M 103209M - 102400M = 809M extra? fv domU, mem=102400, vcpu=1 free_memory: 22349 125551M - 22349M = 103202M 103202M - 102400M = 802M extra? pgp2XYo5aNNXl.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 146931: all pass - PUSHED
flight 146931 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/146931/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c baseline version: xen f7fb9a0aa9fbb81292e1626ce40340d3f6d8d505 Last test of basis 146739 2020-02-05 09:18:44 Z7 days Failing since146819 2020-02-09 09:18:20 Z3 days2 attempts Testing same since 146931 2020-02-12 09:19:05 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Christian Lindig George Dunlap Ian Jackson Jan Beulich Jeff Kubascik Juergen Gross Julien Grall Julien Grall Marek Marczykowski-Górecki Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu Wei Liu 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 f7fb9a0aa9..6c47c37b9b 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Race condition in console_available callback? (libvirt + libxl + xenconsoled)
Hello, I am trying to debug an issue in QubesOS where a domain created by libvirt often does not have information stored about the console TTY path. The relevant part of libvirt creates a domain using libxl_domain_create_new() and registers a callback (aop_console_how) that is supposed to fire when the console is available. The callback then calls libxl_console_get_tty(), but that fails with: 2020-01-06 11:52:30.952+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/4/console/tty': Resource temporarily unavailable Based on my reading of the libxl code, it's supposed to set the path in xenstore and then call the console_available callback, but only if the bootloader is configured. Otherwise, we call console_available at a later point (in domcreate_attach_devices()) and the path in xenstore is being set by xenconsoled independently. However, there is no guarantee that xenconsoled will do that before we call console_available. And indeed, looking at the traces from xenstored, the read and write of `.../console/tty` are ordered randomly depending on the machine. Should libxl wait for the information appearing in '.../console/tty' at this point? Perhaps similar as the code I see in xenconsoled client (xen/tools/console/client.c)? I would be happy to work on a patch but I'm unfamiliar with the project so I want to check my assumptions. (I am testing with Xen 4.8.5 because that's what the stable version of QubesOS uses, but as far as I can tell, that part has not changed since). Original QubesOS bug here: https://github.com/QubesOS/qubes-issues/issues/5156 -- Paweł Marczewski Invisible Things Lab signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: do live patching only from main idle loop
On 11.02.2020 10:31, Juergen Gross wrote: > One of the main design goals of core scheduling is to avoid actions > which are not directly related to the domain currently running on a > given cpu or core. Live patching is one of those actions which are > allowed taking place on a cpu only when the idle scheduling unit is > active on that cpu. > > Unfortunately live patching tries to force the cpus into the idle loop > just by raising the schedule softirq, which will no longer be > guaranteed to work with core scheduling active. Additionally there are > still some places in the hypervisor calling check_for_livepatch_work() > without being in the idle loop. > > It is easy to force a cpu into the main idle loop by scheduling a > tasklet on it. So switch live patching to use tasklets for switching to > idle and raising scheduling events. Additionally the calls of > check_for_livepatch_work() outside the main idle loop can be dropped. > > As tasklets are only running on idle vcpus and stop_machine_run() > is activating tasklets on all cpus but the one it has been called on > to rendezvous, it is mandatory for stop_machine_run() to be called on > an idle vcpu, too, as otherwise there is no way for scheduling to > activate the idle vcpu for the tasklet on the sibling of the cpu > stop_machine_run() has been called on. > > Signed-off-by: Juergen Gross Applicable x86 bits Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] AMD/IOMMU: Remove unused iommu_get_addr_{lo, hi}_from_cmd() helpers
On 11.02.2020 15:55, Andrew Cooper wrote: > These were introduced in 262bb227a4 in 2012, and have never had any users. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] hvmloader: Drop use of XENVER_extraversion
On 11.02.2020 15:08, Andrew Cooper wrote: > The printf() in init_hypercalls() only ends up in the hypervisor console log, > so extraversion really isn't interesting. > > The SMBios table doesn't need extraversion, and removing it reduces the > ability for a guest to fingerprint the exact hypervisor it is running under. While I'm not entirely opposed, let's compare with bare hardware's BIOSes / SMBIOS tables: Don't you see, just like I do, typically very detailed BIOS etc version information (sometimes including even something like build numbers) there? I can accept that excess data in extraversion may go too far, but the minor version number we put there by default is hardly of any concern, and may end up being useful. The one argument against its usefulness is that it's generally string of no-where standardized contents. Personally I like Sergey's approach better, but I realize you dislike it to a degree that, as it seems, you're not even willing to have a reasonable dispute over it. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] xsm: add Kconfig option for denied string
On 11.02.2020 14:56, Andrew Cooper wrote: > On 11/02/2020 13:42, Sergey Dyasli wrote: >> Add Kconfig option to make it possible to configure the string returned >> to non-privileged guests instead of the default "" which could >> propagate to UI / logs after the subsequent patch that hides detailed >> Xen version information from unprivileged guests. >> >> Introduce XENVER_denied_string to allow guests to set up UI / logs >> filtering which dependens on the new CONFIG_XSM_DENIED_STRING. > > No. This is even worse than other suggestions. > > It is entirely unacceptable to expect guests to have to modify them to > figure out when they're being lied to. Why "lied to"? Denying data access is different from lying imo. Plus your proposal to return empty strings then is even more of a lie, for being not even recognizable a "access denied". > And it is now possible *without source code modifications* to create a > Xen which reports one string in this hypercall, and has empty strings > elsewhere, which is even more chaotic for guests. Empty strings elsewhere? Do you mean because of access having been denied, or because they in fact are empty? In the former case I'd like to ask for at least one example, while in the latter case I don't see what wrong you see. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] xsm: add Kconfig option for denied string
On 11.02.2020 14:42, Sergey Dyasli wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -228,6 +228,14 @@ choice > bool "SILO" if XSM_SILO > endchoice > > +config XSM_DENIED_STRING > + string "xen_version hypercall denied information replacement string" > + default "" > + depends on XSM Why would this string want to be configurable only in XSM- enabled builds? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] AMD/IOMMU: Clean up the allocation helpers
On 11.02.2020 12:27, Andrew Cooper wrote: > Conform to style, drop unnecessary local variables, and avoid opencoding > clear_domain_page(). > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen-unstable: pci-passthrough regression bisected to: x86/smp: use APIC ALLBUT destination shorthand when possible
On Wed, Feb 12, 2020 at 09:46:22AM +0100, Sander Eikelenboom wrote:
> On 11/02/2020 15:00, Roger Pau Monné wrote:
> > Thanks, I have another patch for you to try, which will likely make
> > your system crash. Could you give it a try and paste the log output?
> >
> > Thanks, Roger.
>
> Applied the patch, rebuild, rebooted and braced for impact ...
> However the device bugged again, but no xen panic occured, so nothing
> special in the logs.
> I only had time to try it once, so I could retry this evening.
Sorry, that's my fault because I gave you a patch that was missing a
chunk, the following should hopefully trigger the panic. Would you
mind trying again?
Thanks, Roger.
---8<---
commit 9bd7ee8fa836690087f3eef89d24aded0c8cd8ae
Author: Roger Pau Monne
Date: Tue Feb 11 11:14:48 2020 +0100
x86: add accessors for scratch cpu mask
Current usage of the per-CPU scratch cpumask is dangerous since
there's no way to figure out if the mask is already being used except
for manual code inspection of all the callers and possible call paths.
This is unsafe and not reliable, so introduce a minimal get/put
infrastructure to prevent nested usage of the scratch mask.
Signed-off-by: Roger Pau Monné
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index e98e08e9c8..4ee261b632 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2236,10 +2236,11 @@ int io_apic_set_pci_routing (int ioapic, int pin, int
irq, int edge_level, int a
entry.vector = vector;
if (cpumask_intersects(desc->arch.cpu_mask, TARGET_CPUS)) {
-cpumask_t *mask = this_cpu(scratch_cpumask);
+cpumask_t *mask = get_scratch_cpumask();
cpumask_and(mask, desc->arch.cpu_mask, TARGET_CPUS);
SET_DEST(entry, logical, cpu_mask_to_apicid(mask));
+put_scratch_cpumask();
} else {
printk(XENLOG_ERR "IRQ%d: no target CPU (%*pb vs %*pb)\n",
irq, CPUMASK_PR(desc->arch.cpu_mask), CPUMASK_PR(TARGET_CPUS));
@@ -2433,10 +2434,11 @@ int ioapic_guest_write(unsigned long physbase, unsigned
int reg, u32 val)
if ( cpumask_intersects(desc->arch.cpu_mask, TARGET_CPUS) )
{
-cpumask_t *mask = this_cpu(scratch_cpumask);
+cpumask_t *mask = get_scratch_cpumask();
cpumask_and(mask, desc->arch.cpu_mask, TARGET_CPUS);
SET_DEST(rte, logical, cpu_mask_to_apicid(mask));
+put_scratch_cpumask();
}
else
{
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index cc2eb8e925..7ecf5376e3 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -196,7 +196,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
{
unsigned int cpu, old_vector, irq = desc->irq;
unsigned int vector = desc->arch.vector;
-cpumask_t *tmp_mask = this_cpu(scratch_cpumask);
+cpumask_t *tmp_mask = get_scratch_cpumask();
BUG_ON(!valid_irq_vector(vector));
@@ -223,7 +223,10 @@ static void _clear_irq_vector(struct irq_desc *desc)
trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, tmp_mask);
if ( likely(!desc->arch.move_in_progress) )
+{
+put_scratch_cpumask();
return;
+}
/* If we were in motion, also clear desc->arch.old_vector */
old_vector = desc->arch.old_vector;
@@ -236,6 +239,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
per_cpu(vector_irq, cpu)[old_vector] = ~irq;
}
+put_scratch_cpumask();
release_old_vec(desc);
desc->arch.move_in_progress = 0;
@@ -1152,10 +1156,11 @@ static void irq_guest_eoi_timer_fn(void *data)
break;
case ACKTYPE_EOI:
-cpu_eoi_map = this_cpu(scratch_cpumask);
+cpu_eoi_map = get_scratch_cpumask();
cpumask_copy(cpu_eoi_map, action->cpu_eoi_map);
spin_unlock_irq(>lock);
on_selected_cpus(cpu_eoi_map, set_eoi_ready, desc, 0);
+put_scratch_cpumask();
return;
}
@@ -2531,12 +2536,12 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
unsigned int irq;
static int warned;
struct irq_desc *desc;
+cpumask_t *affinity = get_scratch_cpumask();
for ( irq = 0; irq < nr_irqs; irq++ )
{
bool break_affinity = false, set_affinity = true;
unsigned int vector;
-cpumask_t *affinity = this_cpu(scratch_cpumask);
if ( irq == 2 )
continue;
@@ -2640,6 +2645,8 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
irq, CPUMASK_PR(affinity));
}
+put_scratch_cpumask();
+
/* That doesn't seem sufficient. Give it 1ms. */
local_irq_enable();
mdelay(1);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9b33829084..bded19717b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1271,7 +1271,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
(l1e_owner == pg_owner) )
{
struct vcpu *v;
-
Re: [Xen-devel] Xen-unstable: pci-passthrough regression bisected to: x86/smp: use APIC ALLBUT destination shorthand when possible
On 11/02/2020 15:00, Roger Pau Monné wrote: > On Mon, Feb 10, 2020 at 09:49:30PM +0100, Sander Eikelenboom wrote: >> On 03/02/2020 14:21, Roger Pau Monné wrote: >>> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote: On 03/02/2020 13:41, Roger Pau Monné wrote: > On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote: >> On 03/02/2020 13:23, Roger Pau Monné wrote: >>> On Mon, Feb 03, 2020 at 09:33:51AM +0100, Sander Eikelenboom wrote: Hi Roger, Last week I encountered an issue with the PCI-passthrough of a USB controller. In the guest I get: [ 1143.313756] xhci_hcd :00:05.0: xHCI host not responding to stop endpoint command. [ 1143.334825] xhci_hcd :00:05.0: xHCI host controller not responding, assume dead [ 1143.347364] xhci_hcd :00:05.0: HC died; cleaning up [ 1143.356407] usb 1-2: USB disconnect, device number 2 Bisection turned up as the culprit: commit 5500d265a2a8fa63d60c08beb549de8ec82ff7a5 x86/smp: use APIC ALLBUT destination shorthand when possible >>> >>> Sorry to hear that, let see if we can figure out what's wrong. >> >> No problem, that is why I test stuff :) >> I verified by reverting that commit and now it works fine again. >>> >>> Does the same controller work fine when used in dom0? >> >> Will test that, but as all other pci devices in dom0 work fine, >> I assume this controller would also work fine in dom0 (as it has also >> worked fine for ages with PCI-passthrough to that guest and still works >> fine when reverting the referenced commit). > > Is this the only device that fails to work when doing pci-passthrough, > or other devices also don't work with the mentioned change applied? > > Have you tested on other boxes? > >> I don't know if your change can somehow have a side effect >> on latency around the processing of pci-passthrough ? > > Hm, the mentioned commit should speed up broadcast IPIs, but I don't > see how it could slow down other interrupts. Also I would think the > domain is not receiving interrupts from the device, rather than > interrupts being slow. > > Can you also paste the output of lspci -v for that xHCI device from > dom0? > > Thanks, Roger. Will do this evening including the testing in dom0 etc. Will also see if there is any pattern when observing /proc/interrupts in the guest. >>> >>> Thanks! I also have some trivial patch that I would like you to try, >>> just to discard send_IPI_mask clearing the scratch_cpumask under >>> another function feet. >>> >>> Roger. >> >> Hi Roger, >> >> Took a while, but I was able to run some tests now. >> >> I also forgot a detail in the first report (probably still a bit tired from >> FOSDEM), >> namely: the device passedthrough works OK for a while before I get the >> kernel message. >> >> I tested the patch and it looks like it makes the issue go away, >> I tested for a day, while without the patch (or revert of the commit) the >> device >> will give problems within a few hours. > > Thanks, I have another patch for you to try, which will likely make > your system crash. Could you give it a try and paste the log output? > > Thanks, Roger. Applied the patch, rebuild, rebooted and braced for impact ... However the device bugged again, but no xen panic occured, so nothing special in the logs. I only had time to try it once, so I could retry this evening. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/amd: Avoid cpu_has_hypervisor evaluating true on native hardware
On 11.02.2020 18:16, Andrew Cooper wrote: > On 11/02/2020 16:59, Jan Beulich wrote: >> On 11.02.2020 17:31, Roger Pau Monné wrote: >>> On Tue, Feb 11, 2020 at 03:51:54PM +, Andrew Cooper wrote: Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets configured with the HYPERVISOR bit before native CPUID is scanned for feature bits. This results in cpu_has_hypervisor becoming set as part of identify_cpu(), and ends up appearing in the raw and host CPU policies. A combination of this bug, and c/s bb502a8ca59 "x86: check feature flags after resume" which checks that feature bits don't go missing, results in broken S3 on AMD hardware. Alter amd_init_levelling() to exclude the HYPERVISOR bit from cpumask_defaults, and update domain_cpu_policy_changed() to allow it to be explicitly forwarded. This also fixes a bug on kexec, where the hypervisor bit is left enabled for the new kernel to find. These changes highlight a further but - dom0 construction is asymetric with domU construction, by not having any calls to domain_cpu_policy_changed(). Extend arch_domain_create() to always call domain_cpu_policy_changed(). Reported-by: Igor Druzhinin Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Igor Druzhinin CC: Marek Marczykowski-Górecki CC: Claudia v2: * Rewrite the commit message. No change to the patch content. Marek/Claudia: Do either of you want a Reported-by tag seeing as you found a brand new way that this was broken? >> I understand this is addressing only one half of their issue. Since >> you said you don't find it surprising, do you have any idea why the >> OSXSAVE bit is behaving differently on AMD and on Intel? > > It isn't behaving differently between Intel and AMD, I don't think. > > The diagnostics are asymmetric - they ever printed when a feature > disappears, not for a feature appearing. Oh, I see - this is the part I was missing. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 146925: regressions - FAIL
flight 146925 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146882
build-arm64-xsm 6 xen-buildfail REGR. vs. 146882
build-armhf 6 xen-buildfail REGR. vs. 146882
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
version targeted for testing:
xen 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
baseline version:
xen 6c47c37b9b40d6fe40bce8c8fd39135f6d549c8c
Last test of basis 146882 2020-02-11 16:00:54 Z0 days
Testing same since 146893 2020-02-11 20:01:02 Z0 days5 attempts
People who touched revisions under test:
Andrew Cooper
Ian Jackson
jobs:
build-arm64-xsm fail
build-amd64 pass
build-armhf fail
build-amd64-libvirt fail
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-amd64-libvirt 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
Not pushing.
commit 1b3cec69bf300e012a0269f0a4f28cca1ebf22c9
Author: Andrew Cooper
Date: Wed Feb 5 15:25:21 2020 +
tools/libxl: Combine legacy CPUID handling logic
While we are in the process of overhauling boot time CPUID/MSR handling, the
existing logic is going to have to remain in roughly this form for backwards
compatibility.
Fold libxl__cpuid_apply_policy() and libxl__cpuid_set() together into a
single
libxl__cpuid_legacy() to reduce the complexity for callers.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
commit dacb80f9757c011161cec6609f39837c9ea8caa8
Author: Andrew Cooper
Date: Wed Jan 8 12:53:49 2020 +
tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from the API
These functions should never have been exposed. They don't have external
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivalent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
