Re: [Xen-devel] [PATCH] x86: introduce and use setup_force_cpu_cap()
>>> Sarah Newman 09/07/17 3:55 AM >>> >On 09/05/2017 06:22 AM, Jan Beulich wrote: >> For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd >> need to clone the respective hack used for CPUID_FAULTING. Introduce an >> inverse of setup_clear_cpu_cap() instead, but let clearing of features >> overrule forced setting of them. >> >> XEN_SMAP being wrong post-boot is a problem specifically for live >> patching, as a live patch may need alternative instruction patching >> keyed off of that feature flag. >> >> Reported-by: Sarah Newman >> Signed-off-by: Jan Beulich > >Reported-by/Tested-by: Sarah Newman Thanks. >Some questions: > >It looks like setup_clear_cpu_cap has a search for dependent capabilities >that also must be cleared. Does the same need to happen for >setup_force_cpu_cap even if it doesn't matter for the current cpu features? We obviously can't force-set dependent capabilities, and forcing a feature on won't result in the need to clear any others (unless of course it was a strange inverse "feature", but for those it would probably be better to not force them on in the first place). >Does it make sense to add a comment where forced_caps is declared >that cleared_caps overrides forced_caps instead of just in the commit >message? From the code it should be pretty obvious, I would think. But of course you're free to submit a patch to add comments if you feel strongly about it. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113118: trouble: broken/pass
flight 113118 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113118/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 18 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days6 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6
[Xen-devel] [xen-unstable-smoke test] 113116: trouble: broken/pass
flight 113116 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113116/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 17 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days5 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6
[Xen-devel] [ovmf baseline-only test] 72070: all pass
This run is configured for baseline tests only. flight 72070 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72070/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b80a4097393c90d041b299ef628e6104612a2586 baseline version: ovmf 3f3a69b87a2d9b8e0186f6c078302614f55a3357 Last test of basis72068 2017-09-06 08:19:44 Z0 days Testing same since72070 2017-09-07 01:21:42 Z0 days1 attempts People who touched revisions under test: Eric Dong Fu Siyuan Jiewen Yao Ruiyu Ni Wang 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 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit b80a4097393c90d041b299ef628e6104612a2586 Author: Fu Siyuan Date: Wed Sep 6 18:08:07 2017 +0800 NetworkPkg: Fix GCC build error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Cc: Ard Biesheuvel commit 5f74808d03a3f5aae4a098afdff0c3e73d762776 Author: Fu Siyuan Date: Wed Sep 6 18:07:40 2017 +0800 MdeModulePkg: Fix GCC build error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Cc: Ard Biesheuvel commit 9a04dcffbb1e59333e500a8ce66e01a562be8b4f Author: Fu Siyuan Date: Mon Sep 4 16:04:53 2017 +0800 NetworkPkg/Ip6Dxe: fix a bug in IP6 driver for IpSec protocol notify. The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip6IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Reviewed-by: Ye Ting commit 5aae2d35de031a38e7812c615ff6bce36b31466a Author: Fu Siyuan Date: Mon Sep 4 16:04:13 2017 +0800 MdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify. The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip4IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Reviewed-by: Ye Ting commit 12cfc9009e7cf1a69ca675110c2cf6e21b152992 Author: Eric Dong Date: Wed Sep 6 13:52:51 2017 +0800 MdePkg/PiMmCis.h: Fix build failure. Include the missed header file to fix build failure. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong Reviewed-by: Liming Gao commit d51b0122bf9bd1df831c77b5669bfbb66aaa4874 Author: Wang Fan Date: Thu Aug 24 17:17:19 2017 +0800 MdePkg: Add UEFI 2.7 defined GUID and structure for AIP network media type. Reviewed-by: Fu Siyuan Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang Fan commit 4d150848c51f39363fec01779514baa8394d68c5 Author: Jiewen Yao Date: Wed Sep 6 12:07:11 2017 +0800 IntelSiliconPkg/VTd: improve debug message. Add /n for debug message to make error more readable. Suggested-by: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao Reviewed-by: Star Zeng commit 60794ee6b0c86c103ab227b0d9c2968c9c74810e Author: Jiewen Yao Date: Mon Sep 4 09:28:26 2017 +0800 IntelFramdworkModulePkg/
[Xen-devel] [xen-4.8-testing test] 113075: regressions - trouble: blocked/broken/fail/pass
flight 113075 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/113075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm broken build-arm64-pvopsbroken test-xtf-amd64-amd64-3 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112944 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112944 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 112944 build-arm64-xsm 2 hosts-allocate broken like 112944 build-arm64-pvops 3 capture-logsbroken like 112944 build-arm64-xsm 3 capture-logsbroken like 112944 build-arm64 2 hosts-allocate broken like 112944 build-arm64 3 capture-logsbroken like 112944 test-xtf-amd64-amd64-1 48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112916 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 112916 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112944 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112944 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112944 test-amd64-amd64-xl-rtds 10 debian-install fail like 112944 build-i386-prev 7 xen-build/dist-test fail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-pvh-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-amd64-libvirt-xsm 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64
Re: [Xen-devel] [PATCH] x86: introduce and use setup_force_cpu_cap()
On 09/05/2017 06:22 AM, Jan Beulich wrote: > For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd > need to clone the respective hack used for CPUID_FAULTING. Introduce an > inverse of setup_clear_cpu_cap() instead, but let clearing of features > overrule forced setting of them. > > XEN_SMAP being wrong post-boot is a problem specifically for live > patching, as a live patch may need alternative instruction patching > keyed off of that feature flag. > > Reported-by: Sarah Newman > Signed-off-by: Jan Beulich Reported-by/Tested-by: Sarah Newman Some questions: It looks like setup_clear_cpu_cap has a search for dependent capabilities that also must be cleared. Does the same need to happen for setup_force_cpu_cap even if it doesn't matter for the current cpu features? Does it make sense to add a comment where forced_caps is declared that cleared_caps overrides forced_caps instead of just in the commit message? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113111: trouble: broken/pass
flight 113111 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113111/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 16 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days4 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6
[Xen-devel] [ovmf test] 113078: all pass - PUSHED
flight 113078 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113078/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b80a4097393c90d041b299ef628e6104612a2586
baseline version:
ovmf 3f3a69b87a2d9b8e0186f6c078302614f55a3357
Last test of basis 113061 2017-09-06 02:03:48 Z0 days
Failing since113069 2017-09-06 08:22:21 Z0 days2 attempts
Testing same since 113078 2017-09-06 11:47:39 Z0 days1 attempts
People who touched revisions under test:
Eric Dong
Fu Siyuan
Jiewen Yao
Ruiyu Ni
Wang 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 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 :
+ branch=ovmf
+ revision=b80a4097393c90d041b299ef628e6104612a2586
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
b80a4097393c90d041b299ef628e6104612a2586
+ branch=ovmf
+ revision=b80a4097393c90d041b299ef628e6104612a2586
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' xb80a4097393c90d041b299ef628e6104612a2586 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git:/
[Xen-devel] [qemu-mainline test] 113073: trouble: blocked/broken/fail/pass
flight 113073 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/113073/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-i386 10 freebsd-install fail in 113060 pass in 113073 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail pass in 113060 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 113060 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113036 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 2 hosts-allocate broken like 113036 build-arm64-xsm 2 hosts-allocate broken like 113036 build-arm64-pvops 2 hosts-allocate broken like 113036 build-arm64-xsm 3 capture-logsbroken like 113036 build-arm64 3 capture-logsbroken like 113036 build-arm64-pvops 3 capture-logsbroken like 113036 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 113036 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 113060 like 113036 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113036 test-amd64-amd64-xl-rtds 10 debian-install fail like 113036 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113036 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113036 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 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-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuub07d1c2f5607489d4d4a6a65ce36a3e896ac065e baseline version: qemuu32f0f68bb77289b75a82925f712bb52e16eac3ba Last test of basis 113036 2017-09-04 09:16:59 Z2 days Failing since
[Xen-devel] [xtf test] 113077: all pass - PUSHED
flight 113077 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113077/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 7001ab0503fe91e4962ab270efc88d12412e3cb7
baseline version:
xtf 295eeb7e3cd8c506c5ade03865a0e440a5cd8b22
Last test of basis 112985 2017-08-31 13:15:43 Z6 days
Testing same since 113077 2017-09-06 11:47:34 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64-xtf pass
build-amd64 pass
build-amd64-pvopspass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 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 :
+ branch=xtf
+ revision=7001ab0503fe91e4962ab270efc88d12412e3cb7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf
7001ab0503fe91e4962ab270efc88d12412e3cb7
+ branch=xtf
+ revision=7001ab0503fe91e4962ab270efc88d12412e3cb7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x7001ab0503fe91e4962ab270efc88d12412e3cb7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x '
[Xen-devel] [xen-unstable-smoke test] 113108: trouble: broken/pass
flight 113108 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113108/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 15 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days3 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6
Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass
On Wed, 2017-09-06 at 12:29 -0700, Stefano Stabellini wrote: > On Wed, 6 Sep 2017, Dario Faggioli wrote: > > > > Or, in general, make sense out of the fact that the stack pointer > > register changes in such a way that, when we get back in > > do_softirq(), > > what's in the stack in the place where there was the 'cpu' local > > variable has (at least in some circumstances) changed? > > I think yes, it could cause the smp_processor_id() mismatch. > Ok, then the patch was wrong (sorry again), and should stay reverted. I still find the comment very confusing (if correct at all), and I'll probably send a new patch to improve it. Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 113072: trouble: blocked/broken/fail/pass
flight 113072 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/113072/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-arm64-pvops 3 capture-logs broken REGR. vs. 112102 Tests which are failing intermittently (not blocking): test-armhf-armhf-examine 7 reboot fail in 113058 pass in 113072 test-armhf-armhf-xl-xsm 16 guest-start/debian.repeat fail in 113058 pass in 113072 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 113058 pass in 113072 test-armhf-armhf-xl-cubietruck 19 leak-check/check fail in 113058 pass in 113072 test-armhf-armhf-libvirt-raw 6 xen-installfail pass in 113058 test-armhf-armhf-xl-rtds 7 xen-boot fail pass in 113058 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 113058 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 112102 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 112102 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 112102 build-arm64-xsm 3 capture-logs broken blocked in 112102 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 112102 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 112102 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 113058 blocked in 112102 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 113058 like 112102 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 113058 like 112102 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 113058 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 113058 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 113058 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 112102 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 112102 test-amd64-amd64-xl-rtds 10 debian-install fail like 112102 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-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-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-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-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm
[Xen-devel] [linux-next test] 113070: regressions - trouble: blocked/broken/fail/pass
flight 113070 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/113070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm broken build-arm64-pvopsbroken test-armhf-armhf-libvirt-raw broken test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 113056 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113056 test-armhf-armhf-libvirt-xsm 10 debian-install fail REGR. vs. 113056 test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 113056 test-armhf-armhf-libvirt-raw 18 leak-check/check fail REGR. vs. 113056 test-armhf-armhf-libvirt 10 debian-install fail REGR. vs. 113056 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 2 hosts-allocate broken like 113056 build-arm64 2 hosts-allocate broken like 113056 build-arm64-pvops 2 hosts-allocate broken like 113056 build-arm64-xsm 3 capture-logsbroken like 113056 build-arm64 3 capture-logsbroken like 113056 build-arm64-pvops 3 capture-logsbroken like 113056 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail like 113056 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail like 113056 test-amd64-i386-libvirt 7 xen-boot fail like 113056 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail like 113056 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail like 113056 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail like 113056 test-amd64-i386-pair 10 xen-boot/src_hostfail like 113056 test-amd64-i386-pair 11 xen-boot/dst_hostfail like 113056 test-amd64-i386-xl-xsm7 xen-boot fail like 113056 test-amd64-i386-freebsd10-i386 7 xen-bootfail like 113056 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail like 113056 test-amd64-i386-xl7 xen-boot fail like 113056 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail like 113056 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 113056 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-bootfail like 113056 test-amd64-i386-freebsd10-amd64 7 xen-boot fail like 113056 test-amd64-i386-examine 7 reboot fail like 113056 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail like 113056 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail like 113056 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail like 113056 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail like 113056 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 113056 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail like 113056 test-amd64-i386-xl-raw7 xen-boot fail like 113056 test-amd64-i386-rumprun-i386 7 xen-boot fail like 113056 test-amd64-i386-libvirt-xsm 7 xen-boot fail like 113056 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail like 113056 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-bootfail like 113056 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 113056 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail like 113056 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail like 113056 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113056 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saveres
[Xen-devel] [xen-unstable-smoke test] 113102: trouble: broken/pass
flight 113102 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113102/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 14 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days2 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6
[Xen-devel] [ovmf bisection] complete build-amd64-xsm
branch xen-unstable xenbranch xen-unstable job build-amd64-xsm testid xen-build Tree: ovmf https://github.com/tianocore/edk2.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: ovmf https://github.com/tianocore/edk2.git Bug introduced: 5aae2d35de031a38e7812c615ff6bce36b31466a Bug not present: 12cfc9009e7cf1a69ca675110c2cf6e21b152992 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113103/ commit 5aae2d35de031a38e7812c615ff6bce36b31466a Author: Fu Siyuan Date: Mon Sep 4 16:04:13 2017 +0800 MdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify. The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip4IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Reviewed-by: Ye Ting For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-amd64-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/ovmf/build-amd64-xsm.xen-build --summary-out=tmp/113103.bisection-summary --basis-template=113061 --blessings=real,real-bisect ovmf build-amd64-xsm xen-build Searching for failure / basis pass: 113069 fail [host=godello1] / 113061 [host=godello0] 113050 ok. Failure / basis pass flights: 113069 / 113050 (tree with no url: minios) (tree with no url: seabios) Tree: ovmf https://github.com/tianocore/edk2.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 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Basis pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#56e88e9e5f980e30f28d907e0ff442e4dc8dc5de-9a04dcffbb1e59333e500a8ce66e01a562be8b4f git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#c7c6232bd304568d4da4bef521603aae0035e172-c7c6232bd304568d4da4bef521603aae0035e172 git://xenbits.xen.org/xen.git#ee2c1fc48ac14a4c8b9eb9224753591fa5e7-ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Loaded 1001 nodes in revision graph Searching for test results: 113050 pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113061 [host=godello0] 113091 pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113093 fail 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113094 pass 60794ee6b0c86c103ab227b0d9c2968c9c74810e 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113069 fail 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113095 pass d51b0122bf9bd1df831c77b5669bfbb66aaa4874 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113096 pass 12cfc9009e7cf1a69ca675110c2cf6e21b152992 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113098 fail 5aae2d35de031a38e7812c615ff6bce36b31466a 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113099 pass 12cfc9009e7cf1a69ca675110c2cf6e21b152992 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113100 fail 5aae2d35de031a38e7812c615ff6bce36b31466a 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa
Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass
On Wed, 6 Sep 2017, Dario Faggioli wrote: > On Tue, 2017-09-05 at 15:06 -0700, Stefano Stabellini wrote: > > On Tue, 5 Sep 2017, Dario Faggioli wrote: > > > > > > Re-checking things now, I actually do see that context_switch() on > > > ARM > > > is not 'terminal'. It call schedule_tail(), which on x86 does not > > > return, while in ARM, it does. I must have confused these two... > > > Sorry. > > > > > > Also, mostly out of curiosity, still looking at ARM code, I'm not > > > getting at all how continue_new_vcpu() works (e.g., when/how is it > > > invoked?). > > > > On ARM, context_switch() returns, unless it's the first time a new > > vcpu > > is run. In that case pc is set to continue_new_vcpu. __context_switch > > restores pc to continue_new_vcpu, returning to it. > > > Ah, yes, that's what I was missing! The fact that PC is assigned the > adress of continue_new_vcpu().. that's how it run. Only the first time, > as you're explaining. > > Thanks! :-) > > > From the second time onward a vcpu is run, > > context_switch returns normally. > > > Right. And you (or someone else) can also confirm that the stack is > per-vCPU? Yes, we have a per-vCPU stack on ARM. > Or, in general, make sense out of the fact that the stack pointer > register changes in such a way that, when we get back in do_softirq(), > what's in the stack in the place where there was the 'cpu' local > variable has (at least in some circumstances) changed? I think yes, it could cause the smp_processor_id() mismatch. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 09/10] build/fedora: Add `RUNNING_STAGE1_XEN.md`
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > Signed-off-by: Rajiv Ranganath This is very detailed, good stuff. I have one question below: > + > +## Booting into Xen > + > +Build and install Xen and stage1-xen. Please see > [BUILDING.md](/BUILDING.md#build_fedora). > + > +If you followed the container build with Docker, then copy over > `stage1-xen-build.tar.gz`. Extract `stage1-xen-build.tar.gz` into `/opt` > directory. > + > +```shell > +[root@localhost ~]# tar zxvf stage1-xen-build.tar.gz -C /opt > + > +[root@localhost ~]# ls /opt > +qemu-unstable stage1-xen xen-unstable xen-unstable-runit > +``` > + > +This will extract all the build artifacts into `/opt` directory. Is there a reason to keep all the binaries under /opt? I mean, at this point, we could do something like cp -ar /opt/xen-unstable/* / and do the same for the other components. Do we keep them under /opt for ease of management, so that the next time we do a build, we can easily test with a different Xen version? Or is there another reason? > +Next we will create a BIOS Boot Menu entry to boot `xen-4.10-unstable.efi`. > This will start Xen hypervisor. Xen will then start Fedora as Dom-0 guest. > + > +On Fedora, EFI system partition (ESP) is usually mounted at `/boot/efi`. > This is a `vfat` partition. You can check if EFI system partition is mounted > as follows – > + > +```shell > +[root@localhost ~]# mount | grep '\/boot\/efi' > +/dev/sda1 on /boot/efi type vfat > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro) > +``` > + > +Create a directory for Xen under `/boot/efi/EFI` and copy over > `xen-4.10-unstable.efi`. > + > +```shell > +[root@localhost ~]# mkdir -p /boot/efi/EFI/xen > +[root@localhost ~]# cp > /opt/xen-unstable/boot/efi/EFI/xen/xen-4.10-unstable.efi /boot/efi/EFI/xen/ > +``` > + > +Inspect `/boot/efi/EFI/fedora/grub.cfg`. Under section `### BEGIN > /etc/grub.d/10_linux ###` you will find `menuentry` for Fedora kernel and > initrd. Look for `linuxefi` and `initrdefi`. Copy over the `vmlinuz` and > `initramfs` files that you want to use for your Dom-0 into > `/boot/efi/EFI/xen` directory. > + > +```shell > +[root@localhost ~]# cp /boot/vmlinuz-A.B.C-D.fcXX.x86_64 /boot/efi/EFI/xen/ > + > +[root@localhost ~]# cp /boot/initramfs-A.B.C-D.fcXX.x86_64.img > /boot/efi/EFI/xen/ > +``` > + > +Now in `/boot/efi/EFI/xen/` you should have the following files. > + > +```shell > +[root@localhost ~]# ls /boot/efi/EFI/xen/ > +initramfs-A.B.C-D.fcXX.x86_64.img vmlinuz-A.B.C-D.fcXX.x86_64 > xen-4.10-unstable.efi > +``` > + > +Next create a file `xen-4.10-unstable.cfg` in `/boot/efi/EFI/xen/`. This is > the [configuration file](https://xenbits.xen.org/docs/unstable/misc/efi.html) > that Xen EFI loader will use to load Dom-0 kernel and initrd. > + > +Following are contents of `xen-4.10-unstable.cfg` > + > +``` > +[global] > +default=fedora-A.B.C-D.fc25 > + > +[fedora-A.B.C-D.fc25] > +options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan > flask=disabled conring_size=2097152 loglvl=all autoballoon=0 > dom0_mem=4096M,max:4096M > +kernel=vmlinuz-A.B.C-D.fc25.x86_64 > root=UUID=---- ro rhgb console=hvc0 > console=tty0 > +ramdisk=initramfs-A.B.C-D.fc25.x86_64.img > +``` > + > +You can find the boot parameters for `kernel=` from `linuxefi` entry in > `/boot/efi/EFI/fedora/grub.cfg` Adjust `dom0_mem` appropriately leaving > sufficient room for dom-U guests. > + > +We can now use `efibootmgr` to create a boot entry for Xen. If this the > first time you are using `efibootmgr` please checkout the man pages by doing > `man efibootmgr`. > + > +Use `efibootmgr -v` to list all the EFI boot entires. > + > +```shell > +[root@localhost ~]# efibootmgr -v > +BootCurrent: 0002 > +Timeout: 2 seconds > +BootOrder: ... > + > +[...] > + > +Boot0001* Xen > HD(1,GPT,7d511991-1c25-4e33-900b-1d61d7752f19,0x800,0x82000)/File(\EFI\xen\xen-4.10-unstable.efi) > +Boot0002* Fedora > HD(1,GPT,7d511991-1c25-4e33-900b-1d61d7752f19,0x800,0x82000)/File(\EFI\fedora\shim.efi) > + > +[...] > +``` > + > +In the above example there is already an entry for Xen with a boot number of > `1`. Fedora is at boot number `2`. Your entires would look different. You > won't have the Xen entry as yet! We are showing you an example where the Xen > boot entry has already been created. > + > +Let us now create a boot entry for Xen. First we need to identify the disk > and the partition number for EFI system partition. In most cases it is at > `/dev/sda1`. You can identify this by doing – > + > +```shell > +[root@localhost ~]# df /boot/efi > +Filesystem 1K-blocks Used Available Use% Mounted on > +/dev/sda1 262128 63019199109 25% /boot/efi > + > +[root@localhost ~]# sgdisk -p /dev/sda > +Disk /dev/sda: 976773168 sectors, 465.8 GiB > +Logical sector size: 512 bytes > + > +[...] > + > +Number Start (sector)End (sector) Size Code N
[Xen-devel] [linux-linus test] 113067: regressions - trouble: blocked/broken/fail/pass
flight 113067 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113067/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm broken build-arm64-pvopsbroken test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-examine 7 reboot fail REGR. vs. 113031 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 113031 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 113031 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 113031 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 113031 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 113031 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 113031 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 113031 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail REGR. vs. 113031 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 2 hosts-allocate broken like 113031 build-arm64-pvops 2 hosts-allocate broken like 113031 build-arm64-xsm 3 capture-logsbroken like 113031 build-arm64-pvops 3 capture-logsbroken like 113031 build-arm64 2 hosts-allocate broken like 113031 build-arm64 3 capture-logsbroken like 113031 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 113031 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113031 test-armhf-armhf-xl-rtds 12 guest-start fail like 113031 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113031 test-amd64-amd64-xl-rtds 10 debian-install fail like 113031 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113031 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 1
Re: [Xen-devel] [stage1-xen PATCH v1 10/10] BUILDING.md: Add Fedora instructions
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > Signed-off-by: Rajiv Ranganath Reviewed-by: Stefano Stabellini > --- > BUILDING.md | 96 > --- > 1 file changed, 91 insertions(+), 5 deletions(-) > > diff --git a/BUILDING.md b/BUILDING.md > index 3ef5311..946c799 100644 > --- a/BUILDING.md > +++ b/BUILDING.md > @@ -1,7 +1,13 @@ > # Build > -stage1-xen requires new Xen and QEMU versions at the time of writing. You > are unlikely to find them already packaged with your distro. This document > describes how to build and install the latest Xen and QEMU from scratch. In > addition, given that CoreOS rkt is also missing from reasonably new distros > such as Ubuntu Xenial Xerus, I added instructions on how to build that too. > The document includes the dependencies needed for the build based on Ubuntu > Xenial Xerus. > +stage1-xen requires new Xen and QEMU versions at the time of writing. You > are unlikely to find them already packaged with your distro. This document > describes how to build and install the latest Xen, QEMU and rkt from scratch > for Ubuntu Xenial Xerus and Fedora. Differently from documentation for > Ubuntu, the documentation for Fedora uses a Docker container for the build. > There is also support for building on host on Fedora. > > -## Building Xen > + * [Ubuntu Xenial Xerus](#build_ubuntu) > + * [Fedora](#build_fedora) > + > + > +## Ubuntu Xenial Xerus > + > +### Building Xen > ``` > apt-get install git build-essential python-dev gettext uuid-dev > libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev libssl-dev > libpixman-1-dev bridge-utils wget libfdt-dev bin86 bcc liblzma-dev iasl > libc6-dev-i386 > > @@ -17,7 +23,7 @@ reboot > Make sure to select Xen at boot, or edit /boot/grub/grub.cfg to make it the > default, changing "set default="0" to point to the appropriate entry below > (the one booting xen.gz), which could be entry number "4" for example. > > > -## Building QEMU > +### Building QEMU > ``` > apt-get install libglib2.0-dev libpixman-1-dev libcap-dev libattr1-dev > > @@ -54,7 +60,7 @@ make install > cp i386-softmmu/qemu-system-i386 /usr/lib/xen/bin/ > ``` > > -## Building CoreOS rkt > +### Building CoreOS rkt > ``` > apt-get install golang automake libacl1-dev libsystemd-dev > ./configure --disable-tpm --with-stage1-flavors=coreos > @@ -62,7 +68,7 @@ make > cp build-rkt-1.26.0+git/target/bin/rkt /usr/sbin > ``` > > -## Building stage1-xen > +### Building stage1-xen > ``` > apt-get install busybox-static jq > > @@ -72,3 +78,83 @@ export GOPATH=/path/to/gopath > bash build.sh > cp stage1-xen.aci /home/username > ``` > + > + > +## Fedora > + > +On Fedora there are two ways to build stage1-xen artifacts. > + > + * [Container Build](#build_fedora_container_build) > + * [Manual Build](#build_fedora_manual_build) > + > + > +### Container Build > + > +We can build stage1-xen artifacts (Xen, QEMU and rkt) automatically in a > docker container as follows – > + > +``` > +cd stage1-xen > + > +docker pull lambdalinuxfedora/stage1-xen-fedora-buildroot > + > +docker run --rm \ > + -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \ > + -v /tmp:/tmp \ > + -t -i lambdalinuxfedora/stage1-xen-fedora-buildroot \ > + /sbin/my_init -- /root/bin/run > +``` > + > +Once `docker run` completes, the build artifact `stage1-xen-build.tar.gz` is > generated in `/tmp` directory. Please see > [RUNNING_STAGE1_XEN.md](build/fedora/RUNNING_STAGE1_XEN.md) for details on > how to setup Fedora for running stage1-xen. > + > + > +### Manual Build > + > +It is also possible to manually build stage1-xen components on a Fedora > host. > + > +Please ensure that you have all the dependencies installed. The dependencies > for Xen, QEMU, rkt and stage1-xen is documented in > [buildroot-Dockerfile](build/fedora/buildroot-Dockerfile). You will also need > to install [`binutils`](https://github.com/lambda-linux-fedora/binutils) > package that is compiled with `i386pe` support. You can download the > pre-built RPMs from > [here](https://drive.google.com/open?id=0B_tTbuxmuRzIR05wQ3E1eWVyaGs). > + > +Install `binutils` package. > + > +``` > +tar xvf binutils-2.26.1-1.1.fc25.tar > + > +dnf install -y > ./binutils/2.26.1/1.1.fc25/x86_64/binutils-2.26.1-1.1.fc25.x86_64.rpm > +``` > + > +You can verify `i386pe` support in `binutils` by doing the following. > + > +``` > +[root@localhost]# ld -V > +GNU ld version 2.26.1-1.1.fc25 Supported emulations: > + elf_x86_64 > + elf32_x86_64 > + elf_i386 > + elf_iamcu > + i386linux > + elf_l1om > + elf_k1om > + i386pep > + i386pe > +``` > + > +You should see the lines `i386pep` and `i386pe` in the output. > + > +Next you can build Xen, Qemu and rkt using the following scripts – > + > + * [`build/fedora/components/xen`](build/fedora/components/xen) > + * [`build/fedora/components/qemu`](build/fedora/components/qemu) > + * [`build/fedora/com
Re: [Xen-devel] [stage1-xen PATCH v1 07/10] .circleci/config.yml: Add
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > From: Rajiv M Ranganath > > Signed-off-by: Rajiv Ranganath Reviewed-by: Stefano Stabellini > --- > .circleci/config.yml | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 .circleci/config.yml > > diff --git a/.circleci/config.yml b/.circleci/config.yml > new file mode 100644 > index 000..93315b4 > --- /dev/null > +++ b/.circleci/config.yml > @@ -0,0 +1,21 @@ > +version: 2 > +jobs: > + build: > +working_directory: /root > +docker: > + - image: lambdalinuxfedora/stage1-xen-fedora-buildroot:1708260126 > +command: /sbin/my_init > +steps: > + - run: > + # We create `stage1-xen` directory in Dockerfile for local dev > + # environment. Removing it here so CircleCI checkout step can work > + # correctly > + name: Removing stage1-xen directory from GOPATH... > + command: | > +rm -rf /root/gopath/src/github.com/rkt/stage1-xen > + - checkout: > + path: /root/gopath/src/github.com/rkt/stage1-xen > + - run: > + name: Starting run... > + command: | > +/root/bin/run > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
> ---
> build/fedora/components/qemu | 50
> build/fedora/components/rkt | 58
> ++
> build/fedora/components/xen | 46 +
> build/fedora/run | 56 +
> 4 files changed, 210 insertions(+)
> create mode 100755 build/fedora/components/qemu
> create mode 100755 build/fedora/components/rkt
> create mode 100755 build/fedora/components/xen
> create mode 100755 build/fedora/run
>
> diff --git a/build/fedora/components/qemu b/build/fedora/components/qemu
> new file mode 100755
> index 000..6c89e2c
> --- /dev/null
> +++ b/build/fedora/components/qemu
> @@ -0,0 +1,50 @@
> +#!/usr/bin/python2
> +
> +import shlex
> +import subprocess
> +import sys
> +import os
> +
> +# Modify this if you would like to install Qemu elsewhere on your filesystem
> or
> +# a different version of Qemu
> +QEMU_PREFIX = '/opt/qemu-unstable'
> +QEMU_BRANCH = 'master'
I am not sure we want to checkout always the latest QEMU. It is a
running target. It makes sense to use one of the latest releases
instead, such as v2.10.0?
> +# This should correspond to your Xen install prefix
> +XEN_PREFIX = '/opt/xen-unstable'
> +
> +
> +# helper function to capture stdout from a long running process
> +def subprocess_stdout(cmd, cwd, env):
> +p = subprocess.Popen(
> +shlex.split(cmd), cwd=cwd, env=env, stdout=subprocess.PIPE)
> +while p.poll() is None:
> +l = p.stdout.readline()
> +sys.stdout.write(l)
> +if p.returncode != 0:
> +sys.exit(1)
Is this the same as
#!/bin/bash
set -e
?
Please add a few words in the commit message about the benefit of this
approach of writing scripts.
> +env = os.environ.copy()
> +
> +# build and install qemu
> +print "Cloning qemu..."
> +cmd = "git clone --branch %(branch)s git://git.qemu.org/qemu.git" % {
> +'branch': QEMU_BRANCH
> +}
> +subprocess.check_output(shlex.split(cmd), cwd='/root')
> +
> +steps = [
> +"./configure --prefix=%(qemu_prefix)s --enable-xen
> --target-list=i386-softmmu --extra-cflags=\"-I%(xen_prefix)s/include\"
> --extra-ldflags=\"-L%(xen_prefix)s/lib -Wl,-rpath,%(xen_prefix)s/lib\"
> --disable-kvm --enable-virtfs --enable-linux-aio"
> +% {
> +'qemu_prefix': QEMU_PREFIX,
> +'xen_prefix': XEN_PREFIX
> +}, 'make', 'make install'
> +]
> +for cmd in steps:
> +cwd = '/root/qemu'
> +subprocess_stdout(cmd, cwd, env)
> +
> +cmd = "cp i386-softmmu/qemu-system-i386
> %(xen_prefix)s/lib/xen/bin/qemu-system-i386" % {
> +'xen_prefix': XEN_PREFIX
> +}
> +subprocess.check_output(shlex.split(cmd), cwd='/root/qemu')
> diff --git a/build/fedora/components/rkt b/build/fedora/components/rkt
> new file mode 100755
> index 000..edfdd1c
> --- /dev/null
> +++ b/build/fedora/components/rkt
> @@ -0,0 +1,58 @@
> +#!/usr/bin/python2
> +
> +import shlex
> +import subprocess
> +import sys
> +import os
> +
> +# `rkt` is installed in the same prefix as `stage1-xen`. Modify this if you
> +# would like to install rkt elsewhere on your filesystem.
> +STAGE1_XEN_PREFIX = '/opt/stage1-xen'
> +RKT_PREFIX = STAGE1_XEN_PREFIX
> +RKT_BRANCH = 'master'
> +
> +# Adjust this according to what RKT_BRANCH generates
> +RKT_BUILD_VER = 'rkt-1.28.1+git'
I think it would be best if git-checked out the tag (v1.28.1) so that we
are sure there are no version mismatches. In fact, I would remove
RKT_BRANCH and just use a single variable to specify the version to
clone and build.
> +# helper function to capture stdout from a long running process
> +def subprocess_stdout(cmd, cwd, env):
> +p = subprocess.Popen(
> +shlex.split(cmd), cwd=cwd, env=env, stdout=subprocess.PIPE)
> +while p.poll() is None:
> +l = p.stdout.readline()
> +sys.stdout.write(l)
> +if p.returncode != 0:
> +sys.exi(1)
> +
> +
> +env = os.environ.copy()
> +
> +# build rkt
> +print "Cloning rkt..."
> +cmd = "git clone --branch %(branch)s https://github.com/rkt/rkt.git"; % {
> +'branch': RKT_BRANCH
> +}
> +subprocess.check_output(shlex.split(cmd), cwd='/root')
> +
> +steps = [
> +'./autogen.sh', './configure --disable-tpm --with-stage1-flavors=coreos',
> +'make'
> +]
> +for cmd in steps:
> +cwd = '/root/rkt'
> +subprocess_stdout(cmd, cwd, env)
> +
> +# install rkt build artifacts to RKT_PREFIX
> +steps = [
> +"mkdir -p %(prefix)s/bin" % {
> +'prefix': RKT_PREFIX
> +},
> +"cp /root/rkt/build-%(build_ver)s/target/bin/rkt %(prefix)s/bin/rkt" % {
> +'build_ver': RKT_BUILD_VER,
> +'prefix': RKT_PREFIX
> +}
> +]
> +for cmd in steps:
> +cwd = '/root/rkt'
> +subprocess_stdout(cmd, cwd, env)
> diff --git a/build/fedora/components/xen b/build/fedora/components/xen
> new file mode 100755
> index 000..95
Re: [Xen-devel] [stage1-xen PATCH v1 08/10] README.md: Add CircleCI badge
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > From: Rajiv M Ranganath > > Signed-off-by: Rajiv Ranganath Reviewed-by: Stefano Stabellini > --- > README.md |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/README.md b/README.md > index 9ea6adf..e1cd40c 100644 > --- a/README.md > +++ b/README.md > @@ -1,5 +1,7 @@ > # stage1-xen - A Xen based stage1 for CoreOS rkt > > +[](https://circleci.com/gh/rkt/stage1-xen/tree/master) > + > ## Goal > > CoreOS rkt is a modular container engine with [three stages of > execution](https://coreos.com/rkt/docs/latest/devel/stage1-implementors-guide.html). > Stage1 is responsible for creating the execution environment for the > contained applications. > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 01/10] .gitignore: Add
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > From: Rajiv M Ranganath > > Signed-off-by: Rajiv Ranganath Reviewed-by: Stefano Stabellini > --- > .gitignore |2 ++ > 1 file changed, 2 insertions(+) > create mode 100644 .gitignore > > diff --git a/.gitignore b/.gitignore > new file mode 100644 > index 000..873f8f6 > --- /dev/null > +++ b/.gitignore > @@ -0,0 +1,2 @@ > +# build/fedora > +build/fedora/binutils-*.tar > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 02/10] build/fedora: Add `buildroot-README.md`
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > From: Rajiv M Ranganath > > Signed-off-by: Rajiv Ranganath Reviewed-by: Stefano Stabellini > --- > build/fedora/buildroot-README.md | 50 > ++ > 1 file changed, 50 insertions(+) > create mode 100644 build/fedora/buildroot-README.md > > diff --git a/build/fedora/buildroot-README.md > b/build/fedora/buildroot-README.md > new file mode 100644 > index 000..0efb150 > --- /dev/null > +++ b/build/fedora/buildroot-README.md > @@ -0,0 +1,50 @@ > +## stage1-xen Fedora Buildroot > + > +stage1-xen build artifacts for Fedora is built in two phases. In the first > phase > +a docker container is prepared with all the build dependencies. We refer to > it > +as `stage1-xen-fedora-buildroot`. In the next phase we execute the `run` > script > +that uses `stage1-xen-fedora-buildroot` and to produce the build artifacts. > + > +### Building `stage1-xen-fedora-buildroot` > + > +`stage1-xen-fedora-buildroot` has a external dependency > +on [`binutils`](https://github.com/lambda-linux-fedora/binutils) package > that is > +compiled with `i386pe` support. You can download the pre-built RPMs > +from [here](https://drive.google.com/open?id=0B_tTbuxmuRzIR05wQ3E1eWVyaGs). > +Please download `binutils-2.26.1-1.1.fc25.tar`. > + > +To build docker image > + > +``` > +cd stage1-xen/build/fedora > + > +docker build -f buildroot-Dockerfile -t stage1-xen-fedora-buildroot . > +``` > + > +### Running `stage1-xen-fedora-buildroot` > + > +``` > +cd stage1-xen > + > +docker run --rm \ > + -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \ > + -v /tmp:/tmp \ > + -t -i stage1-xen-fedora-buildroot \ > + /sbin/my_init -- /root/bin/run > +``` > + > +The generated build artifacts are in `/tmp` directory. > + > +To debug build issues - > + > +``` > +cd stage1-xen > + > +docker run --rm \ > + -v `pwd`:/root/gopath/src/github.com/rkt/stage1-xen \ > + -v /tmp:/tmp \ > + -t -i stage1-xen-fedora-buildroot \ > + /sbin/my_init -- /bin/bash > +``` > + > +Also see section on `ipdb` in `buildroot-Dockerfile`. > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 03/10] build/fedora: Add `buildroot-Dockerfile`
On Sun, 27 Aug 2017, Rajiv Ranganath wrote:
> From: Rajiv M Ranganath
>
> Signed-off-by: Rajiv Ranganath
Reviewed-by: Stefano Stabellini
> ---
> build/fedora/buildroot-Dockerfile | 113
> +
> 1 file changed, 113 insertions(+)
> create mode 100644 build/fedora/buildroot-Dockerfile
>
> diff --git a/build/fedora/buildroot-Dockerfile
> b/build/fedora/buildroot-Dockerfile
> new file mode 100644
> index 000..971560e
> --- /dev/null
> +++ b/build/fedora/buildroot-Dockerfile
> @@ -0,0 +1,113 @@
> +# tarballs checksum
> +# -
> +# 974b3091232d781c4fc410ccca98fb62ba9febe9e6a988e348804483c4f66742
> binutils-2.26.1-1.1.fc25.tar
> +
> +FROM lambdalinuxfedora/baseimage-fedora
> +
> +CMD ["/sbin/my_init"]
> +
> +COPY [ \
> + "./binutils-2.26.1-1.1.fc25.tar", \
> + \
> + "./components/*", \
> + "./run", \
> + "/tmp/docker-build/" \
> +]
> +
> +RUN \
> + # dnf
> + echo "Running dnf update..." && \
> + dnf update -y && \
> + dnf install -y less && \
> + dnf install -y sudo && \
> + \
> + # circleci container requirements
> + #
> https://circleci.com/docs/2.0/custom-images/#adding-required-and-custom-tools-or-files
> + dnf install -y git && \
> + dnf install -y openssh-clients && \
> + dnf install -y tar && \
> + dnf install -y gzip && \
> + dnf install -y ca-certificates && \
> + \
> + # install `binutils`
> + pushd /tmp/docker-build && \
> +# verify checksum
> +echo "974b3091232d781c4fc410ccca98fb62ba9febe9e6a988e348804483c4f66742
> binutils-2.26.1-1.1.fc25.tar" | sha256sum -c - && \
> +tar xvf binutils-2.26.1-1.1.fc25.tar && \
> +dnf install -y
> ./binutils/2.26.1/1.1.fc25/x86_64/binutils-2.26.1-1.1.fc25.x86_64.rpm && \
> + popd && \
> + \
> + dnf install -y @buildsys-build && \
> + \
> + # Having `ipdb` around is useful when debugging `run` script. Uncomment
> this
> + # section as required
> + # dnf install -y python2-devel && \
> + # dnf install -y python-pip && \
> + # su -l root -c "pip2 install --user ipdb==0.8 ipython==5.3.0" && \
> + \
> + # Note: xen and qemu has some duplicate package dependencies. We are
> + # explicitly calling out dependencies for xen and qemu
> + #
> + # xen build dependencies
> + dnf install -y bridge-utils && \
> + dnf install -y gettext && \
> + dnf install -y glib2-devel && \
> + dnf install -y glibc-devel.i686 && \
> + dnf install -y grub2 && \
> + dnf install -y iasl && \
> + dnf install -y libaio-devel && \
> + dnf install -y libuuid-devel && \
> + dnf install -y ncurses-devel && \
> + dnf install -y openssl-devel && \
> + dnf install -y pixman-devel && \
> + dnf install -y python2-devel && \
> + dnf install -y wget && \
> + dnf install -y yajl-devel && \
> + \
> + # qemu build dependencies
> + dnf install -y glib2-devel && \
> + dnf install -y libaio-devel && \
> + dnf install -y libattr-devel && \
> + dnf install -y libcap-devel && \
> + dnf install -y libcap-ng-devel && \
> + dnf install -y pixman-devel && \
> + dnf install -y zlib-devel && \
> + \
> + # rkt build dependencies
> + dnf install -y autoconf && \
> + dnf install -y automake && \
> + dnf install -y git && \
> + dnf install -y glibc-static && \
> + dnf install -y gnupg && \
> + dnf install -y golang && \
> + dnf install -y libacl-devel && \
> + dnf install -y squashfs-tools && \
> + dnf install -y systemd-devel && \
> + dnf install -y wget && \
> + \
> + # stage1-xen build dependencies
> + dnf install -y bc && \
> + dnf install -y busybox && \
> + dnf install -y glide && \
> + dnf install -y golang && \
> + dnf install -y jq && \
> + dnf install -y libacl-devel && \
> + dnf install -y wget && \
> + \
> + # copy `run` file and `components/{qemu,rkt,xen}`
> + su -l root -c "mkdir /root/bin" && \
> + su -l root -c "cp /tmp/docker-build/run /root/bin" && \
> + su -l root -c "mkdir /root/bin/components" && \
> + su -l root -c "cp /tmp/docker-build/qemu /root/bin/components" && \
> + su -l root -c "cp /tmp/docker-build/rkt /root/bin/components" && \
> + su -l root -c "cp /tmp/docker-build/xen /root/bin/components" && \
> + \
> + # create `stage1-xen` directory
> + mkdir -p /root/gopath/src/github.com/rkt/stage1-xen && \
> + \
> + # cleanup
> + rm -rf /tmp/docker-build && \
> + dnf clean all && \
> + rm -rf /var/cache/dnf/* && \
> + rm -rf /tmp/* && \
> + rm -rf /var/tmp/*
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts
On Sun, 27 Aug 2017, Rajiv Ranganath wrote: > From: Rajiv M Ranganath > > Signed-off-by: Rajiv Ranganath The series is much better now thank you. One question: why did you write your own init scripts rather than reusing xencommons (with the caveat that you would have to add make sure to source_path.sh before running xencommons)? Does it have something to do with systemd? > --- > build/fedora/xen-unstable-runit/setup.sh | 18 > build/fedora/xen-unstable-runit/teardown.sh| 18 > .../xen-init-dom0-disk-backend/run | 11 ++ > build/fedora/xen-unstable-runit/xen-init-dom0/run |9 > build/fedora/xen-unstable-runit/xenconsoled/run| 13 +++ > build/fedora/xen-unstable-runit/xenstored/run | 23 > > 6 files changed, 92 insertions(+) > create mode 100755 build/fedora/xen-unstable-runit/setup.sh > create mode 100755 build/fedora/xen-unstable-runit/teardown.sh > create mode 100755 > build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run > create mode 100755 build/fedora/xen-unstable-runit/xen-init-dom0/run > create mode 100755 build/fedora/xen-unstable-runit/xenconsoled/run > create mode 100755 build/fedora/xen-unstable-runit/xenstored/run > > diff --git a/build/fedora/xen-unstable-runit/setup.sh > b/build/fedora/xen-unstable-runit/setup.sh > new file mode 100755 > index 000..b5adf8c > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/setup.sh > @@ -0,0 +1,18 @@ > +#!/bin/bash > + > +set -e > + > +# runit RPM creates `/etc/service` directory > +if [ ! -d "/etc/service" ]; then > +echo "/etc/service directory not found. Please install runit RPM." > +exit 1 > +fi > + > +runit_services="xenconsoled xen-init-dom0 xen-init-dom0-disk-backend > xenstored" > + > +for service in $runit_services; do > +ln -sf /opt/xen-unstable-runit/$service /etc/service/$service > +done > + > +echo "Successfully created symlinks in /etc/service directory." > +exit 0 > diff --git a/build/fedora/xen-unstable-runit/teardown.sh > b/build/fedora/xen-unstable-runit/teardown.sh > new file mode 100755 > index 000..d333807 > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/teardown.sh > @@ -0,0 +1,18 @@ > +#!/bin/bash > + > +set -e > + > +# runit RPM creates `/etc/service` directory > +if [ ! -d "/etc/service" ]; then > +echo "/etc/service directory not found." > +exit 1 > +fi > + > +runit_services="xenconsoled xen-init-dom0 xen-init-dom0-disk-backend > xenstored" > + > +for service in $runit_services; do > +rm -f /etc/service/$service > +done > + > +echo "Successfully deleted symlinks in /etc/service directory." > +exit 0 > diff --git a/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run > b/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run > new file mode 100755 > index 000..6315d48 > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/xen-init-dom0-disk-backend/run > @@ -0,0 +1,11 @@ > +#!/bin/bash > + > +set -e > + > +sv check xenstored >/dev/null || exit 1 > +sv check xenconsoled >/dev/null || exit 1 > + > +# In case of failure, allow user to run teardown script > +sleep 5s > + > +exec /opt/xen-unstable/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach > -name dom0 -nographic -M xenpv -monitor /dev/null -serial /dev/null -parallel > /dev/null -nodefaults -no-user-config > diff --git a/build/fedora/xen-unstable-runit/xen-init-dom0/run > b/build/fedora/xen-unstable-runit/xen-init-dom0/run > new file mode 100755 > index 000..193ba19 > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/xen-init-dom0/run > @@ -0,0 +1,9 @@ > +#!/bin/bash > + > +set -e > + > +sv check xenstored >/dev/null || exit 1 > + > +/opt/xen-unstable/lib/xen/bin/xen-init-dom0 > + > +exec chpst -b xen-init-dom0 runit-pause > diff --git a/build/fedora/xen-unstable-runit/xenconsoled/run > b/build/fedora/xen-unstable-runit/xenconsoled/run > new file mode 100755 > index 000..b5b7a9f > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/xenconsoled/run > @@ -0,0 +1,13 @@ > +#!/bin/bash > + > +set -e > + > +sv check xen-init-dom0 >/dev/null || exit 1 > + > +[ ! -d /var/log/xen/console ] && mkdir -p /var/log/xen/console > + > +# In case of failure, allow user to run teardown script > +sleep 5s > + > +# --log=[none|guest|hv|all] > +exec /opt/xen-unstable/sbin/xenconsoled -i --log=none > diff --git a/build/fedora/xen-unstable-runit/xenstored/run > b/build/fedora/xen-unstable-runit/xenstored/run > new file mode 100755 > index 000..beb2a5f > --- /dev/null > +++ b/build/fedora/xen-unstable-runit/xenstored/run > @@ -0,0 +1,23 @@ > +#!/bin/bash > + > +set -e > + > +[ ! -d /var/run/xen ] && mkdir -p /var/run/xen > +[ ! -d /var/run/xenstored ] && mkdir -p /var/run/xenstored > +[ ! -d /var/log/xen ] && mkdir -p /var/log/xen > +[ ! -d /var/lib/xen ] && mkdir -p /var/lib/xen > +[ ! -d /var/lib/xen/dump ] && mkdir -p /var/lib/xen/dump > +[ ! -
[Xen-devel] [xen-unstable-smoke test] 113097: regressions - trouble: broken/fail/pass
flight 113097 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113097/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken test-armhf-armhf-xl 6 xen-install fail REGR. vs. 113039 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 65c256266477e72f455a45a54597d5816646c74f baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 13 attempts Testing same since 113097 2017-09-06 17:02:46 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu Yi Sun jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs Not pushing. commit 65c256266477e72f455a45a54597d5816646c74f Author: Yi Sun Date: Mon Sep 4 19:01:44 2017 +0800 tools: change the type of '*nr' in 'libxl_psr_cat_get_info' Due to historical reason, type of parameter '*nr' in 'libxl_psr_cat_get_info' is 'int'. But this is not right. It should be 'unsigned int'. This patch fixes this and does related changes. Suggested-by: Roger Pau Monné Signed-off-by: Yi Sun Acked-by: Wei Liu commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329 Author: Yi Sun Date: Mon Sep 4 19:01:43 2017 +0800 tools: use '__i386__' and '__x86_64__' to replace PSR macros The libxl interfaces and related functions are not necessary to be included by 'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86 macros. Furthermore, only compile 'xl_psr.c' under x86. Suggested-by: Roger Pau Monné Suggested-by: Wei Liu Signed-off-by: Yi Sun Reviewed-by: Roger Pau Monné Acked-by: Wei Liu commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6bfa782b18dfd43746f940bed Author: Andrew Cooper Date: Tue Sep 5 17:54:45 2017 +0100 x86/traps:
Re: [Xen-devel] Regarding changing memory for DOM0
On Wed, 30 Aug 2017, George John wrote: > Hai all, > Sorry for the delay > First of all Thank you very much for the quick reply. > I tried the same with MMC root .It boot up successfully but after typing > xl list I am getting following errors > > libxl: error: libxl.c:662:libxl_list_domain: getting domain info list: > Permission denied This is usually due to a mismatch of the version of the hypervisor and the version of the tools. > During next booting, the memory card got corrupted. > > > U-Boot 2015.04 (Feb 15 2017 - 15:16:02) > > CPU: Renesas Electronics R8A7795 rev 1.1 > Board: Salvator-X > I2C: ready > DRAM: 3.9 GiB > MMC: sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2 > In: serial > Out: serial > Err: serial > Net: Board Net Initialization Failed > No ethernet found. > Hit any key to stop autoboot: 0 > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type ** > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type ** > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type ** > Failed to mount ext2 filesystem... > ** Unrecognized filesystem type ** > Wrong Image Format for bootm command > ERROR: can't get kernel image > > On Aug 14, 2017 5:41 PM, "Andrii Anisov" wrote: > Hello Julien, > > > On 14.08.17 14:50, Julien Grall wrote: > The kernel should really be able to deal with memory below and > above 4GB. > > Yes, it should. I suppose a bug somewhere in Renesas eth driver. > Meanwhile George John could make some investigations. > > Otherwise the problem would be exactly the same on baremetal as > the board support seems to have bank above 4GB... > > The first step here is to check that NFS is working on baremetal. > I don't remember if this has been yet done. > > NFS does work baremetal. It is the default BSP configuration. > NFS works when Dom0 has 752 MB ram under 4GB. > > -- > > *Andrii Anisov* > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/2] paravirt, xen: correct xen_nopvspin case
With the boot parameter "xen_nopvspin" specified a Xen guest should not
make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this disable the virt_spin_lock_key.
Signed-off-by: Juergen Gross
---
arch/x86/xen/spinlock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 25a7c4302ce7..e8ab80ad7a6f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -129,6 +130,7 @@ void __init xen_init_spinlocks(void)
if (!xen_pvspin) {
printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+ static_branch_disable(&virt_spin_lock_key);
return;
}
printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/2] guard virt_spin_lock() with a static key
With virt_spin_lock() being guarded by a static key the bare metal case can be optimized by patching the call away completely. In case a kernel running as a guest it can decide whether to use paravitualized spinlocks, the current fallback to the unfair test-and-set scheme, or to mimic the bare metal behavior. V3: - remove test for hypervisor environment from virt_spin_lock(9 as suggested by Waiman Long V2: - use static key instead of making virt_spin_lock() a pvops function Juergen Gross (2): paravirt/locks: use new static key for controlling call of virt_spin_lock() paravirt,xen: correct xen_nopvspin case arch/x86/include/asm/qspinlock.h | 11 ++- arch/x86/kernel/paravirt-spinlocks.c | 6 ++ arch/x86/kernel/smpboot.c| 2 ++ arch/x86/xen/spinlock.c | 2 ++ kernel/locking/qspinlock.c | 4 5 files changed, 24 insertions(+), 1 deletion(-) -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
has the downside of falling back to unfair test and set scheme for
qspinlocks due to virt_spin_lock() detecting the virtualized
environment.
Add a static key controlling whether virt_spin_lock() should be
called or not. When running on bare metal set the new key to false.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/qspinlock.h | 11 ++-
arch/x86/kernel/paravirt-spinlocks.c | 6 ++
arch/x86/kernel/smpboot.c| 2 ++
kernel/locking/qspinlock.c | 4
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index 48a706f641f2..308dfd0714c7 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -1,6 +1,7 @@
#ifndef _ASM_X86_QSPINLOCK_H
#define _ASM_X86_QSPINLOCK_H
+#include
#include
#include
#include
@@ -46,10 +47,14 @@ static inline void queued_spin_unlock(struct qspinlock
*lock)
#endif
#ifdef CONFIG_PARAVIRT
+DECLARE_STATIC_KEY_TRUE(virt_spin_lock_key);
+
+void native_pv_lock_init(void) __init;
+
#define virt_spin_lock virt_spin_lock
static inline bool virt_spin_lock(struct qspinlock *lock)
{
- if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
+ if (!static_branch_likely(&virt_spin_lock_key))
return false;
/*
@@ -65,6 +70,10 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
return true;
}
+#else
+static inline void native_pv_lock_init(void)
+{
+}
#endif /* CONFIG_PARAVIRT */
#include
diff --git a/arch/x86/kernel/paravirt-spinlocks.c
b/arch/x86/kernel/paravirt-spinlocks.c
index 8f2d1c9d43a8..2fc65ddea40d 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -42,3 +42,9 @@ struct pv_lock_ops pv_lock_ops = {
#endif /* SMP */
};
EXPORT_SYMBOL(pv_lock_ops);
+
+void __init native_pv_lock_init(void)
+{
+ if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
+ static_branch_disable(&virt_spin_lock_key);
+}
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 54b9e89d4d6b..21500d3ba359 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -77,6 +77,7 @@
#include
#include
#include
+#include
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
@@ -1381,6 +1382,7 @@ void __init native_smp_prepare_boot_cpu(void)
/* already set me in cpu_online_mask in boot_cpu_init() */
cpumask_set_cpu(me, cpu_callout_mask);
cpu_set_state_online(me);
+ native_pv_lock_init();
}
void __init native_smp_cpus_done(unsigned int max_cpus)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 294294c71ba4..838d235b87ef 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -76,6 +76,10 @@
#define MAX_NODES 4
#endif
+#ifdef CONFIG_PARAVIRT
+DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
+#endif
+
/*
* Per-CPU queue node structures; we can never have more than 4 nested
* contexts: task, softirq, hardirq, nmi.
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
On 06/09/17 18:13, Waiman Long wrote:
> On 09/06/2017 12:04 PM, Peter Zijlstra wrote:
>> On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
#define virt_spin_lock virt_spin_lock
static inline bool virt_spin_lock(struct qspinlock *lock)
{
+ if (!static_branch_likely(&virt_spin_lock_key))
+ return false;
if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
return false;
>> Now native has two NOPs instead of one. Can't we merge these two static
>> branches?
>
>
> I guess we can remove the static_cpu_has() call. Just that any spin_lock
> calls before native_pv_lock_init() will use the virt_spin_lock(). That
> is still OK as the init call is done before SMP starts.
Hmm, right. I'll send V3 in some minutes.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 22/27 v8] xen/arm: vpl011: Add support for vuart console in xenconsole
On 5 September 2017 at 15:01, Wei Liu wrote: > On Mon, Sep 04, 2017 at 09:58:07PM +0530, Bhupinder Thakur wrote: >> Hi Jan, >> >> >> On 28 August 2017 at 14:41, Jan Beulich wrote: >> On 28.08.17 at 10:56, wrote: >> >> --- a/config/arm32.mk >> >> +++ b/config/arm32.mk >> >> @@ -1,5 +1,6 @@ >> >> CONFIG_ARM := y >> >> CONFIG_ARM_32 := y >> >> +CONFIG_VUART_CONSOLE := y >> >> CONFIG_ARM_$(XEN_OS) := y >> >> >> >> CONFIG_XEN_INSTALL_SUFFIX := >> >> diff --git a/config/arm64.mk b/config/arm64.mk >> >> index aa45772..861d0a4 100644 >> >> --- a/config/arm64.mk >> >> +++ b/config/arm64.mk >> >> @@ -1,5 +1,6 @@ >> >> CONFIG_ARM := y >> >> CONFIG_ARM_64 := y >> >> +CONFIG_VUART_CONSOLE := y >> >> CONFIG_ARM_$(XEN_OS) := y >> > >> > I think this wants to be solved better than by starting to again >> > introduce CONFIG_* values here. >> >> I think I can remove this flag from here since it is used currently >> for xenconsole only to enable VUART console support for ARM. I can >> directly define the flag in the tools/console Makefile based on >> CONFIG_ARM option. > > Just use CONFIG_ARM directly? I believe I cannot use CONFIG_ARM directly in tools/console/daemon/io.c as it is a makefile variable. Currently, in tools/console/Makefile the VUART specifc flag is included like this: CFLAGS_vuart-$(CONFIG_VUART_CONSOLE) = -DCONFIG_VUART_CONSOLE I will change it to: CFLAGS_vuart-$(CONFIG_ARM) = -DCONFIG_VUART_CONSOLE and remove CONFIG_VUART_CONSOLE variable from arm32.mk and arm64.mk. Regards, Bhupinder ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/6] xen: try to prevent idle timer from firing too often.
On Tue, 2017-08-29 at 17:30 +0100, George Dunlap wrote:
> On 08/18/2017 07:04 PM, Dario Faggioli wrote:
> >
> > What we're trying to avoid is one of those idle CPUs to
> > wake up, only to discover that the grace period is still
> > running, and that it hence could have be slept longer
> > (saving more power).
>
> So I think we're only taking about one or two extra wakeups per cpu
> maximum -- if this even happens at all.
>
Yep, indeed.
> Wouldn't it be better to first add a performance counter, and check
> to
> see if and how often this situation happens?
>
The counter is there already. It's rcu_idle_timer ("RCU: idle_timer").
> > This patch implements an heuristic aimed at achieving
> > that, at the price of having to call cpumask_weight() on
> > the 'entering idle' path, on CPUs with queued callbacks.
>
> The heuristic seems a bit strange to me too: why would each cpu
> increase
> the grace period in a linear fashion? I haven't looked at the grace
> period code, but I would have expected each one to be independent;
> and
> so there'd be a "diminishing returns" effect when adding more cpus.
>
I like the idea, in general. Let me just double check whether I'm
understanding what you're suggesting properly.
First of all, what do you mean with "adding more cpus"? Adding to what?
The timer is useful when a CPU, which is participating in the grace
period, goes idle, while the grace period is not finished. From that
point on, the number of CPUs participating to _that_ grace period will
monotonically decrease, until it reaches zero. So what does 'adding'
means in this context?
> If we have to have something like this (which I'm not at all
> convinced
> we do), I would think having a single number which self-adjusted so
> that
> the number of 'misses' was around 1% would be a good balance. What
> about a heuristic like this:
>
> 1. If the timer goes off and the grace period isn't over, add 10ms to
> the timer period
> 2. If the timer goes off and the grace period *is* over, subtract
> 100us
> from the timer period
>
So, let's say we start with a period of 1ms. First time RCU is used,
the timer fires twice: the first time it finds the grace period is
still ongoning --and hence the period becomes 11ms-- while the seconds
finds it over --so the period is now 10.9ms.
Next time RCU is used, if the timer is necessary, we use 10.9ms.
Am I getting your proposal right?
If yes, do we allow the period to become smaller than the initial value
(1ms, in the example above). I'd say we better not (or that we at least
set a lower bound), or, given enough occurrences of cases when the
timer fires and finds the grace period to be over in a row, the period
can become 0!
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113092: trouble: broken/fail/pass
flight 113092 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/113092/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken test-arm64-arm64-xl-xsm broken build-arm64-pvopsbroken Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 16 guest-start/debian.repeat fail pass in 113084 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113039 build-arm64-pvops 3 capture-logsbroken like 113039 build-arm64 2 hosts-allocate broken like 113039 build-arm64 3 capture-logsbroken like 113039 test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen 0829a6bdbdc6b79990bd0668e847275b6a2717e5 baseline version: xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a Last test of basis 113039 2017-09-04 15:02:08 Z2 days Failing since113052 2017-09-05 13:01:29 Z1 days 12 attempts Testing same since 113074 2017-09-06 11:14:03 Z0 days3 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Jan Beulich Olaf Hering Tamas K Lengyel Wei Liu jobs: build-amd64 pass build-arm64 broken build-armhf pass build-amd64-libvirt pass build-arm64-pvopsbroken test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken broken-step build-arm64-pvops hosts-allocate broken-step build-arm64-pvops capture-logs broken-step build-arm64 hosts-allocate broken-step build-arm64 capture-logs broken-job build-arm64 broken broken-job test-arm64-arm64-xl-xsm broken broken-job build-arm64-pvops broken Not pushing. commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5 Author: Jan Beulich Date: Wed Sep 6 12:32:00 2017 +0200 x86: introduce and use setup_force_cpu_cap() For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem specifically for live patching, as a live patch may need alternative instruction patching keyed off of that feature flag. Reported-by: Sarah Newman Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit fd903a35daf3e7e6bfa782b18dfd43746f940bed Author: Andrew Cooper Date: Tue Sep 5 17:54:45 2017 +0100 x86/traps: Fix show_page_walk() to avoid printing trailing whitespace This moves the L2 line to be consistent with the L3 line. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Acked-by: Jan Beulich commit 12257de3cfff9b4ffa0b7379ef82c9ad7c8dbec9 Author: Andrew Cooper Date: Fri Sep 1 17:05:21 2017 + xen: Drop asmlinkage everywhere asmlinkage is defined as nothing on all architectures, and not used consistently anywhere, even in common code. Remove it all. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Reviewed-by: Stefano Stabellini commit 150dd3946c521a9257c4dd97e6190c6b0df680d3 Author: Olaf Hering Dat
Re: [Xen-devel] [PATCH v2 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
On 09/06/2017 12:04 PM, Peter Zijlstra wrote:
> On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
>>> #define virt_spin_lock virt_spin_lock
>>> static inline bool virt_spin_lock(struct qspinlock *lock)
>>> {
>>> + if (!static_branch_likely(&virt_spin_lock_key))
>>> + return false;
>>> if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
>>> return false;
>>>
> Now native has two NOPs instead of one. Can't we merge these two static
> branches?
I guess we can remove the static_cpu_has() call. Just that any spin_lock
calls before native_pv_lock_init() will use the virt_spin_lock(). That
is still OK as the init call is done before SMP starts.
Cheers,
Longman
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
On Wed, Sep 06, 2017 at 11:49:49AM -0400, Waiman Long wrote:
> > #define virt_spin_lock virt_spin_lock
> > static inline bool virt_spin_lock(struct qspinlock *lock)
> > {
> > + if (!static_branch_likely(&virt_spin_lock_key))
> > + return false;
> > if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
> > return false;
> >
Now native has two NOPs instead of one. Can't we merge these two static
branches?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/8] xen: double default grant frame limit for huge hosts
On Wed, Sep 06, 2017 at 02:46:50PM +0200, Juergen Gross wrote: > In case a system has memory above the 16TB boundary double the default > grant frame number limit per domain. This ensures a pv domain can still > establish the same number of grants even if it is required to use > version 2 grants which need twice the space of v1 grants. > > Signed-off-by: Juergen Gross > Reviewed-by: Paul Durrant Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: make grant resource limits per domain
On Wed, Sep 06, 2017 at 02:46:49PM +0200, Juergen Gross wrote: > Instead of using the same global resource limits of grant tables (max. > number of grant frames, max. number of maptrack frames) for all domains > make these limits per domain. This will allow setting individual limits > in the future. For now initialize the per domain limits with the global > values. > > Signed-off-by: Juergen Gross > Reviewed-by: Paul Durrant Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 13/13] libxl: make pci and usb setdefault function generic
On Tue, Sep 5, 2017 at 4:06 PM, Wei Liu wrote: > On Tue, Jul 18, 2017 at 05:25:30PM +0300, Oleksandr Grytsov wrote: >> From: Oleksandr Grytsov >> >> Due to changes in device framework setdefault function >> should have same format. Otherwise calling devicetype >> set_default causes segfault. >> >> Signed-off-by: Oleksandr Grytsov > > Shouldn't this patch be placed before the introduction of the new > framework? Wrong function parameters will cause crash if devtype framework will be used. For example if someone call pci set_default: libxl__nic_devtype.set_default(...) So I guess the right place for these changes will be first patch where changes to devtype are introduced. I will fix setdefault function parameters for all devtypes. Does it sounds good? -- Best Regards, Oleksandr Grytsov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
On 09/06/2017 11:29 AM, Juergen Gross wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
> has the downside of falling back to unfair test and set scheme for
> qspinlocks due to virt_spin_lock() detecting the virtualized
> environment.
>
> Add a static key controlling whether virt_spin_lock() should be
> called or not. When running on bare metal set the new key to false.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/include/asm/qspinlock.h | 11 +++
> arch/x86/kernel/paravirt-spinlocks.c | 6 ++
> arch/x86/kernel/smpboot.c| 2 ++
> kernel/locking/qspinlock.c | 4
> 4 files changed, 23 insertions(+)
>
> diff --git a/arch/x86/include/asm/qspinlock.h
> b/arch/x86/include/asm/qspinlock.h
> index 48a706f641f2..fc39389f196b 100644
> --- a/arch/x86/include/asm/qspinlock.h
> +++ b/arch/x86/include/asm/qspinlock.h
> @@ -1,6 +1,7 @@
> #ifndef _ASM_X86_QSPINLOCK_H
> #define _ASM_X86_QSPINLOCK_H
>
> +#include
> #include
> #include
> #include
> @@ -46,9 +47,15 @@ static inline void queued_spin_unlock(struct qspinlock
> *lock)
> #endif
>
> #ifdef CONFIG_PARAVIRT
> +DECLARE_STATIC_KEY_TRUE(virt_spin_lock_key);
> +
> +void native_pv_lock_init(void) __init;
> +
> #define virt_spin_lock virt_spin_lock
> static inline bool virt_spin_lock(struct qspinlock *lock)
> {
> + if (!static_branch_likely(&virt_spin_lock_key))
> + return false;
> if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
> return false;
>
> @@ -65,6 +72,10 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
>
> return true;
> }
> +#else
> +static inline void native_pv_lock_init(void)
> +{
> +}
> #endif /* CONFIG_PARAVIRT */
>
> #include
> diff --git a/arch/x86/kernel/paravirt-spinlocks.c
> b/arch/x86/kernel/paravirt-spinlocks.c
> index 8f2d1c9d43a8..2fc65ddea40d 100644
> --- a/arch/x86/kernel/paravirt-spinlocks.c
> +++ b/arch/x86/kernel/paravirt-spinlocks.c
> @@ -42,3 +42,9 @@ struct pv_lock_ops pv_lock_ops = {
> #endif /* SMP */
> };
> EXPORT_SYMBOL(pv_lock_ops);
> +
> +void __init native_pv_lock_init(void)
> +{
> + if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
> + static_branch_disable(&virt_spin_lock_key);
> +}
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 54b9e89d4d6b..21500d3ba359 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -77,6 +77,7 @@
> #include
> #include
> #include
> +#include
>
> /* Number of siblings per CPU package */
> int smp_num_siblings = 1;
> @@ -1381,6 +1382,7 @@ void __init native_smp_prepare_boot_cpu(void)
> /* already set me in cpu_online_mask in boot_cpu_init() */
> cpumask_set_cpu(me, cpu_callout_mask);
> cpu_set_state_online(me);
> + native_pv_lock_init();
> }
>
> void __init native_smp_cpus_done(unsigned int max_cpus)
> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> index 294294c71ba4..838d235b87ef 100644
> --- a/kernel/locking/qspinlock.c
> +++ b/kernel/locking/qspinlock.c
> @@ -76,6 +76,10 @@
> #define MAX_NODES4
> #endif
>
> +#ifdef CONFIG_PARAVIRT
> +DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
> +#endif
> +
> /*
> * Per-CPU queue node structures; we can never have more than 4 nested
> * contexts: task, softirq, hardirq, nmi.
Acked-by: Waiman Long
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] paravirt, xen: correct xen_nopvspin case
On 09/06/2017 11:29 AM, Juergen Gross wrote:
> With the boot parameter "xen_nopvspin" specified a Xen guest should not
> make use of paravirt spinlocks, but behave as if running on bare
> metal. This is not true, however, as the qspinlock code will fall back
> to a test-and-set scheme when it is detecting a hypervisor.
>
> In order to avoid this disable the virt_spin_lock_key.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/xen/spinlock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 25a7c4302ce7..e8ab80ad7a6f 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -10,6 +10,7 @@
> #include
>
> #include
> +#include
>
> #include
> #include
> @@ -129,6 +130,7 @@ void __init xen_init_spinlocks(void)
>
> if (!xen_pvspin) {
> printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
> + static_branch_disable(&virt_spin_lock_key);
> return;
> }
> printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
Acked-by: Waiman Long
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 0/3] Notify monitor when emulating an unimplemented instruction
Hi Tamas, There are still some loose ends to tie up, but a soon as I will fix then I will try to upstream my patch. Best regards, Petre On Mi, 2017-09-06 at 09:12 -0600, Tamas K Lengyel wrote: > On Wed, Sep 6, 2017 at 7:48 AM, Petre Pircalabu > wrote: > > > > This patchset implements a mechanism which allows XEN to send first > > an event > > if the emulator encountered an unsupported instruction. > > The monitor application can choose to mitigate the error, for > > example to singlestep > > the instruction using the real processor and then resume execution > > of the normal > > instruction flow. > > > > This feature was tested using a modified version of XTF: > > https://github.com/petrepircalabu/xen-test-framework/tree/emul_unim > > pl > Hi Petre, > thanks for sharing that! Do you have any plans to upstream that to > XTF > so we can have some automated tests for other parts of the monitor > code as well? > > Tamas > > > This email was scanned by Bitdefender ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space
On Mon, Sep 04, 2017 at 09:38:11AM -0600, Jan Beulich wrote: > >>> On 14.08.17 at 16:28, wrote: > > Changes since v4: > >[...] > > * Hypervisor code: > >[...] > > - Constify the data opaque parameter of read handlers. > > Is that a good idea? Such callbacks should generally be allowed to > modify their state even if the operation is just a read - think of a > private lock or statistics/debugging data to be updated. Right now the consistency of the opaque data is kept by the global vpci lock, which I like because it makes the code simpler. If the opaque data is not constified for the read handlers then I would be against using a read/write lock. Statistic/debug data IMHO should be kept in a separate structure with it's own lock, that's referenced by the opaque data. This would allow Xen to not allocate this for non-debug builds, reducing memory footprint and lock contention in production. > > +/* > > + * Merge new data into a partial result. > > + * > > + * Zero the bytes of 'data' from [offset, offset + size), and > > + * merge the value found in 'new' from [0, offset) left shifted > > DYM [0, size) here? Yes, will fix. > I also have to admit that I find it strange that > you talk of zeroing something here - the net effect of the function > is not producing any zeros anywhere afaict. Such a pre-function > comment is normally describing the effect of the function as seen > to the caller rather than its inner workings. OK, would it be better to write it as: /* * Merge new data into a partial result. * * Copy the value found in 'new' from [0, size) left shifted by * 'offset' into 'data'. */ > > + */ > > +typedef uint32_t vpci_read_t(struct pci_dev *pdev, unsigned int reg, > > + const void *data); > > + > > +typedef void vpci_write_t(struct pci_dev *pdev, unsigned int reg, > > + uint32_t val, void *data); > > Do these two really need access to the struct pci_dev, rather than > just struct vpci? And if they do, then are they really permitted to > alter that struct pci_dev? I'm leaning towards pdev because it already contains vpci. AFAICT it should be fine to constify it. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [GIT PULL] xen: fixes and features for 4.14
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.14b-rc1-tag
xen: fixes and features for 4.14
It contains the following commits:
- the new pvcalls backend for routing socket calls from a guest to dom0
- some cleanups of Xen code
- a fix for wrong usage of {get,put}_cpu()
Thanks.
Juergen
arch/x86/include/asm/xen/page.h|5 -
arch/x86/xen/mmu.c |2 +-
arch/x86/xen/mmu_pv.c | 20 -
arch/x86/xen/p2m.c | 25 +-
arch/x86/xen/setup.c |5 +-
drivers/xen/Kconfig| 12 +
drivers/xen/Makefile |1 +
drivers/xen/balloon.c |8 +-
drivers/xen/events/events_fifo.c |7 +-
drivers/xen/platform-pci.c |2 +-
drivers/xen/pvcalls-back.c | 1240
include/trace/events/xen.h | 38 --
include/xen/interface/io/pvcalls.h | 121
include/xen/interface/io/ring.h|2 +
include/xen/xen.h | 20 +-
15 files changed, 1397 insertions(+), 111 deletions(-)
Arnd Bergmann (1):
xen/pvcalls: use WARN_ON(1) instead of __WARN()
Arvind Yadav (1):
xen-platform: constify pci_device_id.
Boris Ostrovsky (1):
xen: Don't try to call xen_alloc_p2m_entry() on autotranslating guests
Juergen Gross (4):
xen: cleanup xen.h
xen: remove tests for pvh mode in pure pv paths
xen: remove unused function xen_set_domain_pte()
xen: remove not used trace functions
Julien Grall (1):
xen/events: events_fifo: Don't use {get,put}_cpu() in
xen_evtchn_fifo_init()
Stefano Stabellini (18):
xen: introduce the pvcalls interface header
xen/pvcalls: introduce the pvcalls xenbus backend
xen/pvcalls: initialize the module and register the xenbus backend
xen/pvcalls: xenbus state handling
xen/pvcalls: connect to a frontend
xen/pvcalls: handle commands from the frontend
xen/pvcalls: implement socket command
xen/pvcalls: implement connect command
xen/pvcalls: implement bind command
xen/pvcalls: implement listen command
xen/pvcalls: implement accept command
xen/pvcalls: implement poll command
xen/pvcalls: implement release command
xen/pvcalls: disconnect and module_exit
xen/pvcalls: implement the ioworker functions
xen/pvcalls: implement read
xen/pvcalls: implement write
xen: introduce a Kconfig option to enable the pvcalls backend
Wei Liu (1):
xen/mmu: set MMU_NORMAL_PT_UPDATE in remap_area_mfn_pte_fn
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
On Wed, Sep 06, 2017 at 05:36:54PM +0200, Juergen Gross wrote:
> On 06/09/17 17:32, Wei Liu wrote:
> > On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
> +grant_table_init(struct domain *d)
> +{
> +struct grant_table *gt = d->grant_table;
> +unsigned int i, j;
> +
> +if ( gt->nr_grant_frames )
> +return 0;
> +
> >>>
> >>> EBUSY here? I think we should catch the cases when this is called
> >>> multiple times.
> >>
> >> No. The call of grant_table_init() from
> >> domain_unpause_by_systemcontroller() can't be masked, otherwise I
> >> would have to make struct grant_table public again. Multiple calls
> >> are okay.
> >
> > For domain_unpause_by_systemcontroller, isn't it already guarded by
> > d->creation_finished to ensure there is only one call to
> > grant_table_init?
> >
> > Or do you mean if gnttab_table_init fails the system administrator will
> > somehow tries to unpause the domain again hence calling grant_table_init
> > again?
> >
>
> No. It might have been called already due to e.g. gnttab_setup_table()
> being called as a result of xc_dom_gnttab_seed() during creation of the
> domU. The call from domain_unpause_by_systemcontroller() is just a
> safety net for cases where gnttab_setup_table() wasn't used (e.g. in
> case of a xenstore stubdom).
>
Hmm... OK. In that case I think the multiple call paths is justified.
You can have my Rb on this patch.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/13] libxl: change nic to use generec add function
On Tue, Sep 5, 2017 at 4:03 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:27PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Signed-off-by: Oleksandr Grytsov
>> diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
>> index dd07a6c..16a6c8c 100644
>> --- a/tools/libxl/libxl_nic.c
>> +++ b/tools/libxl/libxl_nic.c
>> @@ -20,15 +20,18 @@
>> int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
>> const char *mac, libxl_device_nic *nic)
>> {
>> +GC_INIT(ctx);
>> libxl_device_nic *nics;
>> int nb, rc, i;
>> libxl_mac mac_n;
>>
>> +libxl_device_nic_init(nic);
>> +
>
> Why is this change introduced?
>
> This is changing the behaviour of the API.
>
> To be clear I don't think its original behaviour is desirable. But if
> you are to change it, please make a separate patch.
Yes, the behavior is changed. I will revert these changes.
>> rc = libxl__parse_mac(mac, mac_n);
>> if (rc)
>> return rc;
>>
>> -nics = libxl_device_nic_list(ctx, domid, &nb);
>> +nics = libxl__device_list(gc, &libxl__nic_devtype, domid, "vif", &nb);
>> if (!nics)
>> return ERROR_FAIL;
>>
--
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
On 06/09/17 17:32, Wei Liu wrote:
> On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
+grant_table_init(struct domain *d)
+{
+struct grant_table *gt = d->grant_table;
+unsigned int i, j;
+
+if ( gt->nr_grant_frames )
+return 0;
+
>>>
>>> EBUSY here? I think we should catch the cases when this is called
>>> multiple times.
>>
>> No. The call of grant_table_init() from
>> domain_unpause_by_systemcontroller() can't be masked, otherwise I
>> would have to make struct grant_table public again. Multiple calls
>> are okay.
>
> For domain_unpause_by_systemcontroller, isn't it already guarded by
> d->creation_finished to ensure there is only one call to
> grant_table_init?
>
> Or do you mean if gnttab_table_init fails the system administrator will
> somehow tries to unpause the domain again hence calling grant_table_init
> again?
>
No. It might have been called already due to e.g. gnttab_setup_table()
being called as a result of xc_dom_gnttab_seed() during creation of the
domU. The call from domain_unpause_by_systemcontroller() is just a
safety net for cases where gnttab_setup_table() wasn't used (e.g. in
case of a xenstore stubdom).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
On Wed, Sep 06, 2017 at 05:15:46PM +0200, Juergen Gross wrote:
> >> +grant_table_init(struct domain *d)
> >> +{
> >> +struct grant_table *gt = d->grant_table;
> >> +unsigned int i, j;
> >> +
> >> +if ( gt->nr_grant_frames )
> >> +return 0;
> >> +
> >
> > EBUSY here? I think we should catch the cases when this is called
> > multiple times.
>
> No. The call of grant_table_init() from
> domain_unpause_by_systemcontroller() can't be masked, otherwise I
> would have to make struct grant_table public again. Multiple calls
> are okay.
For domain_unpause_by_systemcontroller, isn't it already guarded by
d->creation_finished to ensure there is only one call to
grant_table_init?
Or do you mean if gnttab_table_init fails the system administrator will
somehow tries to unpause the domain again hence calling grant_table_init
again?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()
Instead, preserve PGC_need_scrub bit when setting PGC_state_inuse
state while still under the lock and clear those pages later.
Note that we still need to grub the lock when clearing PGC_need_scrub
bit since count_info might be updated during MCE handling in
mark_page_offline().
Signed-off-by: Boris Ostrovsky
---
v3:
* Call check_one_page() only if _PGC_need_scrub is not set.
* After more thinking I decided to keep scub_debug check: the false
positive issue that I was concerned about is bogus: we are checking
whether an unscrubbed page is accidentally given out so the only
potential problem here would be us missing the case where a guest
filled a page with clean pattern *and* we for some reason didn't
scrub it. So the test is not perfect in that respect, but that's it.
xen/common/page_alloc.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index dbad1e1..b5243fc 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -860,6 +860,7 @@ static struct page_info *alloc_heap_pages(
struct page_info *pg;
bool need_tlbflush = false;
uint32_t tlbflush_timestamp = 0;
+unsigned int dirty_cnt = 0;
/* Make sure there are enough bits in memflags for nodeID. */
BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
@@ -953,14 +954,11 @@ static struct page_info *alloc_heap_pages(
/* Reference count must continuously be zero for free pages. */
BUG_ON((pg[i].count_info & ~PGC_need_scrub) != PGC_state_free);
-if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
-{
-if ( !(memflags & MEMF_no_scrub) )
-scrub_one_page(&pg[i]);
-node_need_scrub[node]--;
-}
+/* PGC_need_scrub can only be set if first_dirty is valid */
+ASSERT(first_dirty != INVALID_DIRTY_IDX || !(pg[i].count_info &
PGC_need_scrub));
-pg[i].count_info = PGC_state_inuse;
+/* Preserve PGC_need_scrub so we can check it after lock is dropped. */
+pg[i].count_info = PGC_state_inuse | (pg[i].count_info &
PGC_need_scrub);
if ( !(memflags & MEMF_no_tlbflush) )
accumulate_tlbflush(&need_tlbflush, &pg[i],
@@ -974,13 +972,38 @@ static struct page_info *alloc_heap_pages(
* guest can control its own visibility of/through the cache.
*/
flush_page_to_ram(page_to_mfn(&pg[i]), !(memflags &
MEMF_no_icache_flush));
-
-if ( !(memflags & MEMF_no_scrub) )
-check_one_page(&pg[i]);
}
spin_unlock(&heap_lock);
+if ( first_dirty != INVALID_DIRTY_IDX ||
+ (scrub_debug && !(memflags & MEMF_no_scrub)) )
+{
+for ( i = 0; i < (1U << order); i++ )
+{
+if ( test_bit(_PGC_need_scrub, &pg[i].count_info) )
+{
+if ( !(memflags & MEMF_no_scrub) )
+scrub_one_page(&pg[i]);
+
+dirty_cnt++;
+
+spin_lock(&heap_lock);
+pg[i].count_info &= ~PGC_need_scrub;
+spin_unlock(&heap_lock);
+}
+else if ( !(memflags & MEMF_no_scrub) )
+check_one_page(&pg[i]);
+}
+
+if ( dirty_cnt )
+{
+spin_lock(&heap_lock);
+node_need_scrub[node] -= dirty_cnt;
+spin_unlock(&heap_lock);
+}
+}
+
if ( need_tlbflush )
filtered_flush_tlb_mask(tlbflush_timestamp);
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] guard virt_spin_lock() with a static key
With virt_spin_lock() being guarded by a static key the bare metal case can be optimized by patching the call away completely. In case a kernel running as a guest it can decide whether to use paravitualized spinlocks, the current fallback to the unfair test-and-set scheme, or to mimic the bare metal behavior. V2: - use static key instead of making virt_spin_lock() a pvops function Juergen Gross (2): paravirt/locks: use new static key for controlling call of virt_spin_lock() paravirt,xen: correct xen_nopvspin case arch/x86/include/asm/qspinlock.h | 11 +++ arch/x86/kernel/paravirt-spinlocks.c | 6 ++ arch/x86/kernel/smpboot.c| 2 ++ arch/x86/xen/spinlock.c | 2 ++ kernel/locking/qspinlock.c | 4 5 files changed, 25 insertions(+) -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] paravirt/locks: use new static key for controlling call of virt_spin_lock()
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this
has the downside of falling back to unfair test and set scheme for
qspinlocks due to virt_spin_lock() detecting the virtualized
environment.
Add a static key controlling whether virt_spin_lock() should be
called or not. When running on bare metal set the new key to false.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/qspinlock.h | 11 +++
arch/x86/kernel/paravirt-spinlocks.c | 6 ++
arch/x86/kernel/smpboot.c| 2 ++
kernel/locking/qspinlock.c | 4
4 files changed, 23 insertions(+)
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index 48a706f641f2..fc39389f196b 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -1,6 +1,7 @@
#ifndef _ASM_X86_QSPINLOCK_H
#define _ASM_X86_QSPINLOCK_H
+#include
#include
#include
#include
@@ -46,9 +47,15 @@ static inline void queued_spin_unlock(struct qspinlock *lock)
#endif
#ifdef CONFIG_PARAVIRT
+DECLARE_STATIC_KEY_TRUE(virt_spin_lock_key);
+
+void native_pv_lock_init(void) __init;
+
#define virt_spin_lock virt_spin_lock
static inline bool virt_spin_lock(struct qspinlock *lock)
{
+ if (!static_branch_likely(&virt_spin_lock_key))
+ return false;
if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
return false;
@@ -65,6 +72,10 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
return true;
}
+#else
+static inline void native_pv_lock_init(void)
+{
+}
#endif /* CONFIG_PARAVIRT */
#include
diff --git a/arch/x86/kernel/paravirt-spinlocks.c
b/arch/x86/kernel/paravirt-spinlocks.c
index 8f2d1c9d43a8..2fc65ddea40d 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -42,3 +42,9 @@ struct pv_lock_ops pv_lock_ops = {
#endif /* SMP */
};
EXPORT_SYMBOL(pv_lock_ops);
+
+void __init native_pv_lock_init(void)
+{
+ if (!static_cpu_has(X86_FEATURE_HYPERVISOR))
+ static_branch_disable(&virt_spin_lock_key);
+}
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 54b9e89d4d6b..21500d3ba359 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -77,6 +77,7 @@
#include
#include
#include
+#include
/* Number of siblings per CPU package */
int smp_num_siblings = 1;
@@ -1381,6 +1382,7 @@ void __init native_smp_prepare_boot_cpu(void)
/* already set me in cpu_online_mask in boot_cpu_init() */
cpumask_set_cpu(me, cpu_callout_mask);
cpu_set_state_online(me);
+ native_pv_lock_init();
}
void __init native_smp_cpus_done(unsigned int max_cpus)
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 294294c71ba4..838d235b87ef 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -76,6 +76,10 @@
#define MAX_NODES 4
#endif
+#ifdef CONFIG_PARAVIRT
+DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
+#endif
+
/*
* Per-CPU queue node structures; we can never have more than 4 nested
* contexts: task, softirq, hardirq, nmi.
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] paravirt, xen: correct xen_nopvspin case
With the boot parameter "xen_nopvspin" specified a Xen guest should not
make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this disable the virt_spin_lock_key.
Signed-off-by: Juergen Gross
---
arch/x86/xen/spinlock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 25a7c4302ce7..e8ab80ad7a6f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -129,6 +130,7 @@ void __init xen_init_spinlocks(void)
if (!xen_pvspin) {
printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
+ static_branch_disable(&virt_spin_lock_key);
return;
}
printk(KERN_DEBUG "xen: PV spinlocks enabled\n");
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
On 06/09/17 17:11, Wei Liu wrote:
> On Wed, Sep 06, 2017 at 02:46:48PM +0200, Juergen Gross wrote:
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 5aebcf265f..11eb1778a3 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid, unsigned int
>> domcr_flags,
>> goto fail;
>> init_status |= INIT_gnttab;
>>
>> +if ( domid == 0 && grant_table_init(d) )
>> +goto fail;
>> +
>> poolid = 0;
>>
>> err = -ENOMEM;
>> @@ -998,7 +1001,8 @@ int __domain_pause_by_systemcontroller(struct domain *d,
>> prev = cmpxchg(&d->controller_pause_count, old, new);
>> } while ( prev != old );
>>
>> -pause_fn(d);
>> +if ( pause_fn )
>> +pause_fn(d);
>>
>> return 0;
>> }
>> @@ -1006,6 +1010,7 @@ int __domain_pause_by_systemcontroller(struct domain
>> *d,
>> int domain_unpause_by_systemcontroller(struct domain *d)
>> {
>> int old, new, prev = d->controller_pause_count;
>> +int ret;
>>
>> do
>> {
>> @@ -1029,8 +1034,16 @@ int domain_unpause_by_systemcontroller(struct domain
>> *d)
>> * Creation is considered finished when the controller reference count
>> * first drops to 0.
>> */
>> -if ( new == 0 )
>> +if ( new == 0 && !d->creation_finished )
>> +{
>
> ret can be defined locally here.
Hmm, yes.
>
>> +ret = grant_table_init(d);
>> +if ( ret )
>> +{
>> +__domain_pause_by_systemcontroller(d, NULL);
>> +return ret;
>> +}
>> d->creation_finished = true;
>> +}
>>
>> domain_unpause(d);
>>
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 4520e36d90..29e7fa539b 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -1655,6 +1655,78 @@ gnttab_unpopulate_status_frames(struct domain *d,
>> struct grant_table *gt)
>> gt->nr_status_frames = 0;
>> }
>>
>> +int
>> +grant_table_init(struct domain *d)
>> +{
>> +struct grant_table *gt = d->grant_table;
>> +unsigned int i, j;
>> +
>> +if ( gt->nr_grant_frames )
>> +return 0;
>> +
>
> EBUSY here? I think we should catch the cases when this is called
> multiple times.
No. The call of grant_table_init() from
domain_unpause_by_systemcontroller() can't be masked, otherwise I
would have to make struct grant_table public again. Multiple calls
are okay.
>
> With those changed:
>
> Reviewed-by: Wei Liu
>
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 0/3] Notify monitor when emulating an unimplemented instruction
On Wed, Sep 6, 2017 at 7:48 AM, Petre Pircalabu wrote: > This patchset implements a mechanism which allows XEN to send first an event > if the emulator encountered an unsupported instruction. > The monitor application can choose to mitigate the error, for example to > singlestep > the instruction using the real processor and then resume execution of the > normal > instruction flow. > > This feature was tested using a modified version of XTF: > https://github.com/petrepircalabu/xen-test-framework/tree/emul_unimpl Hi Petre, thanks for sharing that! Do you have any plans to upstream that to XTF so we can have some automated tests for other parts of the monitor code as well? Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
On Wed, Sep 06, 2017 at 02:46:48PM +0200, Juergen Gross wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 5aebcf265f..11eb1778a3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid, unsigned int
> domcr_flags,
> goto fail;
> init_status |= INIT_gnttab;
>
> +if ( domid == 0 && grant_table_init(d) )
> +goto fail;
> +
> poolid = 0;
>
> err = -ENOMEM;
> @@ -998,7 +1001,8 @@ int __domain_pause_by_systemcontroller(struct domain *d,
> prev = cmpxchg(&d->controller_pause_count, old, new);
> } while ( prev != old );
>
> -pause_fn(d);
> +if ( pause_fn )
> +pause_fn(d);
>
> return 0;
> }
> @@ -1006,6 +1010,7 @@ int __domain_pause_by_systemcontroller(struct domain *d,
> int domain_unpause_by_systemcontroller(struct domain *d)
> {
> int old, new, prev = d->controller_pause_count;
> +int ret;
>
> do
> {
> @@ -1029,8 +1034,16 @@ int domain_unpause_by_systemcontroller(struct domain
> *d)
> * Creation is considered finished when the controller reference count
> * first drops to 0.
> */
> -if ( new == 0 )
> +if ( new == 0 && !d->creation_finished )
> +{
ret can be defined locally here.
> +ret = grant_table_init(d);
> +if ( ret )
> +{
> +__domain_pause_by_systemcontroller(d, NULL);
> +return ret;
> +}
> d->creation_finished = true;
> +}
>
> domain_unpause(d);
>
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 4520e36d90..29e7fa539b 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1655,6 +1655,78 @@ gnttab_unpopulate_status_frames(struct domain *d,
> struct grant_table *gt)
> gt->nr_status_frames = 0;
> }
>
> +int
> +grant_table_init(struct domain *d)
> +{
> +struct grant_table *gt = d->grant_table;
> +unsigned int i, j;
> +
> +if ( gt->nr_grant_frames )
> +return 0;
> +
EBUSY here? I think we should catch the cases when this is called
multiple times.
With those changed:
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device
On Wed, Sep 06, 2017 at 12:18:03PM +0200, Juergen Gross wrote: > On 05/09/17 09:28, Vincent Legout wrote: > > Hello, > > > > Sorry for such a long delay. I'm still interested in having this patch > > merged. > > > > I've tried to make the patch more generic and move it to xenbus as > > discussed during the Xen summit, but I'm not sure how or if it's > > possible. Would doing something in xenbus_otherend_changed() make sense? > > But do we have enough information there? I'd be happy to get any advice, > > I've re-attached the original patch. > > Maybe you could add a callback to struct xenbus_driver which is called > by xenbus_otherend_changed() if available and which will return the > missing information (e.g. the kobj). Hello, I'm still unsure we should call KOBJ_OFFLINE, mostly because I don't see any other block devices doing so. AFAICT it seems to be used only by cpu and memory hotplug. Maybe xenbus should use the device_offline function instead on each device it wants to remove? From my limited Linux bus handling understanding, this seems to be more in line with what ACPI does for example. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113084: trouble: broken/pass
flight 113084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113084/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm64-xl-xsm broken
build-arm64-pvopsbroken
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hosts-allocate broken like 113039
build-arm64-pvops 3 capture-logsbroken like 113039
build-arm64 2 hosts-allocate broken like 113039
build-arm64 3 capture-logsbroken like 113039
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
version targeted for testing:
xen 0829a6bdbdc6b79990bd0668e847275b6a2717e5
baseline version:
xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
Last test of basis 113039 2017-09-04 15:02:08 Z1 days
Failing since113052 2017-09-05 13:01:29 Z1 days 11 attempts
Testing same since 113074 2017-09-06 11:14:03 Z0 days2 attempts
People who touched revisions under test:
Alexandru Isaila
Andrew Cooper
Jan Beulich
Olaf Hering
Tamas K Lengyel
Wei Liu
jobs:
build-amd64 pass
build-arm64 broken
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsbroken
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs
Not pushing.
commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5
Author: Jan Beulich
Date: Wed Sep 6 12:32:00 2017 +0200
x86: introduce and use setup_force_cpu_cap()
For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse of setup_clear_cpu_cap() instead, but let clearing of features
overrule forced setting of them.
XEN_SMAP being wrong post-boot is a problem specifically for live
patching, as a live patch may need alternative instruction patching
keyed off of that feature flag.
Reported-by: Sarah Newman
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit fd903a35daf3e7e6bfa782b18dfd43746f940bed
Author: Andrew Cooper
Date: Tue Sep 5 17:54:45 2017 +0100
x86/traps: Fix show_page_walk() to avoid printing trailing whitespace
This moves the L2 line to be consistent with the L3 line.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 12257de3cfff9b4ffa0b7379ef82c9ad7c8dbec9
Author: Andrew Cooper
Date: Fri Sep 1 17:05:21 2017 +
xen: Drop asmlinkage everywhere
asmlinkage is defined as nothing on all architectures, and not used
consistently anywhere, even in common code. Remove it all.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Stefano Stabellini
commit 150dd3946c521a9257c4dd97e6190c6b0df680d3
Author: Olaf Hering
Date: Tue Sep 5 11:03:38 2017 +0200
libxc/bitops: correct comment for bitmap_size
The returned value represents now units of bytes instead of longs.
Fixes commit 11d0044a16 ("tools/libxc: Modify bitmap operations to
ta
Re: [Xen-devel] [PATCH v2] xen: Emit RTC_CHANGE upon TIMEOFFSET ioreq
On Wed, Aug 23, 2017 at 02:25:05PM +0100, Ross Lagerwall wrote: > When the guest writes to the RTC, Xen emulates it and broadcasts a > TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP event to all QMP monitors when > this happens rather than ignoring it so that something useful can be > done with the information. This is the same event that QEMU generates > when it emulates the RTC. > > This patch by itself doesn't affect any of the toolstacks that I > checked; the libxl toolstack doesn't currently handle this event nor > does the XAPI toolstack. If nothing handles the event, it is simply > ignored. We plan on modifying XAPI to handle it. > > Signed-off-by: Ross Lagerwall > --- > > Changed in v2: > * Expanded commit message. > > hw/i386/xen/xen-hvm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index d9ccd5d..ffd20dc 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -16,6 +16,7 @@ > #include "hw/i386/apic-msidef.h" > #include "hw/xen/xen_common.h" > #include "hw/xen/xen_backend.h" > +#include "qapi-event.h" > #include "qmp-commands.h" > > #include "qemu/error-report.h" > @@ -967,6 +968,7 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req) > handle_vmport_ioreq(state, req); > break; > case IOREQ_TYPE_TIMEOFFSET: > +qapi_event_send_rtc_change((int64_t)req->data, &error_abort); Is this the right value? From qapi-schema.json: "offset between base RTC clock (as specified by -rtc base), and new RTC clock value". But with this patch, the offset sent via QMP seems to be between the previous value of the guest rtc and the new one. Other calls to qapi_event_send_rtc_change send the offset between the new guest RTC and qemu_time(). -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.8.2 released
All, I am pleased to announce the release of Xen 4.8.2. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 (tag RELEASE-4.8.2) or from the XenProject download page http://www.xenproject.org/downloads/xen-archives/xen-project-48-series/xen-482.html (where a list of changes can also be found). We recommend all users of the 4.8 stable series to update to this latest point release. Regards, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf bisection] complete build-amd64
branch xen-unstable xenbranch xen-unstable job build-amd64 testid xen-build Tree: ovmf https://github.com/tianocore/edk2.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: ovmf https://github.com/tianocore/edk2.git Bug introduced: 5aae2d35de031a38e7812c615ff6bce36b31466a Bug not present: 12cfc9009e7cf1a69ca675110c2cf6e21b152992 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113089/ commit 5aae2d35de031a38e7812c615ff6bce36b31466a Author: Fu Siyuan Date: Mon Sep 4 16:04:13 2017 +0800 MdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify. The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip4IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan Reviewed-by: Ye Ting For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-amd64.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/ovmf/build-amd64.xen-build --summary-out=tmp/113089.bisection-summary --basis-template=113061 --blessings=real,real-bisect ovmf build-amd64 xen-build Searching for failure / basis pass: 113069 fail [host=godello1] / 113061 [host=godello0] 113050 ok. Failure / basis pass flights: 113069 / 113050 (tree with no url: minios) (tree with no url: seabios) Tree: ovmf https://github.com/tianocore/edk2.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 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Basis pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#56e88e9e5f980e30f28d907e0ff442e4dc8dc5de-9a04dcffbb1e59333e500a8ce66e01a562be8b4f git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#c7c6232bd304568d4da4bef521603aae0035e172-c7c6232bd304568d4da4bef521603aae0035e172 git://xenbits.xen.org/xen.git#ee2c1fc48ac14a4c8b9eb9224753591fa5e7-ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Loaded 1001 nodes in revision graph Searching for test results: 113050 pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113086 fail 5aae2d35de031a38e7812c615ff6bce36b31466a 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113088 pass 12cfc9009e7cf1a69ca675110c2cf6e21b152992 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113089 fail 5aae2d35de031a38e7812c615ff6bce36b31466a 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113061 [host=godello0] 113069 fail 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113076 pass 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113079 fail 9a04dcffbb1e59333e500a8ce66e01a562be8b4f 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113080 pass 60794ee6b0c86c103ab227b0d9c2968c9c74810e 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113081 pass d51b0122bf9bd1df831c77b5669bfbb66aaa4874 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113082 pass 12cfc9009e7cf1a69ca675110c2cf6e21b152992 8051789e982499050680a26febeada7467e18a8d c7c6232bd304568d4da4bef521603aae0035e172 ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113083 fail
Re: [Xen-devel] [PATCH v2 1/1] public/io/netif.h: add gref mapping control messages
On 09/06/2017 02:49 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 01 September 2017 15:51
>> To: Xen-devel
>> Cc: Wei Liu ; Paul Durrant ;
>> Konrad Rzeszutek Wilk ; Joao Martins
>>
>> Subject: [PATCH v2 1/1] public/io/netif.h: add gref mapping control messages
>>
>> Adds 3 messages to allow guest to let backend keep grants mapped,
>> such that 1) guests allowing fast recycling of pages can avoid doing
>> grant ops for those cases, or otherwise 2) preferring copies over
>> grants and 3) always using a fixed set of pages for network I/O.
>>
>> The three control ring messages added are:
>> - Add grefs to be mapped by backend
>> - Remove grefs mappings (If they are not in use)
>> - Get maximum amount of grefs kept mapped.
>>
>> Signed-off-by: Joao Martins
>> ---
>> xen/include/public/io/netif.h | 114
>> ++
>> 1 file changed, 114 insertions(+)
>>
>> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
>> index ca0061410d..264c317471 100644
>> --- a/xen/include/public/io/netif.h
>> +++ b/xen/include/public/io/netif.h
>> @@ -353,6 +353,9 @@ struct xen_netif_ctrl_request {
>> #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE 5
>> #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING 6
>> #define XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM7
>> +#define XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE 8
>> +#define XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING 9
>> +#define XEN_NETIF_CTRL_TYPE_PUT_GREF_MAPPING 10
>>
>> uint32_t data[3];
>> };
>> @@ -391,6 +394,41 @@ struct xen_netif_ctrl_response {
>> };
>>
>> /*
>> + * Static Grants (struct xen_netif_gref_alloc)
>> + * ===
>> + *
>> + * A frontend may provide a fixed set of grant references to be mapped on
>> + * the backend. The message of type
>> XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
>> + * prior its usage in the command ring allows for creation of these
>> mappings.
>> + * The backend will maintain a fixed amount of these mappings.
>> + *
>> + * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE lets a frontend
>> query how many
>> + * of these mappings can be kept.
>> + *
>> + * Each entry in the XEN_NETIF_CTRL_TYPE_{ADD,PUT}_GREF_MAPPING
>> input table has
>
> ADD and PUT are slightly odd choices for opposites. Normally you'd have 'get'
> and 'put' or 'add' and 'remove' (or 'delete').
>
That's true - I probably was too obsessed into fitting in 3 characters to avoid
realigning the earlier chunk listing all ctrl messages types. ADD, DEL probably
is a better one (GET would sound a bit strange for these ops).
>> + * the following format:
>> + *
>> + *0 1 2 3 4 5 6 7 octet
>> + * +-+-+-+-+-+-+-+-+
>> + * | grant ref | flags| padding |
>> + * +-+-+-+-+-+-+-+-+
>> + *
>> + * grant ref: grant reference
>> + * flags: flags describing the control operation
>> + *
>> + */
>> +
>> +struct xen_netif_gref_alloc {
>
> Is 'alloc' really desirable here? What's being allocated?
>
Probably not my best choice of naming, but given that we aren't actually mapping
on the frontend but rather the backend hence I choose 'alloc'. But as you hint
it might be misleading. Would 'map' or 'mapping' be better candidates?
>> + grant_ref_t ref;
>> + uint16_t flags;
>> +
>> +#define _XEN_NETIF_CTRLF_GREF_readonly0
>> +#define XEN_NETIF_CTRLF_GREF_readonly
>> (1U<<_XEN_NETIF_CTRLF_GREF_readonly)
>> +
>> + uint8_t pad[2];
>> +};
>> +
>> +/*
>> * Control messages
>> *
>> *
>> @@ -609,6 +647,82 @@ struct xen_netif_ctrl_response {
>> * invalidate any table data outside that range.
>> * The grant reference may be read-only and must remain valid until
>> * the response has been processed.
>> + *
>> + * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
>> + * -
>> + *
>> + * This is sent by the frontend to fetch the number of grefs that can be
>> kept
>> + * mapped in the backend.
>> + *
>> + * Request:
>> + *
>> + * type= XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
>> + * data[0] = queue index (assumed 0 for single queue)
>> + * data[1] = 0
>> + * data[2] = 0
>> + *
>> + * Response:
>> + *
>> + * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
>> + * supported
>> + * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The queue index
>> is
>> + * out of range
>> + * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
>> + * data = maximum number of entries allowed in the gref mapping table
>> + * (if operation was successful) or zero if a mapping table is
>> + * not supported (i.e. hash mapping is done only by modular
>> + * arithm
Re: [Xen-devel] [PATCH] osstest: fix a typo in mg-repro-setup
Roger Pau Monne writes ("[PATCH] osstest: fix a typo in mg-repro-setup"):
> Signed-off-by: Roger Pau Monné
Included in my latest push, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 113063: trouble: blocked/broken/fail/pass
flight 113063 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113063/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-xsm 18 guest-localmigrate/x10 fail pass in 113054 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken like 113030 build-arm64-pvops 3 capture-logsbroken like 113030 build-arm64 2 hosts-allocate broken like 113030 build-arm64 3 capture-logsbroken like 113030 build-arm64-xsm 2 hosts-allocate broken like 113030 build-arm64-xsm 3 capture-logsbroken like 113030 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 113030 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 113054 blocked in 113030 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 113054 like 113024 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113024 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 113024 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113024 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113024 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113030 test-amd64-amd64-xl-rtds 10 debian-install fail like 113030 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore 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 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-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd
Re: [Xen-devel] [PATCH v2 1/1] public/io/netif.h: add gref mapping control messages
> -Original Message-
> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> Sent: 01 September 2017 15:51
> To: Xen-devel
> Cc: Wei Liu ; Paul Durrant ;
> Konrad Rzeszutek Wilk ; Joao Martins
>
> Subject: [PATCH v2 1/1] public/io/netif.h: add gref mapping control messages
>
> Adds 3 messages to allow guest to let backend keep grants mapped,
> such that 1) guests allowing fast recycling of pages can avoid doing
> grant ops for those cases, or otherwise 2) preferring copies over
> grants and 3) always using a fixed set of pages for network I/O.
>
> The three control ring messages added are:
> - Add grefs to be mapped by backend
> - Remove grefs mappings (If they are not in use)
> - Get maximum amount of grefs kept mapped.
>
> Signed-off-by: Joao Martins
> ---
> xen/include/public/io/netif.h | 114
> ++
> 1 file changed, 114 insertions(+)
>
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> index ca0061410d..264c317471 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -353,6 +353,9 @@ struct xen_netif_ctrl_request {
> #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING_SIZE 5
> #define XEN_NETIF_CTRL_TYPE_SET_HASH_MAPPING 6
> #define XEN_NETIF_CTRL_TYPE_SET_HASH_ALGORITHM7
> +#define XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE 8
> +#define XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING 9
> +#define XEN_NETIF_CTRL_TYPE_PUT_GREF_MAPPING 10
>
> uint32_t data[3];
> };
> @@ -391,6 +394,41 @@ struct xen_netif_ctrl_response {
> };
>
> /*
> + * Static Grants (struct xen_netif_gref_alloc)
> + * ===
> + *
> + * A frontend may provide a fixed set of grant references to be mapped on
> + * the backend. The message of type
> XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
> + * prior its usage in the command ring allows for creation of these mappings.
> + * The backend will maintain a fixed amount of these mappings.
> + *
> + * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE lets a frontend
> query how many
> + * of these mappings can be kept.
> + *
> + * Each entry in the XEN_NETIF_CTRL_TYPE_{ADD,PUT}_GREF_MAPPING
> input table has
ADD and PUT are slightly odd choices for opposites. Normally you'd have 'get'
and 'put' or 'add' and 'remove' (or 'delete').
> + * the following format:
> + *
> + *0 1 2 3 4 5 6 7 octet
> + * +-+-+-+-+-+-+-+-+
> + * | grant ref | flags| padding |
> + * +-+-+-+-+-+-+-+-+
> + *
> + * grant ref: grant reference
> + * flags: flags describing the control operation
> + *
> + */
> +
> +struct xen_netif_gref_alloc {
Is 'alloc' really desirable here? What's being allocated?
> + grant_ref_t ref;
> + uint16_t flags;
> +
> +#define _XEN_NETIF_CTRLF_GREF_readonly0
> +#define XEN_NETIF_CTRLF_GREF_readonly
> (1U<<_XEN_NETIF_CTRLF_GREF_readonly)
> +
> + uint8_t pad[2];
> +};
> +
> +/*
> * Control messages
> *
> *
> @@ -609,6 +647,82 @@ struct xen_netif_ctrl_response {
> * invalidate any table data outside that range.
> * The grant reference may be read-only and must remain valid until
> * the response has been processed.
> + *
> + * XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
> + * -
> + *
> + * This is sent by the frontend to fetch the number of grefs that can be kept
> + * mapped in the backend.
> + *
> + * Request:
> + *
> + * type= XEN_NETIF_CTRL_TYPE_GET_GREF_MAPPING_SIZE
> + * data[0] = queue index (assumed 0 for single queue)
> + * data[1] = 0
> + * data[2] = 0
> + *
> + * Response:
> + *
> + * status = XEN_NETIF_CTRL_STATUS_NOT_SUPPORTED - Operation not
> + * supported
> + * XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER - The queue index
> is
> + * out of range
> + * XEN_NETIF_CTRL_STATUS_SUCCESS - Operation successful
> + * data = maximum number of entries allowed in the gref mapping table
> + * (if operation was successful) or zero if a mapping table is
> + * not supported (i.e. hash mapping is done only by modular
> + * arithmetic).
Too much cut'n'paste here methinks ;-)
> + *
> + * XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
> + *
> + *
> + * This is sent by the frontend for backend to map a list of grant
> + * references.
> + *
> + * Request:
> + *
> + * type= XEN_NETIF_CTRL_TYPE_ADD_GREF_MAPPING
> + * data[0] = queue index
> + * data[1] = grant reference of page containing the mapping list
> + *(assumed to start at beginning of grant)
Should then be 'assumed to start at beginning of *page*'?
> + * data[2] = size of list in entries
> + *
> + * Response:
> + *
> + * status = XEN_NETIF_CTRL_
[Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction
Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.
This value should only be returned by the core emulator only if it fails to
properly decode the current instruction's opcode, and not by any of other
functions, such as the x86_emulate_ops or the hvm_io_ops callbacks.
e.g. hvm_process_io_incercept should not return X86EMUL_UNIMPLEMENTED.
The return value of this function depends on either the return code of
one of the hvm_io_ops handlers (read/write) or the value returned by
hvm_copy_guest_from_phys / hvm_copy_to_guest_phys.
Similary, none of this functions should not return X86EMUL_UNIMPLEMENTED.
- hvmemul_do_io
- hvm_send_buffered_ioreq
- hvm_send_ioreq
- hvm_broadcast_ioreq
- hvmemul_do_io_buffer
- hvmemul_validate
Signed-off-by: Petre Pircalabu
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/emulate.c | 2 ++
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/hvm/io.c | 1 +
xen/arch/x86/hvm/vmx/realmode.c| 2 +-
xen/arch/x86/mm/shadow/multi.c | 2 +-
xen/arch/x86/x86_emulate/x86_emulate.c | 45 ++
xen/arch/x86/x86_emulate/x86_emulate.h | 6 +
7 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 64454c7..8a6eb74 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2044,6 +2044,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long
gla)
switch ( rc )
{
case X86EMUL_UNHANDLEABLE:
+case X86EMUL_UNIMPLEMENTED:
hvm_dump_emulation_state(XENLOG_G_WARNING, "MMCFG", &ctxt);
break;
case X86EMUL_EXCEPTION:
@@ -2101,6 +2102,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind,
unsigned int trapnr,
* consistent with X86EMUL_RETRY.
*/
return;
+case X86EMUL_UNIMPLEMENTED:
case X86EMUL_UNHANDLEABLE:
hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", &ctx);
hvm_inject_hw_exception(trapnr, errcode);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6cb903d..ea2812c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3695,6 +3695,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
switch ( hvm_emulate_one(&ctxt) )
{
case X86EMUL_UNHANDLEABLE:
+case X86EMUL_UNIMPLEMENTED:
hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
break;
case X86EMUL_EXCEPTION:
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index bf41954..984db21 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -96,6 +96,7 @@ bool hvm_emulate_one_insn(hvm_emulate_validate_t *validate,
const char *descr)
switch ( rc )
{
case X86EMUL_UNHANDLEABLE:
+case X86EMUL_UNIMPLEMENTED:
hvm_dump_emulation_state(XENLOG_G_WARNING, descr, &ctxt);
return false;
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index 11bde58..fdbbee2 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -106,7 +106,7 @@ void vmx_realmode_emulate_one(struct hvm_emulate_ctxt
*hvmemul_ctxt)
if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
vio->io_completion = HVMIO_realmode_completion;
-if ( rc == X86EMUL_UNHANDLEABLE )
+if ( rc == X86EMUL_UNHANDLEABLE || rc == X86EMUL_UNIMPLEMENTED )
{
gdprintk(XENLOG_ERR, "Failed to emulate insn.\n");
goto fail;
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index f7efe66..90cfa40 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3488,7 +3488,7 @@ static int sh_page_fault(struct vcpu *v,
* would be a good unshadow hint. If we *do* decide to unshadow-on-fault
* then it must be 'failable': we cannot require the unshadow to succeed.
*/
-if ( r == X86EMUL_UNHANDLEABLE )
+if ( r == X86EMUL_UNHANDLEABLE || r == X86EMUL_UNIMPLEMENTED )
{
perfc_incr(shadow_fault_emulate_failed);
#if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index c1e2300..ad97d93 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -848,7 +848,8 @@ do{ asm volatile (
\
stub.func); \
generate_exception_if(res_.fields.trapnr == EXC_UD, EXC_UD);\
domain_crash(current->domain); \
-goto cannot_emulate;\
+rc = X86EMUL_UNHANDLEABLE; \
+goto done;
[Xen-devel] [PATCH v10 0/3] Notify monitor when emulating an unimplemented instruction
This patchset implements a mechanism which allows XEN to send first an event if the emulator encountered an unsupported instruction. The monitor application can choose to mitigate the error, for example to singlestep the instruction using the real processor and then resume execution of the normal instruction flow. This feature was tested using a modified version of XTF: https://github.com/petrepircalabu/xen-test-framework/tree/emul_unimpl --- Changed since v1: * Removed the emulation kind check when calling hvm_inject_hw_exception Changed since v2: * Removed a file added by mistake Changed since v3: * Removed extra stray line * Added the _enabled suffix to the emul_unhandleable monitor option Changed since v4 * Fixed return expression of hvm_monitor_emul_unhandleable handle monitor_traps failures. * Removed stray parantheses. Changed since v5: * Removed unnecessary "else" when calling hvm_monitor_emul_unhandleable. * Added extra line in arch_monitor_domctl_event. Changed since v6: * add the distinction between unimplemented instructions and emulation failures. * changed "emul_unhandleable" event name to "emul_unimplemented" Changed since v7: * Add "fall-through" comments to the switch statements (coverity) * Added X86EMUL_UNIMPLEMENTED to X86EMUL_UNHANDLEABLE checks the in functions referencing x86_emulate. * Improved comment describing X86EMUL_UNIMPLEMENTED. Changed since v8: * Removed unnecessary "fall-through" comments. * Added check for X86EMUL_UNIMPLEMENTED in hvm_ud_intercept. * add a new label 'unimplemented_insn' to accomodate the existing jumps to 'cannot_emulate' (e.g. invoke_stub) Changed since v9: * Added detailed description in the patch comment regarding the usage (and lack of it) of the new X86EMUL_UNIMPLEMENTED return code. * removed 'cannot_emulate' label. * added local vimrc files to the gitignore list. Petre Pircalabu (3): gitignore: add local vimrc files x86emul: New return code for unimplemented instruction x86/monitor: Notify monitor if an emulation fails. .gitignore | 1 + tools/libxc/include/xenctrl.h | 2 ++ tools/libxc/xc_monitor.c | 14 +++ xen/arch/x86/hvm/emulate.c | 7 ++ xen/arch/x86/hvm/hvm.c | 1 + xen/arch/x86/hvm/io.c | 1 + xen/arch/x86/hvm/monitor.c | 17 + xen/arch/x86/hvm/vmx/realmode.c| 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/monitor.c | 13 ++ xen/arch/x86/x86_emulate/x86_emulate.c | 45 ++ xen/arch/x86/x86_emulate/x86_emulate.h | 6 + xen/include/asm-x86/domain.h | 1 + xen/include/asm-x86/hvm/monitor.h | 1 + xen/include/asm-x86/monitor.h | 3 ++- xen/include/public/domctl.h| 1 + xen/include/public/vm_event.h | 2 ++ 17 files changed, 95 insertions(+), 24 deletions(-) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v10 3/3] x86/monitor: Notify monitor if an emulation fails.
If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.
Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
Acked-by: Wei Liu
Acked-by: Jan Beulich
---
tools/libxc/include/xenctrl.h | 2 ++
tools/libxc/xc_monitor.c | 14 ++
xen/arch/x86/hvm/emulate.c| 5 +
xen/arch/x86/hvm/monitor.c| 17 +
xen/arch/x86/monitor.c| 13 +
xen/include/asm-x86/domain.h | 1 +
xen/include/asm-x86/hvm/monitor.h | 1 +
xen/include/asm-x86/monitor.h | 3 ++-
xen/include/public/domctl.h | 1 +
xen/include/public/vm_event.h | 2 ++
10 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 43151cb..1a179d9 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2028,6 +2028,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch,
domid_t domain_id,
int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+ bool enable);
/**
* This function enables / disables emulation for each REP for a
* REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index a677820..6046680 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -217,6 +217,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t
domain_id,
return do_domctl(xch, &domctl);
}
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+ bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED;
+
+return do_domctl(xch, &domctl);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 8a6eb74..c9066bb 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -2103,6 +2105,9 @@ void hvm_emulate_one_vm_event(enum emul_kind kind,
unsigned int trapnr,
*/
return;
case X86EMUL_UNIMPLEMENTED:
+if ( hvm_monitor_emul_unimplemented() )
+return;
+/* fall-through */
case X86EMUL_UNHANDLEABLE:
hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", &ctx);
hvm_inject_hw_exception(trapnr, errcode);
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..3551463 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,23 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long
value, unsigned long old
return 0;
}
+bool hvm_monitor_emul_unimplemented(void)
+{
+struct vcpu *curr = current;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNIMPLEMENTED,
+.vcpu_id = curr->vcpu_id,
+};
+
+return curr->domain->arch.monitor.emul_unimplemented_enabled &&
+monitor_traps(curr, true, &req) == 1;
+}
+
void hvm_monitor_msr(unsigned int msr, uint64_t value)
{
struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..e59f1f5 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,19 @@ int arch_monitor_domctl_event(struct domain *d,
break;
}
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED:
+{
+bool old_status = ad->monitor.emul_unimplemented_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unimplemented_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
default:
/*
* Should not be reached unless arch_monitor_get_capabilities() is
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index fb8bf17..fcab8f8 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -406,6 +406,7 @@ struct arch_domain
unsigned int cpuid_enabled
[Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files
Signed-off-by: Petre Pircalabu --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 594ffd9..8af9c02 100644 --- a/.gitignore +++ b/.gitignore @@ -27,6 +27,7 @@ cscope.in.out cscope.out cscope.po.out .config +.vimrc dist stubdom/*.tar.gz -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 03/13] libxl: add vdispl device
On Wed, Sep 06, 2017 at 04:02:23PM +0300, Oleksandr Grytsov wrote:
> On Tue, Sep 5, 2017 at 4:04 PM, Wei Liu wrote:
> > On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
> >> > > +rc = snprintf(connector_path, 128, "%s/%d", path,
> >> > > info->num_connectors);
> >>
> >> Why not use GCSPRINTF ? These statically sized buffers etc. are an
> >> invitation to bugs.
> >
> > Right, that's a better suggestion.
>
> I reuse connector_path buffer as path to read connector settings from xen
> store.
> So if I use GCSPRINTF for each setting then this function will allocate
> about 256 bytes for one connector. In typical scenario each frontend will
> have 1 or 2 connectors.
>
That's OK I think.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/3] Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen"
This reverts commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492.
This patch prevents PCI passthrough hotplug on Xen. Even if the Xen tool
stack prepares its own ACPI tables, we still rely on QEMU for hotplug
ACPI notifications.
The original issue is fixed by the two previous patch:
hw/acpi: Limit hotplug to root bus on legacy mode
hw/acpi: Move acpi_set_pci_info to pcihp
Signed-off-by: Anthony PERARD
---
CC: Stefano Stabellini
CC: Bruce Rogers
---
hw/acpi/piix4.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index f276967365..f4fd5907b8 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -385,10 +385,7 @@ static void piix4_device_plug_cb(HotplugHandler
*hotplug_dev,
dev, errp);
}
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
-if (!xen_enabled()) {
-acpi_pcihp_device_plug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev,
- errp);
-}
+acpi_pcihp_device_plug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev,
errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
if (s->cpu_hotplug_legacy) {
legacy_acpi_cpu_plug_cb(hotplug_dev, &s->gpe_cpu, dev, errp);
@@ -411,10 +408,8 @@ static void piix4_device_unplug_request_cb(HotplugHandler
*hotplug_dev,
acpi_memory_unplug_request_cb(hotplug_dev, &s->acpi_memory_hotplug,
dev, errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
-if (!xen_enabled()) {
-acpi_pcihp_device_unplug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev,
-errp);
-}
+acpi_pcihp_device_unplug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev,
+errp);
} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!s->cpu_hotplug_legacy) {
acpi_cpu_unplug_request_cb(hotplug_dev, &s->cpuhp_state, dev, errp);
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/3] hw/acpi: Move acpi_set_pci_info to pcihp
HW part of ACPI PCI hotplug in QEMU depends on ACPI_PCIHP_PROP_BSEL
being set on a PCI bus that supports ACPI hotplug. It should work
regardless of the source of ACPI tables (QEMU generator/legacy SeaBIOS/Xen).
So move ACPI_PCIHP_PROP_BSEL initialization into HW ACPI implementation
part from QEMU's ACPI table generator.
To do PCI passthrough with Xen, the property ACPI_PCIHP_PROP_BSEL needs
to be set, but this was done only when ACPI tables are built which is
not needed for a Xen guest. The need for the property starts with commit
"pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
(f0c9d64a68b776374ec4732424a3e27753ce37b6).
Adding find_i440fx into stubs so that mips-softmmu target can be built.
Reported-by: Sander Eikelenboom
Signed-off-by: Anthony PERARD
---
Changes in V4:
- call acpi_set_pci_info only once
- Add a stub of find_i440fx (for mips_softmmu target)
Changes in V3:
- move acpi_set_pci_info to pcihp instead
Changes in V2:
- check for acpi_enabled before calling acpi_set_pci_info.
- set the property on the root bus only.
---
hw/acpi/pcihp.c | 38 ++
hw/i386/acpi-build.c | 32
stubs/Makefile.objs | 1 +
stubs/pci-host-piix.c | 6 ++
4 files changed, 45 insertions(+), 32 deletions(-)
create mode 100644 stubs/pci-host-piix.c
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 9db3c2eaf2..7da51c0569 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -75,6 +75,43 @@ static int acpi_pcihp_get_bsel(PCIBus *bus)
}
}
+/* Assign BSEL property to all buses. In the future, this can be changed
+ * to only assign to buses that support hotplug.
+ */
+static void *acpi_set_bsel(PCIBus *bus, void *opaque)
+{
+unsigned *bsel_alloc = opaque;
+unsigned *bus_bsel;
+
+if (qbus_is_hotpluggable(BUS(bus))) {
+bus_bsel = g_malloc(sizeof *bus_bsel);
+
+*bus_bsel = (*bsel_alloc)++;
+object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
+ bus_bsel, &error_abort);
+}
+
+return bsel_alloc;
+}
+
+static void acpi_set_pci_info(void)
+{
+static bool bsel_is_set;
+PCIBus *bus;
+unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
+
+if (bsel_is_set) {
+return;
+}
+bsel_is_set = true;
+
+bus = find_i440fx(); /* TODO: Q35 support */
+if (bus) {
+/* Scan all PCI buses. Set property to enable acpi based hotplug. */
+pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, &bsel_alloc);
+}
+}
+
static void acpi_pcihp_test_hotplug_bus(PCIBus *bus, void *opaque)
{
AcpiPciHpFind *find = opaque;
@@ -177,6 +214,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
void acpi_pcihp_reset(AcpiPciHpState *s)
{
+acpi_set_pci_info();
acpi_pcihp_update(s);
}
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 98dd424678..4d19d91e1b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -493,36 +493,6 @@ build_madt(GArray *table_data, BIOSLinker *linker,
PCMachineState *pcms)
table_data->len - madt_start, 1, NULL, NULL);
}
-/* Assign BSEL property to all buses. In the future, this can be changed
- * to only assign to buses that support hotplug.
- */
-static void *acpi_set_bsel(PCIBus *bus, void *opaque)
-{
-unsigned *bsel_alloc = opaque;
-unsigned *bus_bsel;
-
-if (qbus_is_hotpluggable(BUS(bus))) {
-bus_bsel = g_malloc(sizeof *bus_bsel);
-
-*bus_bsel = (*bsel_alloc)++;
-object_property_add_uint32_ptr(OBJECT(bus), ACPI_PCIHP_PROP_BSEL,
- bus_bsel, &error_abort);
-}
-
-return bsel_alloc;
-}
-
-static void acpi_set_pci_info(void)
-{
-PCIBus *bus = find_i440fx(); /* TODO: Q35 support */
-unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
-
-if (bus) {
-/* Scan all PCI buses. Set property to enable acpi based hotplug. */
-pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, &bsel_alloc);
-}
-}
-
static void build_append_pcihp_notify_entry(Aml *method, int slot)
{
Aml *if_ctx;
@@ -2888,8 +2858,6 @@ void acpi_setup(void)
build_state = g_malloc0(sizeof *build_state);
-acpi_set_pci_info();
-
acpi_build_tables_init(&tables);
acpi_build(&tables, MACHINE(pcms));
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index e69c217aff..4a33495911 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -40,3 +40,4 @@ stub-obj-y += pc_madt_cpu_entry.o
stub-obj-y += vmgenid.o
stub-obj-y += xen-common.o
stub-obj-y += xen-hvm.o
+stub-obj-y += pci-host-piix.o
diff --git a/stubs/pci-host-piix.c b/stubs/pci-host-piix.c
new file mode 100644
index 00..6ed81b1f21
--- /dev/null
+++ b/stubs/pci-host-piix.c
@@ -0,0 +1,6 @@
+#include "qemu/osdep.h"
+#include "hw/i386/pc.h"
+PCIBus *find_i440fx(void)
+{
+return NULL;
+}
--
Anthony PERARD
___
Xen
[Xen-devel] [PATCH v4 0/3] Fix hotplug of PCI passthrought device on Xen
Adding PCI passthrough before the guest start works fine (broken in 2.9 but now fixed), but hotplug does not work anymore. Anthony PERARD (3): hw/acpi: Limit hotplug to root bus on legacy mode hw/acpi: Move acpi_set_pci_info to pcihp Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen" hw/acpi/pcihp.c | 40 +++- hw/acpi/piix4.c | 11 +++ hw/i386/acpi-build.c | 32 stubs/Makefile.objs | 1 + stubs/pci-host-piix.c | 6 ++ 5 files changed, 49 insertions(+), 41 deletions(-) create mode 100644 stubs/pci-host-piix.c -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/3] hw/acpi: Limit hotplug to root bus on legacy mode
Signed-off-by: Anthony PERARD
---
New patch in V3
---
hw/acpi/pcihp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index c420a388ea..9db3c2eaf2 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -273,7 +273,7 @@ static void pci_write(void *opaque, hwaddr addr, uint64_t
data,
addr, data);
break;
case PCI_SEL_BASE:
-s->hotplug_select = data;
+s->hotplug_select = s->legacy_piix ? ACPI_PCIHP_BSEL_DEFAULT : data;
ACPI_PCIHP_DPRINTF("pcisel write %" HWADDR_PRIx " <== %" PRIu64 "\n",
addr, data);
default:
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function
On 09/06/2017 09:06 AM, Peter Zijlstra wrote: > On Wed, Sep 06, 2017 at 08:44:09AM -0400, Waiman Long wrote: >> On 09/06/2017 03:08 AM, Peter Zijlstra wrote: >>> Guys, please trim email. >>> >>> On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote: For clarification, I was actually asking if you consider just adding one more jump label to skip it for Xen/KVM instead of making virt_spin_lock() a pv-op. >>> I don't understand. What performance are you worried about. Native will >>> now do: "xor rax,rax; jnz some_cold_label" that's fairly trival code. >> It is not native that I am talking about. I am worry about VM with >> non-Xen/KVM hypervisor where virt_spin_lock() will actually be called. >> Now that function will become a callee-saved function call instead of >> being inlined into the native slowpath function. > But only if we actually end up using the test-and-set thing, because if > you have paravirt we end up using that. I am talking about scenario like a kernel with paravirt spinlock running in a VM managed by VMware, for example. We may not want to penalize them while there are alternatives with less penalty. Cheers, Longman ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 8/8] libxl: add libxl support for setting grant table resource limits
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ;
> julien.gr...@arm.com; jbeul...@suse.com
> Subject: [Xen-devel] [PATCH v3 8/8] libxl: add libxl support for setting grant
> table resource limits
>
> Add new domain config items for setting the limits for the maximum
> numbers of grant table frames and maptrack frames of a domain.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
> ---
> docs/man/xl.cfg.pod.5.in| 15 +++
> tools/libxl/libxl.h | 6 ++
> tools/libxl/libxl_dom.c | 8
> tools/libxl/libxl_types.idl | 3 +++
> tools/xl/xl_parse.c | 5 +
> tools/xl/xl_sxp.c | 2 ++
> 6 files changed, 39 insertions(+)
>
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index 79cb2eaea7..dd0b232020 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -444,6 +444,21 @@ unpausing the domain. With a properly constructed
> security policy (such
> as nomigrate_t in the example policy), this can be used to build a
> domain whose memory is not accessible to the toolstack domain.
>
> +=item B
> +
> +Specify the maximum number of grant frames the domain is allowed to
> have.
> +This value controls how many pages the domain is able to grant access to for
> +other domains, needed e.g. for the operation of paravirtualized devices.
> +The default is 32, if not set to another value via a Xen boot parameter.
> +
> +=item B
> +
> +Specify the maximum number of grant maptrack frames the domain is
> allowed
> +to have. This value controls how many pages of foreign domains can be
> accessed
> +via the grant mechanism by this domain. A value higher than the normal
> default
> +of 1024 is normally needed only for very large configurations for driver
> +domains.
> +
> =item B
>
> Disable migration of this domain. This enables certain other features
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 812b7ea95d..fef22c2306 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -311,6 +311,12 @@
> #define LIBXL_HAVE_P9S 1
>
> /*
> + * LIBXL_HAVE_BUILDINFO_GRANT_LIMITS indicates that
> libxl_domain_build_info
> + * has the grant_frames and maptrack_frames fields.
> + */
> +#define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
> +
> +/*
> * libxl ABI compatibility
> *
> * The only guarantee which libxl makes regarding ABI compatibility
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index f54fd49a73..080335874e 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -322,6 +322,14 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> return ERROR_FAIL;
> }
>
> +if (info->grant_frames || info->maptrack_frames) {
> +if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->grant_frames,
> +info->maptrack_frames) != 0) {
> +LOG(ERROR, "Couldn't set grant table limits");
> +return ERROR_FAIL;
> +}
> +}
> +
> /*
> * Check if the domain has any CPU or node affinity already. If not, try
> * to build up the latter via automatic NUMA placement. In fact, in case
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 173d70acec..2aa7dae83e 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -472,6 +472,9 @@ libxl_domain_build_info =
> Struct("domain_build_info",[
> ("blkdev_start",string),
>
> ("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
> +
> +("grant_frames",uint32),
> +("maptrack_frames", uint32),
>
> ("device_model_version", libxl_device_model_version),
> ("device_model_stubdomain", libxl_defbool),
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 02ddd2e90d..dae3a238a4 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -943,6 +943,11 @@ void parse_config_data(const char *config_source,
> !xlu_cfg_get_string (config, "cpus_soft", &buf, 0))
> parse_vcpu_affinity(b_info, cpus, buf, num_cpus, false);
>
> +if (!xlu_cfg_get_long (config, "grant_frames", &l, 0))
> +b_info->grant_frames = l;
> +if (!xlu_cfg_get_long (config, "maptrack_frames", &l, 0))
> +b_info->maptrack_frames = l;
> +
> libxl_defbool_set(&b_info->claim_mode, claim_mode);
>
> if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
> diff --git a/tools/xl/xl_sxp.c b/tools/xl/xl_sxp.c
> index e738bf2465..4b2fab2d35 100644
> --- a/tools/xl/xl_sxp.c
> +++ b/tools/xl/xl_sxp.c
> @@ -64,6 +64,8 @@ void printf_info_sexp(int domid, libxl_domain_config
> *d_config, FILE *fh)
>
> fprintf(fh, "\t(build_info)\n");
> fprintf(fh, "\t
Re: [Xen-devel] [PATCH v3 7/8] libxc: add libxc support for setting grant table resource limits
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ;
> julien.gr...@arm.com; jbeul...@suse.com
> Subject: [Xen-devel] [PATCH v3 7/8] libxc: add libxc support for setting grant
> table resource limits
>
> Add a new libxc function xc_domain_set_gnttbl_limits() setting the
> limits for the maximum numbers of grant table frames and maptrack
> frames of a domain.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
> ---
> tools/libxc/include/xenctrl.h | 14 ++
> tools/libxc/xc_domain.c | 13 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 43151cb415..39b58cf5b7 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1064,6 +1064,20 @@ int xc_domain_set_virq_handler(xc_interface
> *xch, uint32_t domid, int virq);
> int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
> uint32_t max_port);
>
> +/**
> + * Set the maximum number of grant frames and/or maptrack frames a
> domain
> + * can have. Can only be used at domain setup time. A zero value means
> + * no change.
> + *
> + * @param xch a handle to an open hypervisor interface
> + * @param domid the domain id
> + * @param grant_frames max. number of grant frames
> + * @param maptrack_frames max. number of maptrack frames
> + */
> +int xc_domain_set_gnttab_limits(xc_interface *xch, uint32_t domid,
> +uint32_t grant_frames,
> +uint32_t maptrack_frames);
> +
> /*
> * CPUPOOL MANAGEMENT FUNCTIONS
> */
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 3bab4e8bab..e59665ff6e 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2268,6 +2268,19 @@ int xc_domain_set_max_evtchn(xc_interface
> *xch, uint32_t domid,
> return do_domctl(xch, &domctl);
> }
>
> +int xc_domain_set_gnttab_limits(xc_interface *xch, uint32_t domid,
> +uint32_t grant_frames,
> +uint32_t maptrack_frames)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_set_gnttab_limits;
> +domctl.domain = domid;
> +domctl.u.set_gnttab_limits.grant_frames = grant_frames;
> +domctl.u.set_gnttab_limits.maptrack_frames = maptrack_frames;
> +return do_domctl(xch, &domctl);
> +}
> +
> /* Plumbing Xen with vNUMA topology */
> int xc_domain_setvnuma(xc_interface *xch,
> uint32_t domid,
> --
> 2.12.3
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/8] xen: add new domctl hypercall to set grant table resource limits
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ;
> julien.gr...@arm.com; jbeul...@suse.com
> Subject: [Xen-devel] [PATCH v3 6/8] xen: add new domctl hypercall to set
> grant table resource limits
>
> Add a domctl hypercall to set the domain's resource limits regarding
> grant tables. It is accepted only as long as neither
> gnttab_setup_table() has been called for the domain, nor the domain
> has started to run.
>
> Signed-off-by: Juergen Gross
> ---
> V3:
> - rename *gnttbl* to *gnttab* (Paul Durrant)
Reviewed-by: Paul Durrant
> ---
> tools/flask/policy/modules/dom0.te | 2 +-
> xen/common/domctl.c | 6 ++
> xen/common/grant_table.c| 26 ++
> xen/include/public/domctl.h | 9 +
> xen/include/xen/grant_table.h | 2 ++
> xen/xsm/flask/hooks.c | 3 +++
> xen/xsm/flask/policy/access_vectors | 2 ++
> 7 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/tools/flask/policy/modules/dom0.te
> b/tools/flask/policy/modules/dom0.te
> index 338caaf41e..1643b400f0 100644
> --- a/tools/flask/policy/modules/dom0.te
> +++ b/tools/flask/policy/modules/dom0.te
> @@ -39,7 +39,7 @@ allow dom0_t dom0_t:domain {
> };
> allow dom0_t dom0_t:domain2 {
> set_cpuid gettsc settsc setscheduler set_max_evtchn
> set_vnumainfo
> - get_vnumainfo psr_cmt_op psr_cat_op
> + get_vnumainfo psr_cmt_op psr_cat_op set_gnttab_limits
> };
> allow dom0_t dom0_t:resource { add remove };
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 42658e5744..58381f8fe9 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1149,6 +1150,11 @@ long
> do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> copyback = 1;
> break;
>
> +case XEN_DOMCTL_set_gnttab_limits:
> +ret = grant_table_set_limits(d, op->u.set_gnttab_limits.grant_frames,
> +
> op->u.set_gnttab_limits.maptrack_frames);
> +break;
> +
> default:
> ret = arch_do_domctl(op, d, u_domctl);
> break;
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index c00119f2fe..83f1a9dd34 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v)
> v->maptrack_tail = MAPTRACK_TAIL;
> }
>
> +int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
> + unsigned int maptrack_frames)
> +{
> +struct grant_table *gt = d->grant_table;
> +int ret = -EBUSY;
> +
> +if ( !gt )
> +return -EEXIST;
> +
> +grant_write_lock(gt);
> +
> +if ( gt->nr_grant_frames )
> +goto unlock;
> +
> +ret = 0;
> +if ( grant_frames )
> +gt->max_grant_frames = grant_frames;
> +if ( maptrack_frames )
> +gt->max_maptrack_frames = maptrack_frames;
> +
> + unlock:
> +grant_write_unlock(gt);
> +
> +return ret;
> +}
> +
> #ifdef CONFIG_HAS_MEM_SHARING
> int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
> gfn_t *gfn, uint16_t *status)
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 50ff58f5b9..f7e3509c27 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1163,6 +1163,13 @@ struct xen_domctl_psr_cat_op {
> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>
> +struct xen_domctl_set_gnttab_limits {
> +uint32_t grant_frames; /* IN: if 0, dont change */
> +uint32_t maptrack_frames; /* IN: if 0, dont change */
> +};
> +typedef struct xen_domctl_set_gnttab_limits
> xen_domctl_set_gnttab_limits_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_gnttab_limits_t);
> +
> struct xen_domctl {
> uint32_t cmd;
> #define XEN_DOMCTL_createdomain 1
> @@ -1240,6 +1247,7 @@ struct xen_domctl {
> #define XEN_DOMCTL_monitor_op77
> #define XEN_DOMCTL_psr_cat_op78
> #define XEN_DOMCTL_soft_reset79
> +#define XEN_DOMCTL_set_gnttab_limits 80
> #define XEN_DOMCTL_gdbsx_guestmemio1000
> #define XEN_DOMCTL_gdbsx_pausevcpu 1001
> #define XEN_DOMCTL_gdbsx_unpausevcpu 1002
> @@ -1302,6 +1310,7 @@ struct xen_domctl {
> struct xen_domctl_psr_cmt_oppsr_cmt_op;
> struct xen_domctl_monitor_opmonitor_op;
> struct xen_domctl_psr_cat_oppsr_cat_op;
> +struct xen_domctl_s
Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function
On Wed, Sep 06, 2017 at 08:44:09AM -0400, Waiman Long wrote: > On 09/06/2017 03:08 AM, Peter Zijlstra wrote: > > Guys, please trim email. > > > > On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote: > >> For clarification, I was actually asking if you consider just adding one > >> more jump label to skip it for Xen/KVM instead of making > >> virt_spin_lock() a pv-op. > > I don't understand. What performance are you worried about. Native will > > now do: "xor rax,rax; jnz some_cold_label" that's fairly trival code. > > It is not native that I am talking about. I am worry about VM with > non-Xen/KVM hypervisor where virt_spin_lock() will actually be called. > Now that function will become a callee-saved function call instead of > being inlined into the native slowpath function. But only if we actually end up using the test-and-set thing, because if you have paravirt we end up using that. And the test-and-set thing sucks anyway. But yes, you're right, that case gets worse. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Juergen Gross
> Sent: 06 September 2017 13:47
> To: xen-devel@lists.xen.org
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ;
> julien.gr...@arm.com; jbeul...@suse.com
> Subject: [Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub
> structures
>
> Delay the allocation of the grant table sub structures in order to
> allow modifying parameters needed for sizing of these structures at a
> per domain basis. Either do it from gnttab_setup_table() or just
> before the domain is started the first time.
>
> Signed-off-by: Juergen Gross
> ---
> V3:
> - move call of grant_table_init() from gnttab_setup_table() to
> gnttab_grow_table() (Paul Durrant)
Thanks :-)
Reviewed-by: Paul Durrant
> ---
> xen/common/domain.c | 17 +-
> xen/common/grant_table.c | 138 --
>
> xen/include/xen/grant_table.h | 2 +
> 3 files changed, 96 insertions(+), 61 deletions(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 5aebcf265f..11eb1778a3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid,
> unsigned int domcr_flags,
> goto fail;
> init_status |= INIT_gnttab;
>
> +if ( domid == 0 && grant_table_init(d) )
> +goto fail;
> +
> poolid = 0;
>
> err = -ENOMEM;
> @@ -998,7 +1001,8 @@ int __domain_pause_by_systemcontroller(struct
> domain *d,
> prev = cmpxchg(&d->controller_pause_count, old, new);
> } while ( prev != old );
>
> -pause_fn(d);
> +if ( pause_fn )
> +pause_fn(d);
>
> return 0;
> }
> @@ -1006,6 +1010,7 @@ int __domain_pause_by_systemcontroller(struct
> domain *d,
> int domain_unpause_by_systemcontroller(struct domain *d)
> {
> int old, new, prev = d->controller_pause_count;
> +int ret;
>
> do
> {
> @@ -1029,8 +1034,16 @@ int domain_unpause_by_systemcontroller(struct
> domain *d)
> * Creation is considered finished when the controller reference count
> * first drops to 0.
> */
> -if ( new == 0 )
> +if ( new == 0 && !d->creation_finished )
> +{
> +ret = grant_table_init(d);
> +if ( ret )
> +{
> +__domain_pause_by_systemcontroller(d, NULL);
> +return ret;
> +}
> d->creation_finished = true;
> +}
>
> domain_unpause(d);
>
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 4520e36d90..29e7fa539b 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1655,6 +1655,78 @@ gnttab_unpopulate_status_frames(struct domain
> *d, struct grant_table *gt)
> gt->nr_status_frames = 0;
> }
>
> +int
> +grant_table_init(struct domain *d)
> +{
> +struct grant_table *gt = d->grant_table;
> +unsigned int i, j;
> +
> +if ( gt->nr_grant_frames )
> +return 0;
> +
> +gt->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
> +
> +/* Active grant table. */
> +if ( (gt->active = xzalloc_array(struct active_grant_entry *,
> + max_nr_active_grant_frames)) == NULL )
> +goto no_mem_1;
> +for ( i = 0;
> + i <
> num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
> +{
> +if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
> +goto no_mem_2;
> +clear_page(gt->active[i]);
> +for ( j = 0; j < ACGNT_PER_PAGE; j++ )
> +spin_lock_init(>->active[i][j].lock);
> +}
> +
> +/* Tracking of mapped foreign frames table */
> +gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
> +if ( gt->maptrack == NULL )
> +goto no_mem_2;
> +
> +/* Shared grant table. */
> +if ( (gt->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL
> )
> +goto no_mem_3;
> +for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
> +{
> +if ( (gt->shared_raw[i] = alloc_xenheap_page()) == NULL )
> +goto no_mem_4;
> +clear_page(gt->shared_raw[i]);
> +}
> +
> +/* Status pages for grant table - for version 2 */
> +gt->status = xzalloc_array(grant_status_t *,
> + grant_to_status_frames(max_grant_frames));
> +if ( gt->status == NULL )
> +goto no_mem_4;
> +
> +for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
> +gnttab_create_shared_page(d, gt, i);
> +
> +gt->nr_status_frames = 0;
> +
> +return 0;
> +
> + no_mem_4:
> +for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
> +free_xenheap_page(gt->shared_raw[i]);
> +xfree(gt->shared_raw);
> +gt->shared_raw = NULL;
> + no_mem_3:
> +vfree(gt->maptrack);
> +gt->maptrack = NULL;
> + no_mem_2:
> +for ( i = 0;
> +
Re: [Xen-devel] [PATCH v4 03/13] libxl: add vdispl device
On Tue, Sep 5, 2017 at 4:04 PM, Wei Liu wrote:
> On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"):
>> > > +rc = snprintf(connector_path, 128, "%s/%d", path,
>> > > info->num_connectors);
>>
>> Why not use GCSPRINTF ? These statically sized buffers etc. are an
>> invitation to bugs.
>
> Right, that's a better suggestion.
I reuse connector_path buffer as path to read connector settings from xen store.
So if I use GCSPRINTF for each setting then this function will allocate
about 256 bytes for one connector. In typical scenario each frontend will
have 1 or 2 connectors.
If it is ok I will use GCSPRINTF.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 113071: all pass - PUSHED
flight 113071 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113071/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
baseline version:
xen ee2c1fc48ac14a4c8b9eb9224753591fa5e7
Last test of basis 113023 2017-09-03 09:19:46 Z3 days
Testing same since 113071 2017-09-06 11:11:37 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
George Dunlap
Jan Beulich
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 :
+ branch=xen-unstable-coverity
+ revision=6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push
xen-unstable-coverity 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
+ branch=xen-unstable-coverity
+ revision=6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.9-testing
+ '[' x6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable-coverity
++ : daily-cron.xen-unstable-coverity
++ : daily-cron.xen-unstable-coverity
++ : d
[Xen-devel] [PATCH v3 8/8] libxl: add libxl support for setting grant table resource limits
Add new domain config items for setting the limits for the maximum
numbers of grant table frames and maptrack frames of a domain.
Signed-off-by: Juergen Gross
---
docs/man/xl.cfg.pod.5.in| 15 +++
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_dom.c | 8
tools/libxl/libxl_types.idl | 3 +++
tools/xl/xl_parse.c | 5 +
tools/xl/xl_sxp.c | 2 ++
6 files changed, 39 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 79cb2eaea7..dd0b232020 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -444,6 +444,21 @@ unpausing the domain. With a properly constructed security
policy (such
as nomigrate_t in the example policy), this can be used to build a
domain whose memory is not accessible to the toolstack domain.
+=item B
+
+Specify the maximum number of grant frames the domain is allowed to have.
+This value controls how many pages the domain is able to grant access to for
+other domains, needed e.g. for the operation of paravirtualized devices.
+The default is 32, if not set to another value via a Xen boot parameter.
+
+=item B
+
+Specify the maximum number of grant maptrack frames the domain is allowed
+to have. This value controls how many pages of foreign domains can be accessed
+via the grant mechanism by this domain. A value higher than the normal default
+of 1024 is normally needed only for very large configurations for driver
+domains.
+
=item B
Disable migration of this domain. This enables certain other features
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 812b7ea95d..fef22c2306 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -311,6 +311,12 @@
#define LIBXL_HAVE_P9S 1
/*
+ * LIBXL_HAVE_BUILDINFO_GRANT_LIMITS indicates that libxl_domain_build_info
+ * has the grant_frames and maptrack_frames fields.
+ */
+#define LIBXL_HAVE_BUILDINFO_GRANT_LIMITS 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f54fd49a73..080335874e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -322,6 +322,14 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
return ERROR_FAIL;
}
+if (info->grant_frames || info->maptrack_frames) {
+if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->grant_frames,
+info->maptrack_frames) != 0) {
+LOG(ERROR, "Couldn't set grant table limits");
+return ERROR_FAIL;
+}
+}
+
/*
* Check if the domain has any CPU or node affinity already. If not, try
* to build up the latter via automatic NUMA placement. In fact, in case
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 173d70acec..2aa7dae83e 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -472,6 +472,9 @@ libxl_domain_build_info = Struct("domain_build_info",[
("blkdev_start",string),
("vnuma_nodes", Array(libxl_vnode_info, "num_vnuma_nodes")),
+
+("grant_frames",uint32),
+("maptrack_frames", uint32),
("device_model_version", libxl_device_model_version),
("device_model_stubdomain", libxl_defbool),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 02ddd2e90d..dae3a238a4 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -943,6 +943,11 @@ void parse_config_data(const char *config_source,
!xlu_cfg_get_string (config, "cpus_soft", &buf, 0))
parse_vcpu_affinity(b_info, cpus, buf, num_cpus, false);
+if (!xlu_cfg_get_long (config, "grant_frames", &l, 0))
+b_info->grant_frames = l;
+if (!xlu_cfg_get_long (config, "maptrack_frames", &l, 0))
+b_info->maptrack_frames = l;
+
libxl_defbool_set(&b_info->claim_mode, claim_mode);
if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
diff --git a/tools/xl/xl_sxp.c b/tools/xl/xl_sxp.c
index e738bf2465..4b2fab2d35 100644
--- a/tools/xl/xl_sxp.c
+++ b/tools/xl/xl_sxp.c
@@ -64,6 +64,8 @@ void printf_info_sexp(int domid, libxl_domain_config
*d_config, FILE *fh)
fprintf(fh, "\t(build_info)\n");
fprintf(fh, "\t(max_vcpus %d)\n", b_info->max_vcpus);
+fprintf(fh, "\t(grant_frames %d)\n", b_info->grant_frames);
+fprintf(fh, "\t(maptrack_frames %d)\n", b_info->maptrack_frames);
fprintf(fh, "\t(tsc_mode %s)\n",
libxl_tsc_mode_to_string(b_info->tsc_mode));
fprintf(fh, "\t(max_memkb %"PRId64")\n", b_info->max_memkb);
fprintf(fh, "\t(target_memkb %"PRId64")\n", b_info->target_memkb);
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 3/8] xen: delay allocation of grant table sub structures
Delay the allocation of the grant table sub structures in order to
allow modifying parameters needed for sizing of these structures at a
per domain basis. Either do it from gnttab_setup_table() or just
before the domain is started the first time.
Signed-off-by: Juergen Gross
---
V3:
- move call of grant_table_init() from gnttab_setup_table() to
gnttab_grow_table() (Paul Durrant)
---
xen/common/domain.c | 17 +-
xen/common/grant_table.c | 138 --
xen/include/xen/grant_table.h | 2 +
3 files changed, 96 insertions(+), 61 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 5aebcf265f..11eb1778a3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid, unsigned int
domcr_flags,
goto fail;
init_status |= INIT_gnttab;
+if ( domid == 0 && grant_table_init(d) )
+goto fail;
+
poolid = 0;
err = -ENOMEM;
@@ -998,7 +1001,8 @@ int __domain_pause_by_systemcontroller(struct domain *d,
prev = cmpxchg(&d->controller_pause_count, old, new);
} while ( prev != old );
-pause_fn(d);
+if ( pause_fn )
+pause_fn(d);
return 0;
}
@@ -1006,6 +1010,7 @@ int __domain_pause_by_systemcontroller(struct domain *d,
int domain_unpause_by_systemcontroller(struct domain *d)
{
int old, new, prev = d->controller_pause_count;
+int ret;
do
{
@@ -1029,8 +1034,16 @@ int domain_unpause_by_systemcontroller(struct domain *d)
* Creation is considered finished when the controller reference count
* first drops to 0.
*/
-if ( new == 0 )
+if ( new == 0 && !d->creation_finished )
+{
+ret = grant_table_init(d);
+if ( ret )
+{
+__domain_pause_by_systemcontroller(d, NULL);
+return ret;
+}
d->creation_finished = true;
+}
domain_unpause(d);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 4520e36d90..29e7fa539b 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1655,6 +1655,78 @@ gnttab_unpopulate_status_frames(struct domain *d, struct
grant_table *gt)
gt->nr_status_frames = 0;
}
+int
+grant_table_init(struct domain *d)
+{
+struct grant_table *gt = d->grant_table;
+unsigned int i, j;
+
+if ( gt->nr_grant_frames )
+return 0;
+
+gt->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
+
+/* Active grant table. */
+if ( (gt->active = xzalloc_array(struct active_grant_entry *,
+ max_nr_active_grant_frames)) == NULL )
+goto no_mem_1;
+for ( i = 0;
+ i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+{
+if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
+goto no_mem_2;
+clear_page(gt->active[i]);
+for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+spin_lock_init(>->active[i][j].lock);
+}
+
+/* Tracking of mapped foreign frames table */
+gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
+if ( gt->maptrack == NULL )
+goto no_mem_2;
+
+/* Shared grant table. */
+if ( (gt->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL )
+goto no_mem_3;
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+{
+if ( (gt->shared_raw[i] = alloc_xenheap_page()) == NULL )
+goto no_mem_4;
+clear_page(gt->shared_raw[i]);
+}
+
+/* Status pages for grant table - for version 2 */
+gt->status = xzalloc_array(grant_status_t *,
+ grant_to_status_frames(max_grant_frames));
+if ( gt->status == NULL )
+goto no_mem_4;
+
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+gnttab_create_shared_page(d, gt, i);
+
+gt->nr_status_frames = 0;
+
+return 0;
+
+ no_mem_4:
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+free_xenheap_page(gt->shared_raw[i]);
+xfree(gt->shared_raw);
+gt->shared_raw = NULL;
+ no_mem_3:
+vfree(gt->maptrack);
+gt->maptrack = NULL;
+ no_mem_2:
+for ( i = 0;
+ i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+free_xenheap_page(gt->active[i]);
+xfree(gt->active);
+gt->active = NULL;
+ no_mem_1:
+gt->nr_grant_frames = 0;
+return -ENOMEM;
+}
+
/*
* Grow the grant table. The caller must hold the grant table's
* write lock before calling this function.
@@ -1665,6 +1737,12 @@ gnttab_grow_table(struct domain *d, unsigned int
req_nr_frames)
struct grant_table *gt = d->grant_table;
unsigned int i, j;
+if ( !gt->nr_grant_frames && grant_table_init(d) )
+{
+gdprintk(XENLOG_INFO, "Allocation failure in grant table init.\n");
+return 0;
+}
+
ASSERT(req_nr_frames <= max_grant_frames);
gdprintk(XENLOG_INFO,
@@ -3380,7
[Xen-devel] [PATCH v3 6/8] xen: add new domctl hypercall to set grant table resource limits
Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.
Signed-off-by: Juergen Gross
---
V3:
- rename *gnttbl* to *gnttab* (Paul Durrant)
---
tools/flask/policy/modules/dom0.te | 2 +-
xen/common/domctl.c | 6 ++
xen/common/grant_table.c| 26 ++
xen/include/public/domctl.h | 9 +
xen/include/xen/grant_table.h | 2 ++
xen/xsm/flask/hooks.c | 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
7 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/tools/flask/policy/modules/dom0.te
b/tools/flask/policy/modules/dom0.te
index 338caaf41e..1643b400f0 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -39,7 +39,7 @@ allow dom0_t dom0_t:domain {
};
allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
- get_vnumainfo psr_cmt_op psr_cat_op
+ get_vnumainfo psr_cmt_op psr_cat_op set_gnttab_limits
};
allow dom0_t dom0_t:resource { add remove };
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 42658e5744..58381f8fe9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1149,6 +1150,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
copyback = 1;
break;
+case XEN_DOMCTL_set_gnttab_limits:
+ret = grant_table_set_limits(d, op->u.set_gnttab_limits.grant_frames,
+ op->u.set_gnttab_limits.maptrack_frames);
+break;
+
default:
ret = arch_do_domctl(op, d, u_domctl);
break;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c00119f2fe..83f1a9dd34 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v)
v->maptrack_tail = MAPTRACK_TAIL;
}
+int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
+ unsigned int maptrack_frames)
+{
+struct grant_table *gt = d->grant_table;
+int ret = -EBUSY;
+
+if ( !gt )
+return -EEXIST;
+
+grant_write_lock(gt);
+
+if ( gt->nr_grant_frames )
+goto unlock;
+
+ret = 0;
+if ( grant_frames )
+gt->max_grant_frames = grant_frames;
+if ( maptrack_frames )
+gt->max_maptrack_frames = maptrack_frames;
+
+ unlock:
+grant_write_unlock(gt);
+
+return ret;
+}
+
#ifdef CONFIG_HAS_MEM_SHARING
int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
gfn_t *gfn, uint16_t *status)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 50ff58f5b9..f7e3509c27 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1163,6 +1163,13 @@ struct xen_domctl_psr_cat_op {
typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
+struct xen_domctl_set_gnttab_limits {
+uint32_t grant_frames; /* IN: if 0, dont change */
+uint32_t maptrack_frames; /* IN: if 0, dont change */
+};
+typedef struct xen_domctl_set_gnttab_limits xen_domctl_set_gnttab_limits_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_gnttab_limits_t);
+
struct xen_domctl {
uint32_t cmd;
#define XEN_DOMCTL_createdomain 1
@@ -1240,6 +1247,7 @@ struct xen_domctl {
#define XEN_DOMCTL_monitor_op77
#define XEN_DOMCTL_psr_cat_op78
#define XEN_DOMCTL_soft_reset79
+#define XEN_DOMCTL_set_gnttab_limits 80
#define XEN_DOMCTL_gdbsx_guestmemio1000
#define XEN_DOMCTL_gdbsx_pausevcpu 1001
#define XEN_DOMCTL_gdbsx_unpausevcpu 1002
@@ -1302,6 +1310,7 @@ struct xen_domctl {
struct xen_domctl_psr_cmt_oppsr_cmt_op;
struct xen_domctl_monitor_opmonitor_op;
struct xen_domctl_psr_cat_oppsr_cat_op;
+struct xen_domctl_set_gnttab_limits set_gnttab_limits;
uint8_t pad[128];
} u;
};
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 84a8d61616..dd9aa3b9ee 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -40,6 +40,8 @@ int grant_table_init(
void grant_table_destroy(
struct domain *d);
void grant_table_init_vcpu(struct vcpu *v);
+int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
+ unsigned int maptrack_frames);
/*
* Check if domain has active grants and log first 10 of them.
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 56dc5b0ab9..7b005af834 100644
--- a/xe
[Xen-devel] [PATCH v3 1/8] xen: move XENMAPSPACE_grant_table code into grant_table.c
The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
Switch to mfn_t in order to be more type safe.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
V3:
- update commit message
V2:
- rebased to staging
---
xen/arch/arm/mm.c | 36 --
xen/arch/x86/mm.c | 41 ++-
xen/common/grant_table.c | 38
xen/include/asm-arm/grant_table.h | 7 +++
xen/include/asm-x86/grant_table.h | 5 +
xen/include/xen/grant_table.h | 3 +++
6 files changed, 67 insertions(+), 63 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b39677eac9..3db0e3bdea 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1229,39 +1229,11 @@ int xenmem_add_to_physmap_one(
switch ( space )
{
case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
-(idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-if ( !mfn_eq(mfn, INVALID_MFN) )
-{
-d->arch.grant_table_gfn[idx] = gfn;
-
-t = p2m_ram_rw;
-}
-
-grant_write_unlock(d->grant_table);
+rc = gnttab_map_frame(d, idx, gfn, &mfn);
+if ( rc )
+return rc;
-if ( mfn_eq(mfn, INVALID_MFN) )
-return -EINVAL;
+t = p2m_ram_rw;
break;
case XENMAPSPACE_shared_info:
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index e5a029c9be..3d899e4a8e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4631,40 +4631,19 @@ int xenmem_add_to_physmap_one(
{
struct page_info *page = NULL;
unsigned long gfn = 0; /* gcc ... */
-unsigned long prev_mfn, mfn = 0, old_gpfn;
+unsigned long prev_mfn, old_gpfn;
int rc = 0;
+mfn_t mfn = INVALID_MFN;
p2m_type_t p2mt;
switch ( space )
{
case XENMAPSPACE_shared_info:
if ( idx == 0 )
-mfn = virt_to_mfn(d->shared_info);
+mfn = _mfn(virt_to_mfn(d->shared_info));
break;
case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
- (idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-grant_write_unlock(d->grant_table);
+gnttab_map_frame(d, idx, gpfn, &mfn);
break;
case XENMAPSPACE_gmfn_range:
case XENMAPSPACE_gmfn:
@@ -4681,8 +4660,8 @@ int xenmem_add_to_physmap_one(
}
if ( !get_page_from_mfn(_mfn(idx), d) )
break;
-mfn = idx;
-page = mfn_to_page(_mfn(mfn));
+mfn = _mfn(idx);
+page = mfn_to_page(mfn);
break;
}
case XENMAPSPACE_gmfn_foreign:
@@ -4691,7 +4670,7 @@ int xenmem_add_to_physmap_one(
break;
}
-if ( !paging_mode_translate(d) || (mfn == 0) )
+if ( !paging_mode_translate(d) || mfn_eq(mfn, INVALID_MFN) )
{
rc = -EINVAL;
goto put_both;
@@ -4715,16 +4694,16 @@ int xenmem_add_to_physmap_one(
goto put_both;
/* Unmap from old location, if any. */
-old_gpfn = get_gpfn_from_mfn(mfn);
+old_gpfn = get_gpfn_from_mfn(mfn_x(mfn));
ASSERT( old_gpfn != SHARED_M2P_ENTRY );
if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
ASSERT( old_gpfn == gfn );
if ( old_gpfn != INVALID_M2P_ENTRY )
-
[Xen-devel] [PATCH v3 7/8] libxc: add libxc support for setting grant table resource limits
Add a new libxc function xc_domain_set_gnttbl_limits() setting the
limits for the maximum numbers of grant table frames and maptrack
frames of a domain.
Signed-off-by: Juergen Gross
---
tools/libxc/include/xenctrl.h | 14 ++
tools/libxc/xc_domain.c | 13 +
2 files changed, 27 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 43151cb415..39b58cf5b7 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1064,6 +1064,20 @@ int xc_domain_set_virq_handler(xc_interface *xch,
uint32_t domid, int virq);
int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
uint32_t max_port);
+/**
+ * Set the maximum number of grant frames and/or maptrack frames a domain
+ * can have. Can only be used at domain setup time. A zero value means
+ * no change.
+ *
+ * @param xch a handle to an open hypervisor interface
+ * @param domid the domain id
+ * @param grant_frames max. number of grant frames
+ * @param maptrack_frames max. number of maptrack frames
+ */
+int xc_domain_set_gnttab_limits(xc_interface *xch, uint32_t domid,
+uint32_t grant_frames,
+uint32_t maptrack_frames);
+
/*
* CPUPOOL MANAGEMENT FUNCTIONS
*/
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8bab..e59665ff6e 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2268,6 +2268,19 @@ int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t
domid,
return do_domctl(xch, &domctl);
}
+int xc_domain_set_gnttab_limits(xc_interface *xch, uint32_t domid,
+uint32_t grant_frames,
+uint32_t maptrack_frames)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_set_gnttab_limits;
+domctl.domain = domid;
+domctl.u.set_gnttab_limits.grant_frames = grant_frames;
+domctl.u.set_gnttab_limits.maptrack_frames = maptrack_frames;
+return do_domctl(xch, &domctl);
+}
+
/* Plumbing Xen with vNUMA topology */
int xc_domain_setvnuma(xc_interface *xch,
uint32_t domid,
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/8] xen: clean up grant_table.h
Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
xen/common/grant_table.c | 83 --
xen/include/xen/grant_table.h | 84 ---
2 files changed, 81 insertions(+), 86 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 4c2e9e40a5..4520e36d90 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -40,6 +40,44 @@
#include
#include
+/* Per-domain grant information. */
+struct grant_table {
+/*
+ * Lock protecting updates to grant table state (version, active
+ * entry list, etc.)
+ */
+percpu_rwlock_t lock;
+/* Table size. Number of frames shared with guest */
+unsigned int nr_grant_frames;
+/* Shared grant table (see include/public/grant_table.h). */
+union {
+void **shared_raw;
+struct grant_entry_v1 **shared_v1;
+union grant_entry_v2 **shared_v2;
+};
+/* Number of grant status frames shared with guest (for version 2) */
+unsigned int nr_status_frames;
+/* State grant table (see include/public/grant_table.h). */
+grant_status_t **status;
+/* Active grant table. */
+struct active_grant_entry **active;
+/* Mapping tracking table per vcpu. */
+struct grant_mapping **maptrack;
+unsigned int maptrack_limit;
+/* Lock protecting the maptrack limit */
+spinlock_tmaptrack_lock;
+/*
+ * The defined versions are 1 and 2. Set to 0 if we don't know
+ * what version to use yet.
+ */
+unsigned gt_version;
+};
+
+#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
+/* Default maximum size of a grant table. [POLICY] */
+#define DEFAULT_MAX_NR_GRANT_FRAMES 32
+#endif
+
unsigned int __read_mostly max_grant_frames;
integer_param("gnttab_max_frames", max_grant_frames);
@@ -118,6 +156,18 @@ struct grant_mapping {
uint32_t pad; /* round size to a power of 2 */
};
+/* Number of grant table frames. Caller must hold d's grant table lock. */
+static inline unsigned int nr_grant_frames(const struct grant_table *gt)
+{
+return gt->nr_grant_frames;
+}
+
+/* Number of status grant table frames. Caller must hold d's gr. table lock.*/
+static inline unsigned int nr_status_frames(const struct grant_table *gt)
+{
+return gt->nr_status_frames;
+}
+
#define MAPTRACK_PER_PAGE (PAGE_SIZE / sizeof(struct grant_mapping))
#define maptrack_entry(t, e) \
((t)->maptrack[(e)/MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])
@@ -197,7 +247,27 @@ static inline void act_set_gfn(struct active_grant_entry
*act, gfn_t gfn)
#endif
}
-DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
+static DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
+
+static inline void grant_read_lock(struct grant_table *gt)
+{
+percpu_read_lock(grant_rwlock, >->lock);
+}
+
+static inline void grant_read_unlock(struct grant_table *gt)
+{
+percpu_read_unlock(grant_rwlock, >->lock);
+}
+
+static inline void grant_write_lock(struct grant_table *gt)
+{
+percpu_write_lock(grant_rwlock, >->lock);
+}
+
+static inline void grant_write_unlock(struct grant_table *gt)
+{
+percpu_write_unlock(grant_rwlock, >->lock);
+}
static inline void gnttab_flush_tlb(const struct domain *d)
{
@@ -250,6 +320,15 @@ static inline void active_entry_release(struct
active_grant_entry *act)
spin_unlock(&act->lock);
}
+#define GRANT_STATUS_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
+#define GRANT_PER_PAGE (PAGE_SIZE / sizeof(grant_entry_v2_t))
+/* Number of grant table status entries. Caller must hold d's gr. table lock.*/
+static inline unsigned int grant_to_status_frames(unsigned int grant_frames)
+{
+return (grant_frames * GRANT_PER_PAGE + GRANT_STATUS_PER_PAGE - 1) /
+GRANT_STATUS_PER_PAGE;
+}
+
/* Check if the page has been paged out, or needs unsharing.
If rc == GNTST_okay, *page contains the page struct with a ref taken.
Caller must do put_page(*page).
@@ -1580,7 +1659,7 @@ gnttab_unpopulate_status_frames(struct domain *d, struct
grant_table *gt)
* Grow the grant table. The caller must hold the grant table's
* write lock before calling this function.
*/
-int
+static int
gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
{
struct grant_table *gt = d->grant_table;
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 43ec6c4d80..43b07e60c5 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -29,66 +29,9 @@
#include
#include
-#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
-/* Default maximum size of a grant table. [POLICY] */
-#define DEFAULT_MAX_NR_GRANT_FRAMES 32
-#endif
/* The maximum size of a grant table. */
extern unsigne
[Xen-devel] [PATCH v3 0/8] xen: better grant v2 support
Currently Linux has no support for grant v2 as this would reduce the maximum number of active grants by a factor of 2 compared to v1, because the number of possible grants are limited by the allowed number of grant frames and grant entries of v2 need twice as much bytes as those of v1. Unfortunately grant v2 is the only way to support either guests with more than 16TB memory size or PV guests with memory above the 16TB border, as grant v1 limits the frame number to be 32 bits wide. In order to remove the disadvantage of grant v2 this patch series adds support for setting per-domain values regarding grant limits. Additionally the default limit of grant frames is doubled in case of hosts with memory above the 16TB border. Changes in V3: - patch 1: update commit message - patch 3: move call of grant_table_init() from gnttab_setup_table() to gnttab_grow_table() (Paul Durrant) - patch 4: correct error message (Paul Durrant) - patch 6: rename *gnttbl* to *gnttab* (Paul Durrant) Changes in V2: - add per-domain grant limits instead of different v1 and v2 limits - double default limit for huge hosts Juergen Gross (8): xen: move XENMAPSPACE_grant_table code into grant_table.c xen: clean up grant_table.h xen: delay allocation of grant table sub structures xen: make grant resource limits per domain xen: double default grant frame limit for huge hosts xen: add new domctl hypercall to set grant table resource limits libxc: add libxc support for setting grant table resource limits libxl: add libxl support for setting grant table resource limits docs/man/xl.cfg.pod.5.in| 15 ++ tools/flask/policy/modules/dom0.te | 2 +- tools/libxc/include/xenctrl.h | 14 ++ tools/libxc/xc_domain.c | 13 ++ tools/libxl/libxl.h | 6 + tools/libxl/libxl_dom.c | 8 + tools/libxl/libxl_types.idl | 3 + tools/xl/xl_parse.c | 5 + tools/xl/xl_sxp.c | 2 + xen/arch/arm/mm.c | 36 +--- xen/arch/x86/mm.c | 41 + xen/common/domain.c | 17 +- xen/common/domctl.c | 6 + xen/common/grant_table.c| 354 +++- xen/include/asm-arm/grant_table.h | 7 + xen/include/asm-x86/grant_table.h | 5 + xen/include/public/domctl.h | 9 + xen/include/xen/grant_table.h | 91 + xen/xsm/flask/hooks.c | 3 + xen/xsm/flask/policy/access_vectors | 2 + 20 files changed, 401 insertions(+), 238 deletions(-) -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/8] xen: make grant resource limits per domain
Instead of using the same global resource limits of grant tables (max.
number of grant frames, max. number of maptrack frames) for all domains
make these limits per domain. This will allow setting individual limits
in the future. For now initialize the per domain limits with the global
values.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
V3:
- correct error message (Paul Durrant)
---
xen/common/grant_table.c | 82 ++--
1 file changed, 45 insertions(+), 37 deletions(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 29e7fa539b..ff735a4b47 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -71,6 +71,9 @@ struct grant_table {
* what version to use yet.
*/
unsigned gt_version;
+/* Resource limits of the domain. */
+unsigned int max_grant_frames;
+unsigned int max_maptrack_frames;
};
#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
@@ -287,8 +290,8 @@ num_act_frames_from_sha_frames(const unsigned int num)
return DIV_ROUND_UP(num * sha_per_page, ACGNT_PER_PAGE);
}
-#define max_nr_active_grant_frames \
-num_act_frames_from_sha_frames(max_grant_frames)
+#define max_nr_active_grant_frames(gt) \
+num_act_frames_from_sha_frames(gt->max_grant_frames)
static inline unsigned int
nr_active_grant_frames(struct grant_table *gt)
@@ -526,7 +529,7 @@ get_maptrack_handle(
* out of memory, try stealing an entry from another VCPU (in case the
* guest isn't mapping across its VCPUs evenly).
*/
-if ( nr_maptrack_frames(lgt) < max_maptrack_frames )
+if ( nr_maptrack_frames(lgt) < lgt->max_maptrack_frames )
new_mt = alloc_xenheap_page();
if ( !new_mt )
@@ -1664,14 +1667,15 @@ grant_table_init(struct domain *d)
if ( gt->nr_grant_frames )
return 0;
-gt->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
+gt->nr_grant_frames = min_t(unsigned int, INITIAL_NR_GRANT_FRAMES,
+ gt->max_grant_frames);
/* Active grant table. */
if ( (gt->active = xzalloc_array(struct active_grant_entry *,
- max_nr_active_grant_frames)) == NULL )
+ max_nr_active_grant_frames(gt))) == NULL )
goto no_mem_1;
for ( i = 0;
- i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+ i < num_act_frames_from_sha_frames(gt->nr_grant_frames); i++ )
{
if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
goto no_mem_2;
@@ -1681,14 +1685,14 @@ grant_table_init(struct domain *d)
}
/* Tracking of mapped foreign frames table */
-gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
+gt->maptrack = vzalloc(gt->max_maptrack_frames * sizeof(*gt->maptrack));
if ( gt->maptrack == NULL )
goto no_mem_2;
/* Shared grant table. */
-if ( (gt->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL )
+if ( (gt->shared_raw = xzalloc_array(void *, gt->max_grant_frames)) ==
NULL )
goto no_mem_3;
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
{
if ( (gt->shared_raw[i] = alloc_xenheap_page()) == NULL )
goto no_mem_4;
@@ -1697,11 +1701,11 @@ grant_table_init(struct domain *d)
/* Status pages for grant table - for version 2 */
gt->status = xzalloc_array(grant_status_t *,
- grant_to_status_frames(max_grant_frames));
+ grant_to_status_frames(gt->max_grant_frames));
if ( gt->status == NULL )
goto no_mem_4;
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
gnttab_create_shared_page(d, gt, i);
gt->nr_status_frames = 0;
@@ -1709,7 +1713,7 @@ grant_table_init(struct domain *d)
return 0;
no_mem_4:
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
free_xenheap_page(gt->shared_raw[i]);
xfree(gt->shared_raw);
gt->shared_raw = NULL;
@@ -1718,7 +1722,7 @@ grant_table_init(struct domain *d)
gt->maptrack = NULL;
no_mem_2:
for ( i = 0;
- i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+ i < num_act_frames_from_sha_frames(gt->nr_grant_frames); i++ )
free_xenheap_page(gt->active[i]);
xfree(gt->active);
gt->active = NULL;
@@ -1743,7 +1747,7 @@ gnttab_grow_table(struct domain *d, unsigned int
req_nr_frames)
return 0;
}
-ASSERT(req_nr_frames <= max_grant_frames);
+ASSERT(req_nr_frames <= gt->max_grant_frames);
gdprintk(XENLOG_INFO,
"Expanding dom (%d) grant table from (%d) to (%d) frames.\n",
@@ -1815,15 +1819,6 @@ gnttab_setup_table(
if ( unlikely(
[Xen-devel] [PATCH v3 5/8] xen: double default grant frame limit for huge hosts
In case a system has memory above the 16TB boundary double the default
grant frame number limit per domain. This ensures a pv domain can still
establish the same number of grants even if it is required to use
version 2 grants which need twice the space of v1 grants.
Signed-off-by: Juergen Gross
Reviewed-by: Paul Durrant
---
xen/common/grant_table.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index ff735a4b47..c00119f2fe 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3824,8 +3824,15 @@ static int __init gnttab_usage_init(void)
{
BUILD_BUG_ON(DEFAULT_MAX_MAPTRACK_FRAMES < DEFAULT_MAX_NR_GRANT_FRAMES);
+/*
+ * In case grant v2 is required for pv domains to reference any possible
+ * memory page (i.e. memory is installed above 16TB boundary) double the
+ * grant frame limit. This will allow a guest using v2 grants without
+ * having to lower the number of usable grants.
+ */
if ( !max_grant_frames )
-max_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
+max_grant_frames = ((max_page >> 32) ? 2 : 1) *
+ DEFAULT_MAX_NR_GRANT_FRAMES;
if ( !max_maptrack_frames )
max_maptrack_frames = DEFAULT_MAX_MAPTRACK_FRAMES;
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function
On 09/06/2017 03:08 AM, Peter Zijlstra wrote: > Guys, please trim email. > > On Tue, Sep 05, 2017 at 10:31:46AM -0400, Waiman Long wrote: >> For clarification, I was actually asking if you consider just adding one >> more jump label to skip it for Xen/KVM instead of making >> virt_spin_lock() a pv-op. > I don't understand. What performance are you worried about. Native will > now do: "xor rax,rax; jnz some_cold_label" that's fairly trival code. It is not native that I am talking about. I am worry about VM with non-Xen/KVM hypervisor where virt_spin_lock() will actually be called. Now that function will become a callee-saved function call instead of being inlined into the native slowpath function. Cheers, Longman ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 02/13] libxl: add generic functions to get and free device list
On Tue, Sep 5, 2017 at 2:51 PM, Wei Liu wrote:
> On Tue, Jul 18, 2017 at 05:25:19PM +0300, Oleksandr Grytsov wrote:
>> From: Oleksandr Grytsov
>>
>> Add libxl__device_list and libxl__device_list_free
>> functions to handle device list using the device
>> framework.
>>
>> Signed-off-by: Oleksandr Grytsov
>> ---
>> tools/libxl/libxl_device.c | 66
>>
>> tools/libxl/libxl_internal.h | 8 ++
>> 2 files changed, 74 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
>> index 07165f0..f1d4848 100644
>> --- a/tools/libxl/libxl_device.c
>> +++ b/tools/libxl/libxl_device.c
>> @@ -1991,6 +1991,72 @@ out:
>> return rc;
>> }
>>
>> +void *libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
>> + uint32_t domid, const char* name, int *num)
>> +{
>> +void *r = NULL;
>> +void *list = NULL;
>> +void *item = NULL;
>> +char *libxl_path;
>> +char **dir = NULL;
>> +unsigned int ndirs = 0;
>> +int rc;
>> +
>> +*num = 0;
>> +
>> +libxl_path = GCSPRINTF("%s/device/%s",
>> + libxl__xs_libxl_path(gc, domid), name);
>> +
>> +dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, &ndirs);
>> +
>> +if (dir && ndirs) {
>> +list = libxl__malloc(NOGC, dt->dev_elem_size * ndirs);
>> +void *end = (uint8_t *)list + ndirs * dt->dev_elem_size;
>> +item = list;
>> +
>> +while (item < end) {
>> +dt->init(item);
>> +
>> +if (dt->from_xenstore) {
>> +char* device_libxl_path = GCSPRINTF("%s/%s", libxl_path,
>> *dir);
>> +rc = dt->from_xenstore(gc, device_libxl_path, atoi(*dir),
>> item);
>> +if (rc) goto out;
>> +}
>> +
>> +item = (uint8_t*)item + dt->dev_elem_size;
>
> Space before *.
>
>> +++dir;
>> +}
>> +}
>> +
>> +*num = ndirs;
>> +r = list;
>> +list = NULL;
>> +
>> +out:
>> +
>> +if (list) {
>> +*num = 0;
>> +while(item >= list) {
>
> Space after while, but ...
>
>> +dt->dispose(item);
>> +item = (uint8_t*)item - dt->dev_elem_size;
>> +}
>> +free(list);
>
> You should be able to use libxl__device_list_free here.
Good catch. I will use list_free here. This requires slight changes in
above loop:
i need to count initialized elements in order to pass it to list_free.
>
>> +}
>> +
>> +return r;
>> +}
>> +
>> +void libxl__device_list_free(const struct libxl_device_type *dt,
>> + void *list, int num)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < num; i++)
>> +dt->dispose((uint8_t*)list + i * dt->dev_elem_size);
>> +
>> +free(list);
>> +}
>> +
>> /*
>> * Local variables:
>> * mode: C
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 075dfe3..271ac89 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -3506,6 +3506,7 @@ struct libxl_device_type {
>> int (*dm_needed)(void *, unsigned);
>> void (*update_config)(libxl__gc *, void *, void *);
>> int (*update_devid)(libxl__gc *, uint32_t, void *);
>> +int (*from_xenstore)(libxl__gc *, const char *, libxl_devid, void *);
>> int (*set_xenstore_config)(libxl__gc *, uint32_t, void *, flexarray_t *,
>> flexarray_t *, flexarray_t *);
>> };
>> @@ -4386,6 +4387,13 @@ void libxl__device_add_async(libxl__egc *egc,
>> uint32_t domid,
>> int libxl__device_add(libxl__gc *gc, uint32_t domid,
>>const struct libxl_device_type *dt, void *type);
>>
>> +/* Caller is responsible for freeing the memory by calling
>> + * libxl__device_list_free
>> + */
>> +void* libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
>> + uint32_t domid, const char* name, int *num);
>> +void libxl__device_list_free(const struct libxl_device_type *dt,
>> + void *list, int num);
>> #endif
>>
>> /*
>> --
>> 2.7.4
>>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 113074: trouble: broken/pass
flight 113074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113074/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-arm64-arm64-xl-xsm broken
build-arm64-pvopsbroken
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hosts-allocate broken like 113039
build-arm64-pvops 3 capture-logsbroken like 113039
build-arm64 2 hosts-allocate broken like 113039
build-arm64 3 capture-logsbroken like 113039
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
version targeted for testing:
xen 0829a6bdbdc6b79990bd0668e847275b6a2717e5
baseline version:
xen 6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
Last test of basis 113039 2017-09-04 15:02:08 Z1 days
Failing since113052 2017-09-05 13:01:29 Z0 days 10 attempts
Testing same since 113074 2017-09-06 11:14:03 Z0 days1 attempts
People who touched revisions under test:
Alexandru Isaila
Andrew Cooper
Jan Beulich
Olaf Hering
Tamas K Lengyel
Wei Liu
jobs:
build-amd64 pass
build-arm64 broken
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsbroken
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs
Not pushing.
commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5
Author: Jan Beulich
Date: Wed Sep 6 12:32:00 2017 +0200
x86: introduce and use setup_force_cpu_cap()
For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse of setup_clear_cpu_cap() instead, but let clearing of features
overrule forced setting of them.
XEN_SMAP being wrong post-boot is a problem specifically for live
patching, as a live patch may need alternative instruction patching
keyed off of that feature flag.
Reported-by: Sarah Newman
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
commit fd903a35daf3e7e6bfa782b18dfd43746f940bed
Author: Andrew Cooper
Date: Tue Sep 5 17:54:45 2017 +0100
x86/traps: Fix show_page_walk() to avoid printing trailing whitespace
This moves the L2 line to be consistent with the L3 line.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
commit 12257de3cfff9b4ffa0b7379ef82c9ad7c8dbec9
Author: Andrew Cooper
Date: Fri Sep 1 17:05:21 2017 +
xen: Drop asmlinkage everywhere
asmlinkage is defined as nothing on all architectures, and not used
consistently anywhere, even in common code. Remove it all.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Stefano Stabellini
commit 150dd3946c521a9257c4dd97e6190c6b0df680d3
Author: Olaf Hering
Date: Tue Sep 5 11:03:38 2017 +0200
libxc/bitops: correct comment for bitmap_size
The returned value represents now units of bytes instead of longs.
Fixes commit 11d0044a16 ("tools/libxc: Modify bitmap operations to
ta
Re: [Xen-devel] [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest
On Wed, Sep 06, Andrew Cooper wrote: > If a PVH guest has got MTRRs disabled, then it genuinely can run on an > unshattered 1G superpage at 0. Ok, the code will detect the holes and will release memory as needed. I will drop these two lines. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest
On Wed, Sep 06, Andrew Cooper wrote: > I still fail to understand why you need the bitmaps at all? You can > calculate everything you need from the pfn list alone, which will also > let you spot the presence or absence of the VGA hole. These bitmaps track if a range has been allocated as superpage or not. If there is a given pfn within a range of either 1G or 2M there might be double allocation of a 1G or 2M page. This is not related to the VGA hole. These two lines are just hints that in this range no superpage can be allocated. > You need to track which pfns you've see so far in the stream, and which > pfns have been populated. When you find holes in the pfns in the > stream, you need to undo the prospective superpage allocation. Unless > I've missed something? This is whats happening, holes will be created as soon as they are seen in the stream. > Also, please take care to use 2M decrease reservations wherever > possible, or you will end up shattering the host superpage as part of > trying to remove the memory. This is what Wei suggested, build a list of pfns instead of releasing each pfn individually. I think with this new code it should be possible to decrease in 2M steps as needed. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest
On 06/09/17 13:17, Olaf Hering wrote: > On Wed, Sep 06, Andrew Cooper wrote: > >> On 01/09/17 17:08, Olaf Hering wrote: >>> +/* No superpage in 1st 2MB due to VGA hole */ >>> +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_1g); >>> +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_2m); >> This is false for PVH guests. > How can I detect a PVH guest? You (hopefully) can't, and it would be a layering violation if you could. The exact set of emulation available to/used by a guest is not relevant to how we move its memory. If a PVH guest has got MTRRs disabled, then it genuinely can run on an unshattered 1G superpage at 0. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest
On Wed, Sep 06, Andrew Cooper wrote: > On 01/09/17 17:08, Olaf Hering wrote: > > +/* No superpage in 1st 2MB due to VGA hole */ > > +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_1g); > > +xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_2m); > This is false for PVH guests. How can I detect a PVH guest? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 2/3] tools/libxc: add API for bitmap access for restore
On Wed, Sep 06, Andrew Cooper wrote: > On 01/09/17 17:08, Olaf Hering wrote: > > +static inline bool pfn_is_populated(struct xc_sr_context *ctx, xen_pfn_t > > pfn) > > +static inline int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t > > pfn) > Why are these moved? They are still restore specific. There is no tools/libxc/xc_sr_restore.h, should I create one? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
