[Xen-devel] [xen-4.10-testing test] 122592: regressions - trouble: blocked/broken/fail/pass
flight 122592 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122592/ 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-xsm 4 host-install(4)broken REGR. vs. 122490 build-arm64 5 host-build-prep fail REGR. vs. 122490 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 test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 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-armhf-armhf-libvirt-xsm 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 99e50001bea6f3d777b86bbb9bb41ef66ba47974 baseline version: xen c30ab3d97c8ff0d2ed8948dd013737befc7a2223 Last test of basis 122490 2018-04-28 06:03:56 Z6 days Testing same since 122560 2018-05-02 10:07:00 Z2 days3 attempts People who touched revisions under test: Jan Beulichjobs: build-amd64-xsm pass build-arm64-xsm
[Xen-devel] [xen-unstable-smoke test] 122607: trouble: blocked/broken/pass
flight 122607 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122607/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 122587 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e38e285a51c805cfeee4693962df23e39b3c3bd7 baseline version: xen 4611f529c0e39493a3945641cc161967a864d6b5 Last test of basis 122587 2018-05-03 16:00:26 Z1 days Testing same since 122602 2018-05-04 18:01:13 Z0 days4 attempts People who touched revisions under test: Jan BeulichJuergen Gross Wei Liu jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked 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-xsm broken broken-step build-arm64-xsm host-install(4) Not pushing. commit e38e285a51c805cfeee4693962df23e39b3c3bd7 Author: Wei Liu Date: Fri May 4 16:08:04 2018 +0100 docs: fix xpti command line option doc Signed-off-by: Wei Liu Acked-by: Jan Beulich commit 5c81d260c244026ea74632faa3c6d0a00cc76469 Author: Juergen Gross Date: Thu Apr 26 13:33:18 2018 +0200 xen/x86: use PCID feature Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode - hypervisor active and guest in user mode (XPTI only) - hypervisor active and guest in kernel mode (XPTI only) We use PCID only if PCID _and_ INVPCID are supported. With PCID in use we disable global pages in cr4. A command line parameter controls in which cases PCID is being used. As the non-XPTI case has shown not to perform better with PCID at least on some machines the default is to use PCID only for domains subject to XPTI. With PCID enabled we always disable global pages. This avoids having to either flush the complete TLB or do a cycle through all PCID values when invalidating a single global page. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 1a32c9868711b4ee883ebb6f8807e08d70a920be Author: Juergen Gross Date: Thu Apr 26 13:33:17 2018 +0200 xen/x86: add some cr3 helpers Add some helper macros to access the address and pcid parts of cr3. Use those helpers where appropriate. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d Author: Juergen Gross Date: Thu Apr 26 13:33:16 2018 +0200 xen/x86: convert pv_guest_cr4_to_real_cr4() to a function pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert it from a macro to an ordinary function. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 065a499f78d5b644fa586e3e66f88949821e4f8c Author: Juergen Gross Date: Thu Apr 26
[Xen-devel] [xen-4.7-testing test] 122589: trouble: broken/fail/pass
flight 122589 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122589/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm broken in 122569 test-amd64-amd64-xl-shadow broken in 122569 test-amd64-i386-libvirt-xsm broken in 122569 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken in 122569 test-amd64-amd64-xl-qcow2broken in 122569 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 4 host-install(4) broken in 122569 pass in 122589 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken in 122569 pass in 122589 test-amd64-amd64-xl-shadow 4 host-install(4) broken in 122569 pass in 122589 test-amd64-i386-libvirt-xsm 4 host-install(4) broken in 122569 pass in 122589 test-amd64-amd64-xl-qcow24 host-install(4) broken in 122569 pass in 122589 test-amd64-amd64-xl-qemuu-debianhvm-amd64 4 host-install(4) broken pass in 122569 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122569 pass in 122589 test-armhf-armhf-xl-multivcpu 6 xen-install fail in 122569 pass in 122589 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 122569 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122569 like 122131 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122131 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 122131 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122131 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122131 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-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-arm64-arm64-xl 13 migrate-support-checkfail never pass
[Xen-devel] [xen-unstable baseline-only test] 74673: regressions - FAIL
This run is configured for baseline tests only. flight 74673 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 74668 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74668 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74668 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74668 test-armhf-armhf-libvirt 12 guest-start fail like 74668 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74668 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74668 test-armhf-armhf-xl-midway 12 guest-start fail like 74668 test-armhf-armhf-xl-xsm 12 guest-start fail like 74668 test-armhf-armhf-xl 12 guest-start fail like 74668 test-armhf-armhf-xl-credit2 12 guest-start fail like 74668 test-armhf-armhf-xl-rtds 12 guest-start fail like 74668 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74668 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74668 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail like 74668 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74668 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74668 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 74668 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 74668 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install 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-xl-pvhv2-amd 12 guest-start fail 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop 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 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0306a1311d02ea52b4a9a9bc339f8bab9354c5e3 baseline version: xen eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897 Last test of basis74668 2018-05-03 12:22:29 Z1 days Testing same since74673 2018-05-04 13:19:07 Z0 days1 attempts People who touched revisions under test: Andrew CooperBrian Woods Ian Jackson Jan Beulich Lars Kurth Stewart Hildebrand Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1
[Xen-devel] [xen-unstable-smoke test] 122604: trouble: blocked/broken/pass
flight 122604 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122604/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 host-install(4)broken REGR. vs. 122587 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e38e285a51c805cfeee4693962df23e39b3c3bd7 baseline version: xen 4611f529c0e39493a3945641cc161967a864d6b5 Last test of basis 122587 2018-05-03 16:00:26 Z1 days Testing same since 122602 2018-05-04 18:01:13 Z0 days2 attempts People who touched revisions under test: Jan BeulichJuergen Gross Wei Liu jobs: build-arm64-xsm broken build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm blocked 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-xsm broken broken-step build-arm64-xsm host-install(4) Not pushing. commit e38e285a51c805cfeee4693962df23e39b3c3bd7 Author: Wei Liu Date: Fri May 4 16:08:04 2018 +0100 docs: fix xpti command line option doc Signed-off-by: Wei Liu Acked-by: Jan Beulich commit 5c81d260c244026ea74632faa3c6d0a00cc76469 Author: Juergen Gross Date: Thu Apr 26 13:33:18 2018 +0200 xen/x86: use PCID feature Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode - hypervisor active and guest in user mode (XPTI only) - hypervisor active and guest in kernel mode (XPTI only) We use PCID only if PCID _and_ INVPCID are supported. With PCID in use we disable global pages in cr4. A command line parameter controls in which cases PCID is being used. As the non-XPTI case has shown not to perform better with PCID at least on some machines the default is to use PCID only for domains subject to XPTI. With PCID enabled we always disable global pages. This avoids having to either flush the complete TLB or do a cycle through all PCID values when invalidating a single global page. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 1a32c9868711b4ee883ebb6f8807e08d70a920be Author: Juergen Gross Date: Thu Apr 26 13:33:17 2018 +0200 xen/x86: add some cr3 helpers Add some helper macros to access the address and pcid parts of cr3. Use those helpers where appropriate. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d Author: Juergen Gross Date: Thu Apr 26 13:33:16 2018 +0200 xen/x86: convert pv_guest_cr4_to_real_cr4() to a function pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert it from a macro to an ordinary function. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 065a499f78d5b644fa586e3e66f88949821e4f8c Author: Juergen Gross Date: Thu Apr 26
Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?
On Fri, May 04, 2018 at 06:13:25PM -0400, Rich Persaud wrote: > > On May 1, 2018, at 08:53, Jason Cooperwrote: > > > > add the link to xen-users thread of me talking to myself. :-)) > > > >> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote: > >> When I was first digging into this, I started a thread on xen-users [1], > >> I've attached my xl-reboot.sh script here so you can see exactly what > >> I'm attempting to do: > > > > [1] https://marc.info/?l=xen-users=152389443206023=2 > > You may want to look at the code (toolstack and/or frontend-backend drivers) > for Qubes and OpenXT, both of which use network driver domains and support > wired/wireless networks. > > Operational restart of a measured, non-persistent driver domain (instead of > host) is a benefit of Xen disaggregation architectures. In Qubes, on backend restart, we do equivalent of xl network-detach && xl network-attach (as you do in xl-reboot.sh). xl itself doesn't provide any place to plug such script, but we use libvirt which provide events. Also, we have full control over domain config (libvirt XML), so don't need to extract vif list from xenstore... The problem you describe looks related to https://lkml.org/lkml/2018/2/28/289, but fix is included in 4.16... There was also related libxl patch: https://xen.markmail.org/thread/6qbgmwyjqsshjus7 (but it applies to the case where you first shutdown backend and only then do xl network-detach) Do you have xl devd running in your driver domain? Without that xl network-attach wont work (AFAIR udev isn't used here anymore). Also note that backend shutdown/restart/crash was a source of many problems in frontend kernel and toolstack in the past. Even simple dynamic network-attach/detach sometimes is problematic for the frontend. Links: https://github.com/QubesOS/qubes-issues/issues/3657 (frontend kernel problem) https://github.com/QubesOS/qubes-issues/issues/1426 (toolstack problem, + libvirt) https://github.com/QubesOS/qubes-issues/issues/975 (frontend kernel problem) -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?
> On May 1, 2018, at 08:53, Jason Cooperwrote: > > add the link to xen-users thread of me talking to myself. :-)) > >> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote: >> When I was first digging into this, I started a thread on xen-users [1], >> I've attached my xl-reboot.sh script here so you can see exactly what >> I'm attempting to do: > > [1] https://marc.info/?l=xen-users=152389443206023=2 You may want to look at the code (toolstack and/or frontend-backend drivers) for Qubes and OpenXT, both of which use network driver domains and support wired/wireless networks. Operational restart of a measured, non-persistent driver domain (instead of host) is a benefit of Xen disaggregation architectures. Rich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42
CC'ing xen-devel in case Xen maintainers have a need for something that will that conflict with this proposal wrt supported build platforms. On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote: > This short series is a followup the discussions around min glib version > when Olaf found we had accidentally increased the min glib by using a > newer function: > > https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02699.html > > Some key points from that thread > > - Although we have a docker job that tries to test the min glib > version is adhered to, that's only run post-build, not by Peter's > merge tests, nor by patchew. > > - The docker min glib test failed to detect the problem anyway > because RHEL had backported the symbol in question. > > - The docker min glib test only builds with certain configure > options so isn't foolproof. > > - The modern distros we implicitly care about have way newer glib > than 2.22 > > - Peter's OS-X build host previously had 2.22, but after switching > from fink to homebrew now has 2.56 > > - I suggested following libvirt's lead in writing a policy for how > we pick supported OS targets to inform maintainers when min versions > can be increased. > > This series writes such a document largely based on one I wrote for > libvirt with a few changes, largely around OS-X and *BSD. Note it > is not meant to be an exhaustive list of distros we'll build on, rather > a representative selection, so that we can identify the range of 3rd > party library versions we need to care about. So if your favourite > distro is missing, dont be alarmed, as it probably ships similar > vintage software to one of those listed - if not feel free to suggest > additions. > > Based on that doc and https://repology.org/metapackage/glib/versions, > I identified that we could feasibly set min glib to 2.42. Note that > this would be dropping RHEL-6 as a build host (RHEL-6.0 came out in > 2010 so that's reasonable to drop IMHO). It would still cover 2 major > Debian versions and 2 most recent Ubuntu LTS (16.04, 18.04, but *not* > 14.04). This min glib lets us remove almost all our compat code. > > Most interestingly, thanks tothe new min version being greater than > 2.32, we can now use GLIB_VERSION_MAX_ALLOWED to validate the correct > API usage according to our min version: > > > https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS > > This means that *all* our CI jobs & developer builds will be enforcing > the min version, so means very many more conditionally built features > will get their build validated against min glib version. This would > do a much better job of catching mistakes than our min-glib docker > job, making that obsolete. > > Daniel P. Berrangé (3): > qemu-doc: provide details of supported build platforms > glib: bump min required glib library version to 2.42 > glib: enforce the minimum required version and warn about old APIs > > configure | 6 +- > include/glib-compat.h | 362 > ++-- > qemu-doc.texi | 68 + > tests/test-qmp-event.c | 2 +- > tests/tpm-emu.h | 4 +- > tests/vhost-user-test.c | 4 +- > trace/simple.c | 6 +- > 7 files changed, 123 insertions(+), 329 deletions(-) > > -- > 2.14.3 > Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122602: trouble: broken/pass
flight 122602 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122602/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm broken test-arm64-arm64-xl-xsm 4 host-install(4)broken REGR. vs. 122587 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen e38e285a51c805cfeee4693962df23e39b3c3bd7 baseline version: xen 4611f529c0e39493a3945641cc161967a864d6b5 Last test of basis 122587 2018-05-03 16:00:26 Z1 days Testing same since 122602 2018-05-04 18:01:13 Z0 days1 attempts People who touched revisions under test: Jan BeulichJuergen Gross Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm 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 test-arm64-arm64-xl-xsm broken broken-step test-arm64-arm64-xl-xsm host-install(4) Not pushing. commit e38e285a51c805cfeee4693962df23e39b3c3bd7 Author: Wei Liu Date: Fri May 4 16:08:04 2018 +0100 docs: fix xpti command line option doc Signed-off-by: Wei Liu Acked-by: Jan Beulich commit 5c81d260c244026ea74632faa3c6d0a00cc76469 Author: Juergen Gross Date: Thu Apr 26 13:33:18 2018 +0200 xen/x86: use PCID feature Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode - hypervisor active and guest in user mode (XPTI only) - hypervisor active and guest in kernel mode (XPTI only) We use PCID only if PCID _and_ INVPCID are supported. With PCID in use we disable global pages in cr4. A command line parameter controls in which cases PCID is being used. As the non-XPTI case has shown not to perform better with PCID at least on some machines the default is to use PCID only for domains subject to XPTI. With PCID enabled we always disable global pages. This avoids having to either flush the complete TLB or do a cycle through all PCID values when invalidating a single global page. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 1a32c9868711b4ee883ebb6f8807e08d70a920be Author: Juergen Gross Date: Thu Apr 26 13:33:17 2018 +0200 xen/x86: add some cr3 helpers Add some helper macros to access the address and pcid parts of cr3. Use those helpers where appropriate. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d Author: Juergen Gross Date: Thu Apr 26 13:33:16 2018 +0200 xen/x86: convert pv_guest_cr4_to_real_cr4() to a function pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert it from a macro to an ordinary function. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich commit 065a499f78d5b644fa586e3e66f88949821e4f8c Author: Juergen Gross Date: Thu Apr 26 13:33:15 2018 +0200 xen/x86: use flag byte for
[Xen-devel] [PATCH v3 1/8] xen_backend: add grant table helpers
This patch adds grant table helper functions to the xen_backend code to localize error reporting and use of xen_domid. The patch also defers the call to xengnttab_open() until just before the initialise method in XenDevOps is invoked. This method is responsible for mapping the shared ring. No prior method requires access to the grant table. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 123 ++- include/hw/xen/xen_backend.h | 33 2 files changed, 144 insertions(+), 12 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 7445b50..50412d6 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -106,6 +106,103 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state) return 0; } +void xen_be_set_max_grant_refs(struct XenDevice *xendev, + unsigned int nr_refs) +{ +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +if (xengnttab_set_max_grants(xendev->gnttabdev, nr_refs)) { +xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n", + strerror(errno)); +} +} + +void *xen_be_map_grant_refs(struct XenDevice *xendev, uint32_t *refs, +unsigned int nr_refs, int prot) +{ +void *ptr; + +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +ptr = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_refs, + xen_domid, refs, prot); +if (!ptr) { +xen_pv_printf(xendev, 0, + "xengnttab_map_domain_grant_refs failed: %s\n", + strerror(errno)); +} + +return ptr; +} + +void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr, + unsigned int nr_refs) +{ +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +if (xengnttab_unmap(xendev->gnttabdev, ptr, nr_refs)) { +xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n", + strerror(errno)); +} +} + +int xen_be_copy_grant_refs(struct XenDevice *xendev, + bool to_domain, + XenGrantCopySegment segs[], + unsigned int nr_segs) +{ +xengnttab_grant_copy_segment_t *xengnttab_segs; +unsigned int i; +int rc; + +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs); + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; +xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i]; + +if (to_domain) { +xengnttab_seg->flags = GNTCOPY_dest_gref; +xengnttab_seg->dest.foreign.domid = xen_domid; +xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref; +xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset; +xengnttab_seg->source.virt = seg->source.virt; +} else { +xengnttab_seg->flags = GNTCOPY_source_gref; +xengnttab_seg->source.foreign.domid = xen_domid; +xengnttab_seg->source.foreign.ref = seg->source.foreign.ref; +xengnttab_seg->source.foreign.offset = +seg->source.foreign.offset; +xengnttab_seg->dest.virt = seg->dest.virt; +} + +xengnttab_seg->len = seg->len; +} + +rc = xengnttab_grant_copy(xendev->gnttabdev, nr_segs, xengnttab_segs); + +if (rc) { +xen_pv_printf(xendev, 0, "xengnttab_copy failed: %s\n", + strerror(errno)); +} + +for (i = 0; i < nr_segs; i++) { +xengnttab_grant_copy_segment_t *xengnttab_seg = +_segs[i]; + +if (xengnttab_seg->status != GNTST_okay) { +xen_pv_printf(xendev, 0, "segment[%u] status: %d\n", i, + xengnttab_seg->status); +rc = -1; +} +} + +g_free(xengnttab_segs); +return rc; +} + /* * get xen backend device, allocate a new one if it doesn't exist. */ @@ -149,18 +246,6 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, } qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev)); -if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) { -xendev->gnttabdev = xengnttab_open(NULL, 0); -if (xendev->gnttabdev == NULL) { -xen_pv_printf(NULL, 0, "can't open gnttab device\n"); -xenevtchn_close(xendev->evtchndev); -qdev_unplug(DEVICE(xendev), NULL); -return NULL; -} -} else { -xendev->gnttabdev = NULL; -} - xen_pv_insert_xendev(xendev); if (xendev->ops->alloc) { @@ -322,6 +407,16 @@ static int xen_be_try_initialise(struct XenDevice *xendev) } } +
[Xen-devel] [PATCH v3 5/8] xen_disk: remove use of grant map/unmap
Now that the (native or emulated) xen_be_copy_grant_refs() helper is always available, the xen_disk code can be significantly simplified by removing direct use of grant map and unmap operations. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - Squashed in separate patche removing persistent grant use - Re-based --- hw/block/xen_disk.c | 370 1 file changed, 25 insertions(+), 345 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 66ed2b7..28be8b6 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -36,27 +36,9 @@ /* - */ -static int batch_maps = 0; - -/* - */ - #define BLOCK_SIZE 512 #define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2) -struct PersistentGrant { -void *page; -struct XenBlkDev *blkdev; -}; - -typedef struct PersistentGrant PersistentGrant; - -struct PersistentRegion { -void *addr; -int num; -}; - -typedef struct PersistentRegion PersistentRegion; - struct ioreq { blkif_request_t req; int16_t status; @@ -65,14 +47,11 @@ struct ioreq { off_t start; QEMUIOVectorv; int presync; -uint8_t mapped; /* grant mapping */ uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -int prot; void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; void*pages; -int num_unmap; /* aio status */ int aio_inflight; @@ -103,7 +82,6 @@ struct XenBlkDev { int protocol; blkif_back_rings_t rings; int more_work; -int cnt_map; /* request lists */ QLIST_HEAD(inflight_head, ioreq) inflight; @@ -114,13 +92,7 @@ struct XenBlkDev { int requests_finished; unsigned intmax_requests; -/* Persistent grants extension */ gbooleanfeature_discard; -gbooleanfeature_persistent; -GTree *persistent_gnts; -GSList *persistent_regions; -unsigned intpersistent_gnt_count; -unsigned intmax_grants; /* qemu block driver */ DriveInfo *dinfo; @@ -139,10 +111,8 @@ static void ioreq_reset(struct ioreq *ioreq) ioreq->status = 0; ioreq->start = 0; ioreq->presync = 0; -ioreq->mapped = 0; memset(ioreq->refs, 0, sizeof(ioreq->refs)); -ioreq->prot = 0; memset(ioreq->page, 0, sizeof(ioreq->page)); ioreq->pages = NULL; @@ -156,37 +126,6 @@ static void ioreq_reset(struct ioreq *ioreq) qemu_iovec_reset(>v); } -static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data) -{ -uint ua = GPOINTER_TO_UINT(a); -uint ub = GPOINTER_TO_UINT(b); -return (ua > ub) - (ua < ub); -} - -static void destroy_grant(gpointer pgnt) -{ -PersistentGrant *grant = pgnt; -struct XenBlkDev *blkdev = grant->blkdev; -struct XenDevice *xendev = >xendev; - -xen_be_unmap_grant_ref(xendev, grant->page); -grant->blkdev->persistent_gnt_count--; -xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page); -g_free(grant); -} - -static void remove_persistent_region(gpointer data, gpointer dev) -{ -PersistentRegion *region = data; -struct XenBlkDev *blkdev = dev; -struct XenDevice *xendev = >xendev; - -xen_be_unmap_grant_refs(xendev, region->addr, region->num); -xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n", - region->addr, region->num); -g_free(region); -} - static struct ioreq *ioreq_start(struct XenBlkDev *blkdev) { struct ioreq *ioreq = NULL; @@ -254,7 +193,6 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number); switch (ioreq->req.operation) { case BLKIF_OP_READ: -ioreq->prot = PROT_WRITE; /* to memory */ break; case BLKIF_OP_FLUSH_DISKCACHE: ioreq->presync = 1; @@ -263,7 +201,6 @@ static int ioreq_parse(struct ioreq *ioreq) } /* fall through */ case BLKIF_OP_WRITE: -ioreq->prot = PROT_READ; /* from memory */ break; case BLKIF_OP_DISCARD: return 0; @@ -310,173 +247,6 @@ err: return -1; } -static void ioreq_unmap(struct ioreq *ioreq) -{ -struct XenBlkDev *blkdev = ioreq->blkdev; -struct XenDevice *xendev = >xendev; -int i; - -if (ioreq->num_unmap == 0 || ioreq->mapped == 0) { -return; -} -if (batch_maps) { -if (!ioreq->pages) { -return; -} -
[Xen-devel] [PATCH v3 6/8] xen_backend: make the xen_feature_grant_copy flag private
There is no longer any use of this flag outside of the xen_backend code. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 2 +- include/hw/xen/xen_backend.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 3c3fc2c..9a8e877 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -44,9 +44,9 @@ BusState *xen_sysbus; /* public */ struct xs_handle *xenstore = NULL; const char *xen_protocol; -bool xen_feature_grant_copy; /* private */ +static bool xen_feature_grant_copy; static int debug; int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const char *val) diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h index 29bf1c3..9c17fdd 100644 --- a/include/hw/xen/xen_backend.h +++ b/include/hw/xen/xen_backend.h @@ -16,7 +16,6 @@ /* variables */ extern struct xs_handle *xenstore; extern const char *xen_protocol; -extern bool xen_feature_grant_copy; extern DeviceState *xen_sysdev; extern BusState *xen_sysbus; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/8] xen_disk: legacy code removal and cleanup
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying a significant amount of code purely to remain compatible with older versions of Xen. As can be inferred from the diff stats below, removing this support for older versions of Xen from QEMU reduces the size of the xen_disk source by around 320 lines (~25%). This versionseries maintains compatibility with older Xen, and OS not supporting the grant copy operation, by adding an emulation of it into the xen_backend code. Thus xen_disk can be simplified without regressing support for any environment. This series also performs general cleanup of the code by introducing and consistently using helper functions for calling into libxenttab. Paul Durrant (8): xen_backend: add grant table helpers xen_disk: remove open-coded use of libxengnttab xen: remove other open-coded use of libxengnttab xen_backend: add an emulation of grant copy xen_disk: remove use of grant map/unmap xen_backend: make the xen_feature_grant_copy flag private xen_disk: use a single entry iovec xen_disk: be consistent with use of xendev and blkdev->xendev hw/9pfs/xen-9p-backend.c | 32 ++- hw/block/xen_disk.c | 614 +++ hw/char/xen_console.c| 9 +- hw/net/xen_nic.c | 34 ++- hw/usb/xen-usb.c | 37 ++- hw/xen/xen_backend.c | 178 - include/hw/xen/xen_backend.h | 34 ++- 7 files changed, 351 insertions(+), 587 deletions(-) --- Cc: Anthony PerardCc: Gerd Hoffmann Cc: Greg Kurz Cc: Jason Wang Cc: Kevin Wolf Cc: Max Reitz Cc: Paolo Bonzini Cc: Stefano Stabellini -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/8] xen_disk: remove open-coded use of libxengnttab
Now that helpers are present in xen_backend, this patch removes open-coded calls to libxengnttab from the xen_disk code. This patch also fixes one whitspace error in the assignment of the XenDevOps initialise method. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - New in v2 --- hw/block/xen_disk.c | 122 ++-- 1 file changed, 32 insertions(+), 90 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index f74fcd4..66ed2b7 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -68,7 +68,6 @@ struct ioreq { uint8_t mapped; /* grant mapping */ -uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; int prot; void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -142,7 +141,6 @@ static void ioreq_reset(struct ioreq *ioreq) ioreq->presync = 0; ioreq->mapped = 0; -memset(ioreq->domids, 0, sizeof(ioreq->domids)); memset(ioreq->refs, 0, sizeof(ioreq->refs)); ioreq->prot = 0; memset(ioreq->page, 0, sizeof(ioreq->page)); @@ -168,16 +166,12 @@ static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data) static void destroy_grant(gpointer pgnt) { PersistentGrant *grant = pgnt; -xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev; +struct XenBlkDev *blkdev = grant->blkdev; +struct XenDevice *xendev = >xendev; -if (xengnttab_unmap(gnt, grant->page, 1) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_ref(xendev, grant->page); grant->blkdev->persistent_gnt_count--; -xen_pv_printf(>blkdev->xendev, 3, - "unmapped grant %p\n", grant->page); +xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page); g_free(grant); } @@ -185,15 +179,10 @@ static void remove_persistent_region(gpointer data, gpointer dev) { PersistentRegion *region = data; struct XenBlkDev *blkdev = dev; -xengnttab_handle *gnt = blkdev->xendev.gnttabdev; +struct XenDevice *xendev = >xendev; -if (xengnttab_unmap(gnt, region->addr, region->num) != 0) { -xen_pv_printf(>xendev, 0, - "xengnttab_unmap region %p failed: %s\n", - region->addr, strerror(errno)); -} -xen_pv_printf(>xendev, 3, - "unmapped grant region %p with %d pages\n", +xen_be_unmap_grant_refs(xendev, region->addr, region->num); +xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n", region->addr, region->num); g_free(region); } @@ -304,7 +293,6 @@ static int ioreq_parse(struct ioreq *ioreq) goto err; } -ioreq->domids[i] = blkdev->xendev.dom; ioreq->refs[i] = ioreq->req.seg[i].gref; mem = ioreq->req.seg[i].first_sect * blkdev->file_blk; @@ -324,7 +312,8 @@ err: static void ioreq_unmap(struct ioreq *ioreq) { -xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev; +struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; int i; if (ioreq->num_unmap == 0 || ioreq->mapped == 0) { @@ -334,11 +323,7 @@ static void ioreq_unmap(struct ioreq *ioreq) if (!ioreq->pages) { return; } -if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap); ioreq->blkdev->cnt_map -= ioreq->num_unmap; ioreq->pages = NULL; } else { @@ -346,11 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq) if (!ioreq->page[i]) { continue; } -if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_ref(xendev, ioreq->page[i]); ioreq->blkdev->cnt_map--; ioreq->page[i] = NULL; } @@ -360,14 +341,14 @@ static void ioreq_unmap(struct ioreq *ioreq) static int ioreq_map(struct ioreq *ioreq) { -xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev; -uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; +struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
[Xen-devel] [PATCH v3 3/8] xen: remove other open-coded use of libxengnttab
Now that helpers are available in xen_backend, use them throughout all Xen PV backends. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Greg Kurz Cc: Paolo Bonzini Cc: Jason Wang Cc: Gerd Hoffmann v2: - New in v2 --- hw/9pfs/xen-9p-backend.c | 32 +++- hw/char/xen_console.c| 9 - hw/net/xen_nic.c | 34 +++--- hw/usb/xen-usb.c | 37 + 4 files changed, 51 insertions(+), 61 deletions(-) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index 95e50c4..6026780 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -331,14 +331,14 @@ static int xen_9pfs_free(struct XenDevice *xendev) for (i = 0; i < xen_9pdev->num_rings; i++) { if (xen_9pdev->rings[i].data != NULL) { -xengnttab_unmap(xen_9pdev->xendev.gnttabdev, -xen_9pdev->rings[i].data, -(1 << xen_9pdev->rings[i].ring_order)); +xen_be_unmap_grant_refs(_9pdev->xendev, +xen_9pdev->rings[i].data, +(1 << xen_9pdev->rings[i].ring_order)); } if (xen_9pdev->rings[i].intf != NULL) { -xengnttab_unmap(xen_9pdev->xendev.gnttabdev, -xen_9pdev->rings[i].intf, -1); +xen_be_unmap_grant_refs(_9pdev->xendev, +xen_9pdev->rings[i].intf, +1); } if (xen_9pdev->rings[i].bh != NULL) { qemu_bh_delete(xen_9pdev->rings[i].bh); @@ -390,11 +390,10 @@ static int xen_9pfs_connect(struct XenDevice *xendev) } g_free(str); -xen_9pdev->rings[i].intf = xengnttab_map_grant_ref( -xen_9pdev->xendev.gnttabdev, -xen_9pdev->xendev.dom, -xen_9pdev->rings[i].ref, -PROT_READ | PROT_WRITE); +xen_9pdev->rings[i].intf = +xen_be_map_grant_ref(_9pdev->xendev, + xen_9pdev->rings[i].ref, + PROT_READ | PROT_WRITE); if (!xen_9pdev->rings[i].intf) { goto out; } @@ -403,12 +402,11 @@ static int xen_9pfs_connect(struct XenDevice *xendev) goto out; } xen_9pdev->rings[i].ring_order = ring_order; -xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs( -xen_9pdev->xendev.gnttabdev, -(1 << ring_order), -xen_9pdev->xendev.dom, -xen_9pdev->rings[i].intf->ref, -PROT_READ | PROT_WRITE); +xen_9pdev->rings[i].data = +xen_be_map_grant_refs(_9pdev->xendev, + xen_9pdev->rings[i].intf->ref, + (1 << ring_order), + PROT_READ | PROT_WRITE); if (!xen_9pdev->rings[i].data) { goto out; } diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index bdfaa40..8b4b4bf 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -233,12 +233,11 @@ static int con_initialise(struct XenDevice *xendev) if (!xendev->dev) { xen_pfn_t mfn = con->ring_ref; con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom, - PROT_READ|PROT_WRITE, + PROT_READ | PROT_WRITE, 1, , NULL); } else { -con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, con->xendev.dom, - con->ring_ref, - PROT_READ|PROT_WRITE); +con->sring = xen_be_map_grant_ref(xendev, con->ring_ref, + PROT_READ | PROT_WRITE); } if (!con->sring) return -1; @@ -267,7 +266,7 @@ static void con_disconnect(struct XenDevice *xendev) if (!xendev->dev) { xenforeignmemory_unmap(xen_fmem, con->sring, 1); } else { -xengnttab_unmap(xendev->gnttabdev, con->sring, 1); +xen_be_unmap_grant_ref(xendev, con->sring); } con->sring = NULL; } diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index 20c43a6..73d6f1b 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -160,9 +160,8 @@ static void net_tx_packets(struct XenNetDev *netdev) (txreq.flags & NETTXF_more_data) ? " more_data" : "", (txreq.flags & NETTXF_extra_info) ? " extra_info" : ""); -page =
[Xen-devel] [PATCH v3 4/8] xen_backend: add an emulation of grant copy
Not all Xen environments support the xengnttab_grant_copy() operation. E.g. where the OS is FreeBSD or Xen is older than 4.8.0. This patch introduces an emulation of that operation using xengnttab_map_domain_grant_refs() and memcpy() for those environments. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 53 1 file changed, 53 insertions(+) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 50412d6..3c3fc2c 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -146,6 +146,55 @@ void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr, } } +static int compat_copy_grant_refs(struct XenDevice *xendev, + bool to_domain, + XenGrantCopySegment segs[], + unsigned int nr_segs) +{ +uint32_t *refs = g_new(uint32_t, nr_segs); +int prot = to_domain ? PROT_WRITE : PROT_READ; +void *pages; +unsigned int i; + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; + +refs[i] = to_domain ? +seg->dest.foreign.ref : seg->source.foreign.ref; +} + +pages = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_segs, +xen_domid, refs, prot); +if (!pages) { +xen_pv_printf(xendev, 0, + "xengnttab_map_domain_grant_refs failed: %s\n", + strerror(errno)); +g_free(refs); +return -1; +} + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; +void *page = pages + (i * XC_PAGE_SIZE); + +if (to_domain) { +memcpy(page + seg->dest.foreign.offset, seg->source.virt, + seg->len); +} else { +memcpy(seg->dest.virt, page + seg->source.foreign.offset, + seg->len); +} +} + +if (xengnttab_unmap(xendev->gnttabdev, pages, nr_segs)) { +xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n", + strerror(errno)); +} + +g_free(refs); +return 0; +} + int xen_be_copy_grant_refs(struct XenDevice *xendev, bool to_domain, XenGrantCopySegment segs[], @@ -157,6 +206,10 @@ int xen_be_copy_grant_refs(struct XenDevice *xendev, assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); +if (!xen_feature_grant_copy) { +return compat_copy_grant_refs(xendev, to_domain, segs, nr_segs); +} + xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs); for (i = 0; i < nr_segs; i++) { -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev
Certain functions in xen_disk are called with a pointer to xendev (struct XenDevice *). They then use continer_of() to acces the surrounding blkdev (struct XenBlkDev) but then in various places use >xendev when use of the original xendev pointer is shorter to express and clearly equivalent. This patch is a purely cosmetic patch which makes sure there is a xendev pointer on stack for any function where the pointer is need on multiple occasions modified those functions to use it consistently. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - Re-based --- hw/block/xen_disk.c | 90 +++-- 1 file changed, 46 insertions(+), 44 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 28651c5..9fbc0cd 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -178,10 +178,11 @@ static void ioreq_release(struct ioreq *ioreq, bool finish) static int ioreq_parse(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; size_t len; int i; -xen_pv_printf(>xendev, 3, +xen_pv_printf(xendev, 3, "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 "\n", ioreq->req.operation, ioreq->req.nr_segments, ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number); @@ -199,28 +200,28 @@ static int ioreq_parse(struct ioreq *ioreq) case BLKIF_OP_DISCARD: return 0; default: -xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n", +xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n", ioreq->req.operation); goto err; }; if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') { -xen_pv_printf(>xendev, 0, "error: write req for ro device\n"); +xen_pv_printf(xendev, 0, "error: write req for ro device\n"); goto err; } ioreq->start = ioreq->req.sector_number * blkdev->file_blk; for (i = 0; i < ioreq->req.nr_segments; i++) { if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) { -xen_pv_printf(>xendev, 0, "error: nr_segments too big\n"); +xen_pv_printf(xendev, 0, "error: nr_segments too big\n"); goto err; } if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) { -xen_pv_printf(>xendev, 0, "error: first > last sector\n"); +xen_pv_printf(xendev, 0, "error: first > last sector\n"); goto err; } if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) { -xen_pv_printf(>xendev, 0, "error: page crossing\n"); +xen_pv_printf(xendev, 0, "error: page crossing\n"); goto err; } @@ -228,7 +229,7 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->size += len; } if (ioreq->start + ioreq->size > blkdev->file_size) { -xen_pv_printf(>xendev, 0, "error: access beyond end of file\n"); +xen_pv_printf(xendev, 0, "error: access beyond end of file\n"); goto err; } return 0; @@ -244,7 +245,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) struct XenDevice *xendev = >xendev; XenGrantCopySegment segs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; int i, count, rc; -int64_t file_blk = ioreq->blkdev->file_blk; +int64_t file_blk = blkdev->file_blk; bool to_domain = (ioreq->req.operation == BLKIF_OP_READ); void *virt = ioreq->buf; @@ -272,7 +273,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count); if (rc) { -xen_pv_printf(>blkdev->xendev, 0, +xen_pv_printf(xendev, 0, "failed to copy data %d\n", rc); ioreq->aio_errors++; return -1; @@ -287,11 +288,12 @@ static void qemu_aio_complete(void *opaque, int ret) { struct ioreq *ioreq = opaque; struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; aio_context_acquire(blkdev->ctx); if (ret != 0) { -xen_pv_printf(>xendev, 0, "%s I/O error\n", +xen_pv_printf(xendev, 0, "%s I/O error\n", ioreq->req.operation == BLKIF_OP_READ ? "read" : "write"); ioreq->aio_errors++; } @@ -625,16 +627,17 @@ static void blk_alloc(struct XenDevice *xendev) static void blk_parse_discard(struct XenBlkDev *blkdev) { +struct XenDevice *xendev = >xendev; int enable; blkdev->feature_discard = true; -if (xenstore_read_be_int(>xendev, "discard-enable", ) == 0) { +if (xenstore_read_be_int(xendev, "discard-enable", ) == 0) { blkdev->feature_discard = !!enable; } if (blkdev->feature_discard) { -
[Xen-devel] [PATCH v3 7/8] xen_disk: use a single entry iovec
Since xen_disk now always copies data to and from a guest there is no need to maintain a vector entry corresponding to every page of a request. This means there is less per-request state to maintain so the ioreq structure can shrink significantly. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v3: - Un-break by fixing mis-placed qemu_iovec_add() v2: - Re-based --- hw/block/xen_disk.c | 76 +++-- 1 file changed, 21 insertions(+), 55 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 28be8b6..28651c5 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -46,13 +46,10 @@ struct ioreq { /* parsed request */ off_t start; QEMUIOVectorv; +void*buf; +size_t size; int presync; -/* grant mapping */ -uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -void*pages; - /* aio status */ int aio_inflight; int aio_errors; @@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq) memset(>req, 0, sizeof(ioreq->req)); ioreq->status = 0; ioreq->start = 0; +ioreq->buf = NULL; +ioreq->size = 0; ioreq->presync = 0; -memset(ioreq->refs, 0, sizeof(ioreq->refs)); -memset(ioreq->page, 0, sizeof(ioreq->page)); -ioreq->pages = NULL; - ioreq->aio_inflight = 0; ioreq->aio_errors = 0; @@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev) ioreq = g_malloc0(sizeof(*ioreq)); ioreq->blkdev = blkdev; blkdev->requests_total++; -qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST); +qemu_iovec_init(>v, 1); } else { /* get one from freelist */ ioreq = QLIST_FIRST(>freelist); @@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish) static int ioreq_parse(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; -uintptr_t mem; size_t len; int i; @@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq) goto err; } -ioreq->refs[i] = ioreq->req.seg[i].gref; - -mem = ioreq->req.seg[i].first_sect * blkdev->file_blk; len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) * blkdev->file_blk; -qemu_iovec_add(>v, (void*)mem, len); +ioreq->size += len; } -if (ioreq->start + ioreq->v.size > blkdev->file_size) { +if (ioreq->start + ioreq->size > blkdev->file_size) { xen_pv_printf(>xendev, 0, "error: access beyond end of file\n"); goto err; } @@ -247,35 +238,6 @@ err: return -1; } -static void ioreq_free_copy_buffers(struct ioreq *ioreq) -{ -int i; - -for (i = 0; i < ioreq->v.niov; i++) { -ioreq->page[i] = NULL; -} - -qemu_vfree(ioreq->pages); -} - -static int ioreq_init_copy_buffers(struct ioreq *ioreq) -{ -int i; - -if (ioreq->v.niov == 0) { -return 0; -} - -ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE); - -for (i = 0; i < ioreq->v.niov; i++) { -ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE; -ioreq->v.iov[i].iov_base = ioreq->page[i]; -} - -return 0; -} - static int ioreq_grant_copy(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; @@ -284,25 +246,27 @@ static int ioreq_grant_copy(struct ioreq *ioreq) int i, count, rc; int64_t file_blk = ioreq->blkdev->file_blk; bool to_domain = (ioreq->req.operation == BLKIF_OP_READ); +void *virt = ioreq->buf; -if (ioreq->v.niov == 0) { +if (ioreq->req.nr_segments == 0) { return 0; } -count = ioreq->v.niov; +count = ioreq->req.nr_segments; for (i = 0; i < count; i++) { if (to_domain) { -segs[i].dest.foreign.ref = ioreq->refs[i]; +segs[i].dest.foreign.ref = ioreq->req.seg[i].gref; segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; -segs[i].source.virt = ioreq->v.iov[i].iov_base; +segs[i].source.virt = virt; } else { -segs[i].source.foreign.ref = ioreq->refs[i]; +segs[i].source.foreign.ref = ioreq->req.seg[i].gref; segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; -segs[i].dest.virt = ioreq->v.iov[i].iov_base; +segs[i].dest.virt = virt; } segs[i].len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) * file_blk; +virt += segs[i].len; } rc =
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests
On 04/05/18 19:45, Boris Ostrovsky wrote: > On 05/04/2018 01:28 PM, Andrew Cooper wrote: >> --- a/xen/include/asm-x86/msr-index.h >> +++ b/xen/include/asm-x86/msr-index.h >> @@ -31,6 +31,9 @@ >> #define EFER_LMSLE (1<<_EFER_LMSLE) >> #define EFER_FFXSE (1<<_EFER_FFXSE) >> >> +#define EFER_KNOWN_MASK (EFER_SCE | EFER_LME | EFER_LMA | >> EFER_NX | \ > > I think there is an extra tab here (but this may be my email client not > showing it properly) Its correct in the file, but renders incorrectly everywhere else. (I did a doubletake the first time I saw the email.) > Reviewed-by: Boris OstrovskyThanks, ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests
On 05/04/2018 01:28 PM, Andrew Cooper wrote: > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -31,6 +31,9 @@ > #define EFER_LMSLE (1<<_EFER_LMSLE) > #define EFER_FFXSE (1<<_EFER_FFXSE) > > +#define EFER_KNOWN_MASK (EFER_SCE | EFER_LME | EFER_LMA | > EFER_NX | \ I think there is an extra tab here (but this may be my email client not showing it properly) Reviewed-by: Boris Ostrovsky___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments
On 05/04/2018 11:07 AM, Jan Beulich wrote: > Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates > a (theoretical) window the first patch still leaves, so should at least be > considered. > Furthermore previous discussion suggests that it might even be desirable to > fold > both patches into one (or swap their order). > > 1: re-work VMCB sync-ing > 2: introduce a VM entry helper > > Signed-off-by: Jan Beulich> > Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments
On 04/05/18 16:07, Jan Beulich wrote: > Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates > a (theoretical) window the first patch still leaves, so should at least be > considered. > Furthermore previous discussion suggests that it might even be desirable to > fold > both patches into one (or swap their order). > > 1: re-work VMCB sync-ing > 2: introduce a VM entry helper > > Signed-off-by: Jan BeulichAs this is fixing a real bug and we're getting quite late in 4.11 at this point, Acked-by: Andrew Cooper I'm still not happy with the API, and especially that "svm_sync_vmcb(curr, vmcb_needs_vmsave);" in patch two does not do the intuitive thing. That said, I'm going to need to rewrite this anyway in 4.12 to get the MSR infrastructure working, so this code isn't going to stay long. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl
Thanks. This is much better :-). I have reviewed this for style, obvious bugs, and the semantics in the doc comment. I haven't tried to follow the algorithm in detail, but I reckon it's probably OK. I have reordered the patch (and hence the file) to make the grouping of my comments make more sense. Lars Kurth writes ("[PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl"): > + --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none) > +Insert email addresses into *.patch files according to the POLICY > +See section POLICY: > + --inscover (top|ccend|none) | -c (top|ccend|none) > +Insert email addresses into cover letteraccording to the POLICY > +See section PROCESSING POLICY: I'm afraid that I don't understand which addresses are added where, from the documentation. In particular, what happens without --tags or --tagscc ? Also you should define `tag'; it has a lot of different meanings, some subtly different, and it is not completely clear which one you mean. I think you should formally state the default behaviour. Something like: By default: * get_maintainer is called on each patch to find email addresses of maintainers/reviewers for that patch; these are added to the patch body near the CC section. * further email addresses are found in each patch's commit message tags (CC, signed-off-by, reviewed-by, etc.) * All of the above addresses are added to the CC mail headers of each patch * All of the above addresses are added to the CC mail headers of the cover letter I suspect that what I have above is not the real behaviour. You should write what is true in that kind of style :-). > +my $patch_prefix = "0"; # Use a 0, such that v* does not get picked up > +# Obviously this will only work for series with > +# < 999 patches, which should be fine I don't understand the purpose of this: > +if ($rerollcount > 0) { > +$patch_prefix = "v".$rerollcount; > +} ... > +my $pattern = $patch_dir.'/'.$patch_prefix.'*'.$patch_ext; > +print "Then perform:\n". > + "git send-email -to xen-devel\@lists.xenproject.org ". > + $patch_dir.'/'.$patch_prefix."*.patch"."\n"; What files matching *.patch exist here that should not be processed ? If the answer is none then $patch_prefix is redundant, I think ? > +foreach my $file (@patches) { > +if ($file =~ /\Q$cover_letter\E/) { I know you had me look at this over your shoulder and I said it was right, but I think in fact this would match hypothetical files $patch_dir/0020-do-something-about--cover-letter.patch I think you need to expect a /. So one of +if ($file =~ /\/\Q$cover_letter\E/) { +if ($file =~ m{/\Q$cover_letter\E}) { > +print "Then perform:\n". > + "git send-email -to xen-devel\@lists.xenproject.org ". > + $patch_dir.'/'.$patch_prefix."*.patch"."\n"; > + > +exit 0; > + > +my $readmailinglists = 0; > +my @mailinglists = (); This is a very curious structure. These assignments are never executed (but I guess the program works anyway). I would recommend moving the main program to the bottom of the file. > +sub getmailinglists () { > + # Read mailing list from MAINTAINERS file and copy > + # a list of e-mail addresses to @mailinglists > +if (!$readmailinglists) { I suggest you rename this variable $getmailinglists_done or something. As it is it is confusing because `read' might be the present tense, but then the sense is wrong. Also, you might find it better to use a structure like one of if ($getmailingslists_done) { return; } return if $getmailingslists_done; > +if (-e $maintainers) { ... > +print "Warning: Mailing lists will be treated as CC's\n"; > +} > +# Don't try again, even if the MAINTAINERS file does not exist > +$readmailinglists = 1; > +# Remove any duplicates > +@mailinglists = uniq @mailinglists; > +} Indentation here is misleading. (But this will go away if you adopt my suggestion above). > +sub ismailinglist ($) { > +my ($check) = @_; > +# Get the mailing list information > +getmailinglists(); > +# Do the check > +if ( grep { $_ eq $check} @mailinglists) { Rather than uniq above, and then grep here, you could use a hash %mailinglists. That would be more idiomatic and also less code and faster. But as it is is tolerable. > +sub getmaintainers ($$$) { > +my ($file, $rto, $rcc) = @_; > +my $get_maintainer_args = join " ", @get_maintainer_args; > +my $cmd = "$get_maintainer $get_maintainer_args <$file"; ... > +open($fh, "-|", $cmd) > +or die "Failed to open '$cmd'\n"; You should use the array form of piped open, rather than this string joining. That way arguments containing spaces make their way through correct. > +if (! -e $get_maintainer) { > +die "$tool: The tool requires
[Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests
We don't advertise SVM in CPUID so a PV guest shouldn't be under the impression that it can use SVM functionality, but despite this, it really shouldn't see SVME set when reading EFER. Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use this to clamp the guests view. Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and change "undefined" to "unknown" in the print message, as there is at least EFER.TCE (Translation Cache Extension) defined but unknown to Xen. Signed-off-by: Andrew Cooper--- CC: Jan Beulich CC: Boris Ostrovsky CC: Suravee Suthikulpanit CC: Brian Woods CC: Juergen Gross Arguably, this wants backporting to the stable trees, so should be considered for 4.11 at this point. --- xen/arch/x86/hvm/svm/svmdebug.c | 5 ++--- xen/arch/x86/pv/emul-priv-op.c | 4 +++- xen/include/asm-x86/msr-index.h | 3 +++ 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c index 6c215d1..d35e405 100644 --- a/xen/arch/x86/hvm/svm/svmdebug.c +++ b/xen/arch/x86/hvm/svm/svmdebug.c @@ -133,9 +133,8 @@ bool svm_vmcb_isvalid(const char *from, const struct vmcb_struct *vmcb, PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n", vmcb_get_dr7(vmcb)); -if ( efer & ~(EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | EFER_SVME | - EFER_LMSLE | EFER_FFXSE) ) -PRINTF("EFER: undefined bits are not zero (%#"PRIx64")\n", efer); +if ( efer & ~EFER_KNOWN_MASK ) +PRINTF("EFER: unknown bits are not zero (%#"PRIx64")\n", efer); if ( hvm_efer_valid(v, efer, -1) ) PRINTF("EFER: %s (%"PRIx64")\n", hvm_efer_valid(v, efer, -1), efer); diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index 15f42b3..8293f31 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val, return X86EMUL_OKAY; case MSR_EFER: -*val = read_efer(); +/* Hide unknown bits, and unconditionally hide SVME from guests. */ +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME; +/* Hide the 64-bit features from 32-bit guests. */ if ( is_pv_32bit_domain(currd) ) *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE); return X86EMUL_OKAY; diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index c9f44eb..6d94d65 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -31,6 +31,9 @@ #define EFER_LMSLE (1<<_EFER_LMSLE) #define EFER_FFXSE (1<<_EFER_FFXSE) +#define EFER_KNOWN_MASK(EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | \ +EFER_SVME | EFER_LMSLE | EFER_FFXSE) + /* Speculation Controls. */ #define MSR_SPEC_CTRL 0x0048 #define SPEC_CTRL_IBRS (_AC(1, ULL) << 0) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 6/7] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()
>>> On 08.07.17 at 23:53,wrote: > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -383,9 +383,13 @@ __efi64_mb2_start: > jmp x86_32_switch > > .Lefi_multiboot2_proto: > -/* Zero EFI SystemTable and EFI ImageHandle addresses. */ > +/* > + * Zero EFI SystemTable, EFI ImageHandle and > + * dom0 kernel module struct addresses. > + */ > xor %esi,%esi > xor %edi,%edi > +xor %r14d,%r14d > > /* Skip Multiboot2 information fixed part. */ > lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx > @@ -423,6 +427,15 @@ __efi64_mb2_start: > cmove MB2_efi64_ih(%rcx),%rdi > je .Lefi_mb2_next_tag > > +/* Get dom0 kernel module struct address from Multiboot2 > information. */ > +cmpl$MULTIBOOT2_TAG_TYPE_MODULE,MB2_tag_type(%rcx) > +jne .Lefi_mb2_end > + > +test%r14d,%r14d > +cmovz %ecx,%r14d > +jmp .Lefi_mb2_next_tag > + > +.Lefi_mb2_end: > /* Is it the end of Multiboot2 information? */ > cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx) > je .Lrun_bs > @@ -484,9 +497,12 @@ __efi64_mb2_start: > /* Keep the stack aligned. Do not pop a single item off it. */ > mov (%rsp),%rdi > > +mov %r14d,%edx > + > /* > * efi_multiboot2() is called according to System V AMD64 ABI: > - * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable. > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable, > + * %rdx - dom0 kernel module struct address. How come everything further up treats this as a 32-bit quantity only? > @@ -47,6 +49,7 @@ extern const struct pe_base_relocs { > > static void __init efi_arch_relocate_image(unsigned long delta) > { > +#if 0 > const struct pe_base_relocs *base_relocs; > > for ( base_relocs = __base_relocs_start; base_relocs < > __base_relocs_end; ) > @@ -95,6 +98,7 @@ static void __init efi_arch_relocate_image(unsigned long > delta) > } > base_relocs = (const void *)(base_relocs->entries + i + (i & 1)); > } > +#endif > } ??? > @@ -669,7 +673,9 @@ static bool __init > efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable) > > static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { } > > -void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE > *SystemTable) > +void __init efi_multiboot2(EFI_HANDLE ImageHandle, > + EFI_SYSTEM_TABLE *SystemTable, > + multiboot2_tag_module_t *dom0_kernel) const? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 3/7] xen/x86: Add some addresses to the Multiboot header
>>> On 08.07.17 at 23:53,wrote: > In comparison to ELF the PE format is not supported by the Multiboot > protocol. So, if we wish to load xen.efi using this protocol we have > to put header_addr, load_addr, load_end_addr, bss_end_addr and > entry_addr data into Multiboot header. Looks fine, but you will want to assure us that this non-ELF method of loading is compatible with each and every loader able of loading Xen so far. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 2/7] xen/x86: Manually build PE header
>>> On 08.07.17 at 23:53,wrote: > This is the first step to get: > - one binary which can be loaded by the EFI loader, > Multiboot and Multiboot2 protocols, > - if we wish, in the future we can drop xen/xen.gz > and build xen.efi only, If anything, generate xen.gz from xen.efi - I see value in the compression, but the EFI loader requires an uncompressed binary. And of course we'd have to raise the minimal gcc version requirement. > --- a/xen/arch/x86/Rules.mk > +++ b/xen/arch/x86/Rules.mk > @@ -7,6 +7,8 @@ CFLAGS += -I$(BASEDIR)/include > CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic > CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default > CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET) > +CFLAGS += -DXEN_LOAD_ALIGN=XEN_IMG_OFFSET > +CFLAGS += -DXEN_FILE_ALIGN=PAGE_SIZE ??? (Sadly your description talks about benefits only, not about what the patch actually does.) > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -1,3 +1,4 @@ > +#include > #include > #include > #include > @@ -44,6 +45,150 @@ > .Lmb2ht_init_end\@: > .endm > > +.section .efi.pe.header, "a", @progbits > + > +ENTRY(efi_pe_head) Since you put this in a separate section anyway, why don't you place it in a C file (perhaps even of its own) with suitably declared structures? > +/* > + * Legacy EXE header. > + * > + * Most of it is copied from binutils package, version 2.28, > + * include/coff/pe.h:struct external_PEI_filehdr and > + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out(). > + * > + * Page is equal 512 bytes here. > + * Paragraph is equal 16 bytes here. > + */ > +.short 0x5a4d /* EXE magic number. */ > +.short 0x90 /* Bytes on last page of > file. */ > +.short 0x3/* Pages in file. */ > +.short 0 /* Relocations. */ > +.short 0x4/* Size of header in > paragraphs. */ > +.short 0 /* Minimum extra > paragraphs needed. */ > +.short 0x /* Maximum extra > paragraphs needed. */ > +.short 0 /* Initial (relative) SS > value. */ > +.short 0xb8 /* Initial SP value. */ > +.short 0 /* Checksum. */ > +.short 0 /* Initial IP value. */ > +.short 0 /* Initial (relative) CS > value. */ > +.short 0x40 /* File address of > relocation table. */ > +.short 0 /* Overlay number. */ > +.fill 4, 2, 0/* Reserved words. */ > +.short 0 /* OEM identifier. */ > +.short 0 /* OEM information. */ > +.fill 10, 2, 0 /* Reserved words. */ > +.long pe_header - efi_pe_head/* File address of the PE > header. */ > + > +/* > + * DOS message. > + * > + * It is copied from binutils package, version 2.28, > + * include/coff/pe.h:struct external_PEI_filehdr and > + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out(). > + */ > +.long 0x0eba1f0e > +.long 0xcd09b400 > +.long 0x4c01b821 > +.long 0x685421cd > +.long 0x70207369 > +.long 0x72676f72 > +.long 0x63206d61 > +.long 0x6f6e6e61 > +.long 0x65622074 > +.long 0x6e757220 > +.long 0x206e6920 > +.long 0x20534f44 > +.long 0x65646f6d > +.long 0x0a0d0d2e > +.long 0x24 > +.long 0 Other than what the comment says, this isn't just a message (or else you could have used .asciz for the whole thing). I'm not convinced we need any of this. > @@ -259,6 +266,8 @@ SECTIONS > #endif >__2M_rwdata_end = .; > > + __pe_SizeOfImage = ALIGN(. - __image_base__, XEN_LOAD_ALIGN); I don't think this is in line with what xen.efi currently has. Any difference needs explaining (I think there are further fields in this category). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver
>>> On 04.05.18 at 16:51,wrote: > A bit more than a week ago, I put out for initial review the proposal for > “Graduation Review: Windows PV Driver” at > https://xen.markmail.org/thread/vcbvln7aa3ocikx4 +1 Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/8] xen_disk: use a single entry iovec
> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 04 May 2018 14:56 > To: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > de...@nongnu.org > Cc: Paul Durrant; Stefano Stabellini > ; Anthony Perard ; > Kevin Wolf ; Max Reitz > Subject: [PATCH v2 7/8] xen_disk: use a single entry iovec > > Since xen_disk now always copies data to and from a guest there is no need > to maintain a vector entry corresponding to every page of a request. > This means there is less per-request state to maintain so the ioreq > structure can shrink significantly. > > Signed-off-by: Paul Durrant > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Kevin Wolf > Cc: Max Reitz > > v2: > - Re-based Unfortunately I managed to drop a hunk during rebase and so this patch is actually broken. I'll send a rectified v3 shortly. Paul > --- > hw/block/xen_disk.c | 71 > ++--- > 1 file changed, 18 insertions(+), 53 deletions(-) > > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c > index 28be8b6..230961f 100644 > --- a/hw/block/xen_disk.c > +++ b/hw/block/xen_disk.c > @@ -46,13 +46,10 @@ struct ioreq { > /* parsed request */ > off_t start; > QEMUIOVectorv; > +void*buf; > +size_t size; > int presync; > > -/* grant mapping */ > -uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; > -void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; > -void*pages; > - > /* aio status */ > int aio_inflight; > int aio_errors; > @@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq) > memset(>req, 0, sizeof(ioreq->req)); > ioreq->status = 0; > ioreq->start = 0; > +ioreq->buf = NULL; > +ioreq->size = 0; > ioreq->presync = 0; > > -memset(ioreq->refs, 0, sizeof(ioreq->refs)); > -memset(ioreq->page, 0, sizeof(ioreq->page)); > -ioreq->pages = NULL; > - > ioreq->aio_inflight = 0; > ioreq->aio_errors = 0; > > @@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev > *blkdev) > ioreq = g_malloc0(sizeof(*ioreq)); > ioreq->blkdev = blkdev; > blkdev->requests_total++; > -qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST); > +qemu_iovec_init(>v, 1); > } else { > /* get one from freelist */ > ioreq = QLIST_FIRST(>freelist); > @@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool > finish) > static int ioreq_parse(struct ioreq *ioreq) > { > struct XenBlkDev *blkdev = ioreq->blkdev; > -uintptr_t mem; > size_t len; > int i; > > @@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq) > goto err; > } > > -ioreq->refs[i] = ioreq->req.seg[i].gref; > - > -mem = ioreq->req.seg[i].first_sect * blkdev->file_blk; > len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + > 1) * > blkdev->file_blk; > -qemu_iovec_add(>v, (void*)mem, len); > +ioreq->size += len; > } > -if (ioreq->start + ioreq->v.size > blkdev->file_size) { > +if (ioreq->start + ioreq->size > blkdev->file_size) { > xen_pv_printf(>xendev, 0, "error: access beyond end of > file\n"); > goto err; > } > @@ -247,35 +238,6 @@ err: > return -1; > } > > -static void ioreq_free_copy_buffers(struct ioreq *ioreq) > -{ > -int i; > - > -for (i = 0; i < ioreq->v.niov; i++) { > -ioreq->page[i] = NULL; > -} > - > -qemu_vfree(ioreq->pages); > -} > - > -static int ioreq_init_copy_buffers(struct ioreq *ioreq) > -{ > -int i; > - > -if (ioreq->v.niov == 0) { > -return 0; > -} > - > -ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * > XC_PAGE_SIZE); > - > -for (i = 0; i < ioreq->v.niov; i++) { > -ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE; > -ioreq->v.iov[i].iov_base = ioreq->page[i]; > -} > - > -return 0; > -} > - > static int ioreq_grant_copy(struct ioreq *ioreq) > { > struct XenBlkDev *blkdev = ioreq->blkdev; > @@ -284,6 +246,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) > int i, count, rc; > int64_t file_blk = ioreq->blkdev->file_blk; > bool to_domain = (ioreq->req.operation == BLKIF_OP_READ); > +void *virt = ioreq->buf; > > if (ioreq->v.niov == 0) { > return 0; > @@ -293,16 +256,17 @@ static int ioreq_grant_copy(struct ioreq *ioreq) > > for (i = 0; i < count; i++) { > if (to_domain) { > -segs[i].dest.foreign.ref = ioreq->refs[i]; > +
Re: [Xen-devel] [PATCH] docs: fix xpti command line option doc
>>> On 04.05.18 at 17:09,wrote: > Signed-off-by: Wei Liu I don't think a change like this really needs an ack, but here you go: Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper
Neither the register values copying nor the trace entry generation need doing in assembly. The VMLOAD invocation can also be further deferred (and centralized). Therefore replace the svm_asid_handle_vmrun() invocation with one of the new helper. Similarly move the VM exit side register value copying into svm_vmexit_handler(). Now that we always make it out to guest context after VMLOAD, svm_sync_vmcb() no longer overrides vmcb_needs_vmsave, making svm_vmexit_handler() setting the field early unnecessary. Signed-off-by: Jan Beulich--- v3: svm_vmexit_handler() no longer explicitly sets vmcb_sync_state, and svm_sync_vmcb() no longer converts a needs-vmsave request into in-sync state. Also move the svm_trace_vmentry() invocation to C. v2: New. --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap) jmp .Lsvm_do_resume __UNLIKELY_END(nsvm_hap) -call svm_asid_handle_vmrun - -cmpb $0,tb_init_done(%rip) -UNLIKELY_START(nz, svm_trace) -call svm_trace_vmentry -UNLIKELY_END(svm_trace) - -mov VCPU_svm_vmcb(%rbx),%rcx -mov UREGS_rax(%rsp),%rax -mov %rax,VMCB_rax(%rcx) -mov UREGS_rip(%rsp),%rax -mov %rax,VMCB_rip(%rcx) -mov UREGS_rsp(%rsp),%rax -mov %rax,VMCB_rsp(%rcx) -mov UREGS_eflags(%rsp),%rax -or $X86_EFLAGS_MBS,%rax -mov %rax,VMCB_rflags(%rcx) +mov %rsp, %rdi +call svm_vmenter_helper mov VCPU_arch_msr(%rbx), %rax mov VCPUMSR_spec_ctrl_raw(%rax), %eax @@ -111,16 +96,6 @@ UNLIKELY_END(svm_trace) SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: acd */ /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ -mov VCPU_svm_vmcb(%rbx),%rcx -mov VMCB_rax(%rcx),%rax -mov %rax,UREGS_rax(%rsp) -mov VMCB_rip(%rcx),%rax -mov %rax,UREGS_rip(%rsp) -mov VMCB_rsp(%rcx),%rax -mov %rax,UREGS_rsp(%rsp) -mov VMCB_rflags(%rcx),%rax -mov %rax,UREGS_eflags(%rsp) - STGI GLOBAL(svm_stgi_label) mov %rsp,%rdi --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -687,10 +687,9 @@ static void svm_sync_vmcb(struct vcpu *v if ( new_state == vmcb_needs_vmsave ) { if ( arch_svm->vmcb_sync_state == vmcb_needs_vmload ) -{ svm_vmload(arch_svm->vmcb); -arch_svm->vmcb_sync_state = vmcb_in_sync; -} + +arch_svm->vmcb_sync_state = new_state; } else { @@ -1171,11 +1170,29 @@ static void noreturn svm_do_resume(struc hvm_do_resume(v); -svm_sync_vmcb(v, vmcb_needs_vmsave); - reset_stack_and_jump(svm_asm_do_resume); } +void svm_vmenter_helper(const struct cpu_user_regs *regs) +{ +struct vcpu *curr = current; +struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb; + +svm_asid_handle_vmrun(); + +if ( unlikely(tb_init_done) ) +HVMTRACE_ND(VMENTRY, +nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0, +1/*cycles*/, 0, 0, 0, 0, 0, 0, 0); + +svm_sync_vmcb(curr, vmcb_needs_vmsave); + +vmcb->rax = regs->rax; +vmcb->rip = regs->rip; +vmcb->rsp = regs->rsp; +vmcb->rflags = regs->rflags | X86_EFLAGS_MBS; +} + static void svm_guest_osvw_init(struct vcpu *vcpu) { if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ) @@ -2621,7 +2638,11 @@ void svm_vmexit_handler(struct cpu_user_ bool_t vcpu_guestmode = 0; struct vlapic *vlapic = vcpu_vlapic(v); -v->arch.hvm_svm.vmcb_sync_state = vmcb_needs_vmsave; +regs->rax = vmcb->rax; +regs->rip = vmcb->rip; +regs->rsp = vmcb->rsp; +regs->rflags = vmcb->rflags; + hvm_invalidate_regs_fields(regs); if ( paging_mode_hap(v->domain) ) @@ -3108,8 +3129,6 @@ void svm_vmexit_handler(struct cpu_user_ } out: -svm_sync_vmcb(v, vmcb_needs_vmsave); - if ( vcpu_guestmode || vlapic_hw_disabled(vlapic) ) return; @@ -3118,17 +3137,8 @@ void svm_vmexit_handler(struct cpu_user_ intr.fields.tpr = (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0xFF) >> 4; vmcb_set_vintr(vmcb, intr); -ASSERT(v->arch.hvm_svm.vmcb_sync_state != vmcb_needs_vmload); } -void svm_trace_vmentry(void) -{ -struct vcpu *curr = current; -HVMTRACE_ND(VMENTRY, -nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0, -1/*cycles*/, 0, 0, 0, 0, 0, 0, 0); -} - /* * Local variables: * mode: C --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -119,12 +119,6 @@ void __dummy__(void) OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.is_32bit_pv); BLANK(); -OFFSET(VMCB_rax, struct vmcb_struct, rax); -OFFSET(VMCB_rip, struct vmcb_struct, rip); -OFFSET(VMCB_rsp, struct vmcb_struct, rsp); -
[Xen-devel] [PATCH v3 1/2] SVM: re-work VMCB sync-ing
While the main problem to be addressed here is the issue of what so far was named "vmcb_in_sync" starting out with the wrong value (should have been true instead of false, to prevent performing a VMSAVE without ever having VMLOADed the vCPU's state), go a step further and make the sync-ed state a tristate: CPU and memory may be in sync or an update may be required in either direction. Rename the field and introduce an enum. Callers of svm_sync_vmcb() now indicate the intended new state (with a slight "anomaly" when requesting VMLOAD: we could store vmcb_needs_vmsave in those cases as the callers request, but the VMCB really is in sync at that point, and hence there's no need to VMSAVE in case we don't make it out to guest context), and all syncing goes through that function. With that, there's no need to VMLOAD the state perhaps multiple times; all that's needed is loading it once before VM entry. Signed-off-by: Jan Beulich--- v3: Move conditionals around the svm_sync_vmcb() invocations from svm_do_resume() and svm_vmexit_handler() into the function. v2: Also handle VMLOAD in svm_sync_vmcb(). Add comment to enum vmcb_sync_state. --- I've been considering to put the VMLOAD invocation in svm_asid_handle_vmrun() (instead of the two copies in svm_do_resume() and svm_vmexit_handler()), but that seemed a little too abusive of the function. See patch 2. I'm also not really certain about svm_vmexit_do_vmload(): All I'm doing here is a 1:1 change from previous behavior, but I'm unconvinced this was/is really correct. --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -112,7 +112,6 @@ UNLIKELY_END(svm_trace) /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ mov VCPU_svm_vmcb(%rbx),%rcx -movb $0,VCPU_svm_vmcb_in_sync(%rbx) mov VMCB_rax(%rcx),%rax mov %rax,UREGS_rax(%rsp) mov VMCB_rip(%rcx),%rax --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -680,16 +680,26 @@ static void svm_cpuid_policy_changed(str cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW); } -static void svm_sync_vmcb(struct vcpu *v) +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) { struct arch_svm_struct *arch_svm = >arch.hvm_svm; -if ( arch_svm->vmcb_in_sync ) -return; - -arch_svm->vmcb_in_sync = 1; +if ( new_state == vmcb_needs_vmsave ) +{ +if ( arch_svm->vmcb_sync_state == vmcb_needs_vmload ) +{ +svm_vmload(arch_svm->vmcb); +arch_svm->vmcb_sync_state = vmcb_in_sync; +} +} +else +{ +if ( arch_svm->vmcb_sync_state == vmcb_needs_vmsave ) +svm_vmsave(arch_svm->vmcb); -svm_vmsave(arch_svm->vmcb); +if ( arch_svm->vmcb_sync_state != vmcb_needs_vmload ) +arch_svm->vmcb_sync_state = new_state; +} } static unsigned int svm_get_cpl(struct vcpu *v) @@ -707,7 +717,7 @@ static void svm_get_segment_register(str switch ( seg ) { case x86_seg_fs ... x86_seg_gs: -svm_sync_vmcb(v); +svm_sync_vmcb(v, vmcb_in_sync); /* Fallthrough. */ case x86_seg_es ... x86_seg_ds: @@ -718,7 +728,7 @@ static void svm_get_segment_register(str break; case x86_seg_tr: -svm_sync_vmcb(v); +svm_sync_vmcb(v, vmcb_in_sync); *reg = vmcb->tr; break; @@ -731,7 +741,7 @@ static void svm_get_segment_register(str break; case x86_seg_ldtr: -svm_sync_vmcb(v); +svm_sync_vmcb(v, vmcb_in_sync); *reg = vmcb->ldtr; break; @@ -746,7 +756,6 @@ static void svm_set_segment_register(str struct segment_register *reg) { struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb; -bool sync = false; ASSERT((v == current) || !vcpu_runnable(v)); @@ -768,7 +777,8 @@ static void svm_set_segment_register(str case x86_seg_gs: case x86_seg_tr: case x86_seg_ldtr: -sync = (v == current); +if ( v == current ) +svm_sync_vmcb(v, vmcb_needs_vmload); break; default: @@ -777,9 +787,6 @@ static void svm_set_segment_register(str return; } -if ( sync ) -svm_sync_vmcb(v); - switch ( seg ) { case x86_seg_ss: @@ -813,9 +820,6 @@ static void svm_set_segment_register(str ASSERT_UNREACHABLE(); break; } - -if ( sync ) -svm_vmload(vmcb); } static unsigned long svm_get_shadow_gs_base(struct vcpu *v) @@ -1086,7 +1090,7 @@ static void svm_ctxt_switch_from(struct svm_lwp_save(v); svm_tsc_ratio_save(v); -svm_sync_vmcb(v); +svm_sync_vmcb(v, vmcb_needs_vmload); svm_vmload_pa(per_cpu(host_vmcb, cpu)); /* Resume use of ISTs now that the host TR is reinstated. */ @@ -1114,7 +1118,6 @@ static void svm_ctxt_switch_to(struct vc
[Xen-devel] [PATCH] docs: fix xpti command line option doc
Signed-off-by: Wei Liu--- docs/misc/xen-command-line.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index e7a8bd66e7..616dc9d34c 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1980,7 +1980,7 @@ region of memory being available. ### xpti > `= List of [ default | | dom0= | domu= ]` -> Default: `false` on hardware not to be vulnerable to Meltdown (e.g. AMD) +> Default: `false` on hardware known not to be vulnerable to Meltdown (e.g. AMD) > Default: `true` everywhere else Override default selection of whether to isolate 64-bit PV guest page -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments
Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates a (theoretical) window the first patch still leaves, so should at least be considered. Furthermore previous discussion suggests that it might even be desirable to fold both patches into one (or swap their order). 1: re-work VMCB sync-ing 2: introduce a VM entry helper Signed-off-by: Jan Beulich___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 3/9] xen/x86: support per-domain flag for xpti
On Fri, Apr 27, 2018 at 02:15:25AM -0600, Jan Beulich wrote: > >>> On 27.04.18 at 09:59,wrote: > > On 27/04/18 09:55, Sergey Dyasli wrote: > >> On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote: > >>> index b353352adf..220d1ba020 100644 > >>> --- a/docs/misc/xen-command-line.markdown > >>> +++ b/docs/misc/xen-command-line.markdown > >>> @@ -1955,14 +1955,24 @@ clustered mode. The default, given no hint from > >>> the **FADT**, is cluster > >>> mode. > >>> > >>> ### xpti > >>> -> `= ` > >>> +> `= List of [ default | | dom0= | domu= ]` > >>> > >>> -> Default: `false` on AMD hardware > >>> +> Default: `false` on hardware not to be vulnerable to Meltdown (e.g. > >>> AMD) > >> ^ > >> known > > > > Yes, indeed. > > Recorded for eventual application of the series; no need to resend just for > this. Oops, I missed this while fixing up the conflicts. I will submit a patch to fix this. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver
+1 from me. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 0/9] xen/x86: various XPTI speedups
On Thu, Apr 26, 2018 at 01:33:09PM +0200, Juergen Gross wrote: > Juergen Gross (9): > x86/xpti: avoid copying L4 page table contents when possible > xen/x86: add a function for modifying cr3 > xen/x86: support per-domain flag for xpti > xen/x86: use invpcid for flushing the TLB > xen/x86: disable global pages for domains with XPTI active > xen/x86: use flag byte for decision whether xen_cr3 is valid > xen/x86: convert pv_guest_cr4_to_real_cr4() to a function > xen/x86: add some cr3 helpers > xen/x86: use PCID feature There are conflicts in xen-command-line. I fixed them up and pushed this series to staging. Please check if the result is correct. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Votel] Graduation Review: Windows PV Driver
On 04/05/18 15:51, Lars Kurth wrote: > Hi all, > > A bit more than a week ago, I put out for initial review the proposal for > “Graduation Review: Windows PV Driver” at > https://xen.markmail.org/thread/vcbvln7aa3ocikx4 > There has not been feedback, except for two recorded votes from the Xen > Project Hypervisor Team by Ian Jackson and George Dunlap (both in favour). > > in accordance with https://www.xenproject.org/governance.html, I need the > leadership teams of the two mature projects – the Hypervisor and the XAPI > project – to vote on this proposal. > > The specific voting rules in this case are outlined in section > https://www.xenproject.org/governance.html#project-decisions > > People allowed to vote on behalf of the Hypervisor project are: > Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R > Wilk, Stefano Stabellini, Tim Deegan, Wei Liu > and Juergen Gross (as Release Manager). > > People allowed to vote on behalf of the XAPI project are: > Jon Ludlam, Chandrika Srinivasan, David Scott, Euan Harris, Germano Percossi, > Siddharth Vinoth Kumar, John Else, Mate Lakat, Konstantina Chremmou, Rob > Hoes, Si Beaumont, Thanos Makatos, Thomas Sanders, Vineeth Thampi Raveendran, > Zheng Li > > I propose to tally the votes by Friday the 6th of October. You can reply via > +1: for proposal > -1: against proposal > in public or private. > > Votes will be tallied by subproject – aka the Hypervisor and XAPI project by > % for the proposal - and then averaged across sub-projects that achieved the > quorum. > > Sub-project needs to achieve the following quorum of votes in favour for the > sub-project’s vote to count > Hypervisor: 4 + votes > XAPI: 5 + votes > > At least one subproject needs to achieve a quorum. So to pass, we need two > more votes from the Hypervisor team. +1. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Votel] Graduation Review: Windows PV Driver
Hi all, A bit more than a week ago, I put out for initial review the proposal for “Graduation Review: Windows PV Driver” at https://xen.markmail.org/thread/vcbvln7aa3ocikx4 There has not been feedback, except for two recorded votes from the Xen Project Hypervisor Team by Ian Jackson and George Dunlap (both in favour). in accordance with https://www.xenproject.org/governance.html, I need the leadership teams of the two mature projects – the Hypervisor and the XAPI project – to vote on this proposal. The specific voting rules in this case are outlined in section https://www.xenproject.org/governance.html#project-decisions People allowed to vote on behalf of the Hypervisor project are: Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R Wilk, Stefano Stabellini, Tim Deegan, Wei Liu and Juergen Gross (as Release Manager). People allowed to vote on behalf of the XAPI project are: Jon Ludlam, Chandrika Srinivasan, David Scott, Euan Harris, Germano Percossi, Siddharth Vinoth Kumar, John Else, Mate Lakat, Konstantina Chremmou, Rob Hoes, Si Beaumont, Thanos Makatos, Thomas Sanders, Vineeth Thampi Raveendran, Zheng Li I propose to tally the votes by Friday the 6th of October. You can reply via +1: for proposal -1: against proposal in public or private. Votes will be tallied by subproject – aka the Hypervisor and XAPI project by % for the proposal - and then averaged across sub-projects that achieved the quorum. Sub-project needs to achieve the following quorum of votes in favour for the sub-project’s vote to count Hypervisor: 4 + votes XAPI: 5 + votes At least one subproject needs to achieve a quorum. So to pass, we need two more votes from the Hypervisor team. The proposals are attached Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen 4.11 RC3
Hi all, Xen 4.11 rc3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.11.0-rc3 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.11.0-rc3/xen-4.11.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.11.0-rc3/xen-4.11.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). As a reminder, there will be another Xen Test Day on May 8th. See instructions on: https://wiki.xenproject.org/wiki/Xen_4.11_RC_test_instructions Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/8] xen_disk: legacy code removal and cleanup
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying a significant amount of code purely to remain compatible with older versions of Xen. As can be inferred from the diff stats below, removing this support for older versions of Xen from QEMU reduces the size of the xen_disk source by around 320 lines (~25%). Version 2 of this series maintains compatibility with older Xen, and OS not supporting the grant copy operation, by adding an emulation of it into the xen_backend code. Thus xen_disk can be simplified without regressing support for any environment. This version also performs general cleanup of the code by introducing and consistently using helper functions for calling into libxenttab. Paul Durrant (8): xen_backend: add grant table helpers xen_disk: remove open-coded use of libxengnttab xen: remove other open-coded use of libxengnttab xen_backend: add an emulation of grant copy xen_disk: remove use of grant map/unmap xen_backend: make the xen_feature_grant_copy flag private xen_disk: use a single entry iovec xen_disk: be consistent with use of xendev and blkdev->xendev hw/9pfs/xen-9p-backend.c | 32 ++- hw/block/xen_disk.c | 609 +++ hw/char/xen_console.c| 9 +- hw/net/xen_nic.c | 34 ++- hw/usb/xen-usb.c | 37 ++- hw/xen/xen_backend.c | 178 - include/hw/xen/xen_backend.h | 34 ++- 7 files changed, 348 insertions(+), 585 deletions(-) --- Cc: Anthony PerardCc: Gerd Hoffmann Cc: Greg Kurz Cc: Jason Wang Cc: Kevin Wolf Cc: Max Reitz Cc: Paolo Bonzini Cc: Stefano Stabellini -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 7/8] xen_disk: use a single entry iovec
Since xen_disk now always copies data to and from a guest there is no need to maintain a vector entry corresponding to every page of a request. This means there is less per-request state to maintain so the ioreq structure can shrink significantly. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - Re-based --- hw/block/xen_disk.c | 71 ++--- 1 file changed, 18 insertions(+), 53 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 28be8b6..230961f 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -46,13 +46,10 @@ struct ioreq { /* parsed request */ off_t start; QEMUIOVectorv; +void*buf; +size_t size; int presync; -/* grant mapping */ -uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -void*pages; - /* aio status */ int aio_inflight; int aio_errors; @@ -110,12 +107,10 @@ static void ioreq_reset(struct ioreq *ioreq) memset(>req, 0, sizeof(ioreq->req)); ioreq->status = 0; ioreq->start = 0; +ioreq->buf = NULL; +ioreq->size = 0; ioreq->presync = 0; -memset(ioreq->refs, 0, sizeof(ioreq->refs)); -memset(ioreq->page, 0, sizeof(ioreq->page)); -ioreq->pages = NULL; - ioreq->aio_inflight = 0; ioreq->aio_errors = 0; @@ -138,7 +133,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev) ioreq = g_malloc0(sizeof(*ioreq)); ioreq->blkdev = blkdev; blkdev->requests_total++; -qemu_iovec_init(>v, BLKIF_MAX_SEGMENTS_PER_REQUEST); +qemu_iovec_init(>v, 1); } else { /* get one from freelist */ ioreq = QLIST_FIRST(>freelist); @@ -183,7 +178,6 @@ static void ioreq_release(struct ioreq *ioreq, bool finish) static int ioreq_parse(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; -uintptr_t mem; size_t len; int i; @@ -230,13 +224,10 @@ static int ioreq_parse(struct ioreq *ioreq) goto err; } -ioreq->refs[i] = ioreq->req.seg[i].gref; - -mem = ioreq->req.seg[i].first_sect * blkdev->file_blk; len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) * blkdev->file_blk; -qemu_iovec_add(>v, (void*)mem, len); +ioreq->size += len; } -if (ioreq->start + ioreq->v.size > blkdev->file_size) { +if (ioreq->start + ioreq->size > blkdev->file_size) { xen_pv_printf(>xendev, 0, "error: access beyond end of file\n"); goto err; } @@ -247,35 +238,6 @@ err: return -1; } -static void ioreq_free_copy_buffers(struct ioreq *ioreq) -{ -int i; - -for (i = 0; i < ioreq->v.niov; i++) { -ioreq->page[i] = NULL; -} - -qemu_vfree(ioreq->pages); -} - -static int ioreq_init_copy_buffers(struct ioreq *ioreq) -{ -int i; - -if (ioreq->v.niov == 0) { -return 0; -} - -ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE); - -for (i = 0; i < ioreq->v.niov; i++) { -ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE; -ioreq->v.iov[i].iov_base = ioreq->page[i]; -} - -return 0; -} - static int ioreq_grant_copy(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; @@ -284,6 +246,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) int i, count, rc; int64_t file_blk = ioreq->blkdev->file_blk; bool to_domain = (ioreq->req.operation == BLKIF_OP_READ); +void *virt = ioreq->buf; if (ioreq->v.niov == 0) { return 0; @@ -293,16 +256,17 @@ static int ioreq_grant_copy(struct ioreq *ioreq) for (i = 0; i < count; i++) { if (to_domain) { -segs[i].dest.foreign.ref = ioreq->refs[i]; +segs[i].dest.foreign.ref = ioreq->req.seg[i].gref; segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; -segs[i].source.virt = ioreq->v.iov[i].iov_base; +segs[i].source.virt = virt; } else { -segs[i].source.foreign.ref = ioreq->refs[i]; +segs[i].source.foreign.ref = ioreq->req.seg[i].gref; segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * file_blk; -segs[i].dest.virt = ioreq->v.iov[i].iov_base; +segs[i].dest.virt = virt; } segs[i].len = (ioreq->req.seg[i].last_sect - ioreq->req.seg[i].first_sect + 1) * file_blk; +virt += segs[i].len; } rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count); @@ -314,6 +278,7 @@ static int ioreq_grant_copy(struct
[Xen-devel] [PATCH v2 5/8] xen_disk: remove use of grant map/unmap
Now that the (native or emulated) xen_be_copy_grant_refs() helper is always available, the xen_disk code can be significantly simplified by removing direct use of grant map and unmap operations. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - Squashed in separate patche removing persistent grant use - Re-based --- hw/block/xen_disk.c | 370 1 file changed, 25 insertions(+), 345 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 66ed2b7..28be8b6 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -36,27 +36,9 @@ /* - */ -static int batch_maps = 0; - -/* - */ - #define BLOCK_SIZE 512 #define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2) -struct PersistentGrant { -void *page; -struct XenBlkDev *blkdev; -}; - -typedef struct PersistentGrant PersistentGrant; - -struct PersistentRegion { -void *addr; -int num; -}; - -typedef struct PersistentRegion PersistentRegion; - struct ioreq { blkif_request_t req; int16_t status; @@ -65,14 +47,11 @@ struct ioreq { off_t start; QEMUIOVectorv; int presync; -uint8_t mapped; /* grant mapping */ uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; -int prot; void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; void*pages; -int num_unmap; /* aio status */ int aio_inflight; @@ -103,7 +82,6 @@ struct XenBlkDev { int protocol; blkif_back_rings_t rings; int more_work; -int cnt_map; /* request lists */ QLIST_HEAD(inflight_head, ioreq) inflight; @@ -114,13 +92,7 @@ struct XenBlkDev { int requests_finished; unsigned intmax_requests; -/* Persistent grants extension */ gbooleanfeature_discard; -gbooleanfeature_persistent; -GTree *persistent_gnts; -GSList *persistent_regions; -unsigned intpersistent_gnt_count; -unsigned intmax_grants; /* qemu block driver */ DriveInfo *dinfo; @@ -139,10 +111,8 @@ static void ioreq_reset(struct ioreq *ioreq) ioreq->status = 0; ioreq->start = 0; ioreq->presync = 0; -ioreq->mapped = 0; memset(ioreq->refs, 0, sizeof(ioreq->refs)); -ioreq->prot = 0; memset(ioreq->page, 0, sizeof(ioreq->page)); ioreq->pages = NULL; @@ -156,37 +126,6 @@ static void ioreq_reset(struct ioreq *ioreq) qemu_iovec_reset(>v); } -static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data) -{ -uint ua = GPOINTER_TO_UINT(a); -uint ub = GPOINTER_TO_UINT(b); -return (ua > ub) - (ua < ub); -} - -static void destroy_grant(gpointer pgnt) -{ -PersistentGrant *grant = pgnt; -struct XenBlkDev *blkdev = grant->blkdev; -struct XenDevice *xendev = >xendev; - -xen_be_unmap_grant_ref(xendev, grant->page); -grant->blkdev->persistent_gnt_count--; -xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page); -g_free(grant); -} - -static void remove_persistent_region(gpointer data, gpointer dev) -{ -PersistentRegion *region = data; -struct XenBlkDev *blkdev = dev; -struct XenDevice *xendev = >xendev; - -xen_be_unmap_grant_refs(xendev, region->addr, region->num); -xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n", - region->addr, region->num); -g_free(region); -} - static struct ioreq *ioreq_start(struct XenBlkDev *blkdev) { struct ioreq *ioreq = NULL; @@ -254,7 +193,6 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number); switch (ioreq->req.operation) { case BLKIF_OP_READ: -ioreq->prot = PROT_WRITE; /* to memory */ break; case BLKIF_OP_FLUSH_DISKCACHE: ioreq->presync = 1; @@ -263,7 +201,6 @@ static int ioreq_parse(struct ioreq *ioreq) } /* fall through */ case BLKIF_OP_WRITE: -ioreq->prot = PROT_READ; /* from memory */ break; case BLKIF_OP_DISCARD: return 0; @@ -310,173 +247,6 @@ err: return -1; } -static void ioreq_unmap(struct ioreq *ioreq) -{ -struct XenBlkDev *blkdev = ioreq->blkdev; -struct XenDevice *xendev = >xendev; -int i; - -if (ioreq->num_unmap == 0 || ioreq->mapped == 0) { -return; -} -if (batch_maps) { -if (!ioreq->pages) { -return; -} -
[Xen-devel] [PATCH v2 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev
Certain functions in xen_disk are called with a pointer to xendev (struct XenDevice *). They then use continer_of() to acces the surrounding blkdev (struct XenBlkDev) but then in various places use >xendev when use of the original xendev pointer is shorter to express and clearly equivalent. This patch is a purely cosmetic patch which makes sure there is a xendev pointer on stack for any function where the pointer is need on multiple occasions modified those functions to use it consistently. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - Re-based --- hw/block/xen_disk.c | 90 +++-- 1 file changed, 46 insertions(+), 44 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 230961f..d8b430d 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -178,10 +178,11 @@ static void ioreq_release(struct ioreq *ioreq, bool finish) static int ioreq_parse(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; size_t len; int i; -xen_pv_printf(>xendev, 3, +xen_pv_printf(xendev, 3, "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 "\n", ioreq->req.operation, ioreq->req.nr_segments, ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number); @@ -199,28 +200,28 @@ static int ioreq_parse(struct ioreq *ioreq) case BLKIF_OP_DISCARD: return 0; default: -xen_pv_printf(>xendev, 0, "error: unknown operation (%d)\n", +xen_pv_printf(xendev, 0, "error: unknown operation (%d)\n", ioreq->req.operation); goto err; }; if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') { -xen_pv_printf(>xendev, 0, "error: write req for ro device\n"); +xen_pv_printf(xendev, 0, "error: write req for ro device\n"); goto err; } ioreq->start = ioreq->req.sector_number * blkdev->file_blk; for (i = 0; i < ioreq->req.nr_segments; i++) { if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) { -xen_pv_printf(>xendev, 0, "error: nr_segments too big\n"); +xen_pv_printf(xendev, 0, "error: nr_segments too big\n"); goto err; } if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) { -xen_pv_printf(>xendev, 0, "error: first > last sector\n"); +xen_pv_printf(xendev, 0, "error: first > last sector\n"); goto err; } if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) { -xen_pv_printf(>xendev, 0, "error: page crossing\n"); +xen_pv_printf(xendev, 0, "error: page crossing\n"); goto err; } @@ -228,7 +229,7 @@ static int ioreq_parse(struct ioreq *ioreq) ioreq->size += len; } if (ioreq->start + ioreq->size > blkdev->file_size) { -xen_pv_printf(>xendev, 0, "error: access beyond end of file\n"); +xen_pv_printf(xendev, 0, "error: access beyond end of file\n"); goto err; } return 0; @@ -244,7 +245,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) struct XenDevice *xendev = >xendev; XenGrantCopySegment segs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; int i, count, rc; -int64_t file_blk = ioreq->blkdev->file_blk; +int64_t file_blk = blkdev->file_blk; bool to_domain = (ioreq->req.operation == BLKIF_OP_READ); void *virt = ioreq->buf; @@ -272,7 +273,7 @@ static int ioreq_grant_copy(struct ioreq *ioreq) rc = xen_be_copy_grant_refs(xendev, to_domain, segs, count); if (rc) { -xen_pv_printf(>blkdev->xendev, 0, +xen_pv_printf(xendev, 0, "failed to copy data %d\n", rc); ioreq->aio_errors++; return -1; @@ -288,11 +289,12 @@ static void qemu_aio_complete(void *opaque, int ret) { struct ioreq *ioreq = opaque; struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; aio_context_acquire(blkdev->ctx); if (ret != 0) { -xen_pv_printf(>xendev, 0, "%s I/O error\n", +xen_pv_printf(xendev, 0, "%s I/O error\n", ioreq->req.operation == BLKIF_OP_READ ? "read" : "write"); ioreq->aio_errors++; } @@ -624,16 +626,17 @@ static void blk_alloc(struct XenDevice *xendev) static void blk_parse_discard(struct XenBlkDev *blkdev) { +struct XenDevice *xendev = >xendev; int enable; blkdev->feature_discard = true; -if (xenstore_read_be_int(>xendev, "discard-enable", ) == 0) { +if (xenstore_read_be_int(xendev, "discard-enable", ) == 0) { blkdev->feature_discard = !!enable; } if (blkdev->feature_discard) { -
[Xen-devel] [PATCH v2 1/8] xen_backend: add grant table helpers
This patch adds grant table helper functions to the xen_backend code to localize error reporting and use of xen_domid. The patch also defers the call to xengnttab_open() until just before the initialise method in XenDevOps is invoked. This method is responsible for mapping the shared ring. No prior method requires access to the grant table. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 123 ++- include/hw/xen/xen_backend.h | 33 2 files changed, 144 insertions(+), 12 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 7445b50..50412d6 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -106,6 +106,103 @@ int xen_be_set_state(struct XenDevice *xendev, enum xenbus_state state) return 0; } +void xen_be_set_max_grant_refs(struct XenDevice *xendev, + unsigned int nr_refs) +{ +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +if (xengnttab_set_max_grants(xendev->gnttabdev, nr_refs)) { +xen_pv_printf(xendev, 0, "xengnttab_set_max_grants failed: %s\n", + strerror(errno)); +} +} + +void *xen_be_map_grant_refs(struct XenDevice *xendev, uint32_t *refs, +unsigned int nr_refs, int prot) +{ +void *ptr; + +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +ptr = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_refs, + xen_domid, refs, prot); +if (!ptr) { +xen_pv_printf(xendev, 0, + "xengnttab_map_domain_grant_refs failed: %s\n", + strerror(errno)); +} + +return ptr; +} + +void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr, + unsigned int nr_refs) +{ +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +if (xengnttab_unmap(xendev->gnttabdev, ptr, nr_refs)) { +xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n", + strerror(errno)); +} +} + +int xen_be_copy_grant_refs(struct XenDevice *xendev, + bool to_domain, + XenGrantCopySegment segs[], + unsigned int nr_segs) +{ +xengnttab_grant_copy_segment_t *xengnttab_segs; +unsigned int i; +int rc; + +assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); + +xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs); + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; +xengnttab_grant_copy_segment_t *xengnttab_seg = _segs[i]; + +if (to_domain) { +xengnttab_seg->flags = GNTCOPY_dest_gref; +xengnttab_seg->dest.foreign.domid = xen_domid; +xengnttab_seg->dest.foreign.ref = seg->dest.foreign.ref; +xengnttab_seg->dest.foreign.offset = seg->dest.foreign.offset; +xengnttab_seg->source.virt = seg->source.virt; +} else { +xengnttab_seg->flags = GNTCOPY_source_gref; +xengnttab_seg->source.foreign.domid = xen_domid; +xengnttab_seg->source.foreign.ref = seg->source.foreign.ref; +xengnttab_seg->source.foreign.offset = +seg->source.foreign.offset; +xengnttab_seg->dest.virt = seg->dest.virt; +} + +xengnttab_seg->len = seg->len; +} + +rc = xengnttab_grant_copy(xendev->gnttabdev, nr_segs, xengnttab_segs); + +if (rc) { +xen_pv_printf(xendev, 0, "xengnttab_copy failed: %s\n", + strerror(errno)); +} + +for (i = 0; i < nr_segs; i++) { +xengnttab_grant_copy_segment_t *xengnttab_seg = +_segs[i]; + +if (xengnttab_seg->status != GNTST_okay) { +xen_pv_printf(xendev, 0, "segment[%u] status: %d\n", i, + xengnttab_seg->status); +rc = -1; +} +} + +g_free(xengnttab_segs); +return rc; +} + /* * get xen backend device, allocate a new one if it doesn't exist. */ @@ -149,18 +246,6 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, } qemu_set_cloexec(xenevtchn_fd(xendev->evtchndev)); -if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) { -xendev->gnttabdev = xengnttab_open(NULL, 0); -if (xendev->gnttabdev == NULL) { -xen_pv_printf(NULL, 0, "can't open gnttab device\n"); -xenevtchn_close(xendev->evtchndev); -qdev_unplug(DEVICE(xendev), NULL); -return NULL; -} -} else { -xendev->gnttabdev = NULL; -} - xen_pv_insert_xendev(xendev); if (xendev->ops->alloc) { @@ -322,6 +407,16 @@ static int xen_be_try_initialise(struct XenDevice *xendev) } } +
[Xen-devel] [PATCH v2 2/8] xen_disk: remove open-coded use of libxengnttab
Now that helpers are present in xen_backend, this patch removes open-coded calls to libxengnttab from the xen_disk code. This patch also fixes one whitspace error in the assignment of the XenDevOps initialise method. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Kevin Wolf Cc: Max Reitz v2: - New in v2 --- hw/block/xen_disk.c | 122 ++-- 1 file changed, 32 insertions(+), 90 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index f74fcd4..66ed2b7 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -68,7 +68,6 @@ struct ioreq { uint8_t mapped; /* grant mapping */ -uint32_tdomids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; uint32_trefs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; int prot; void*page[BLKIF_MAX_SEGMENTS_PER_REQUEST]; @@ -142,7 +141,6 @@ static void ioreq_reset(struct ioreq *ioreq) ioreq->presync = 0; ioreq->mapped = 0; -memset(ioreq->domids, 0, sizeof(ioreq->domids)); memset(ioreq->refs, 0, sizeof(ioreq->refs)); ioreq->prot = 0; memset(ioreq->page, 0, sizeof(ioreq->page)); @@ -168,16 +166,12 @@ static gint int_cmp(gconstpointer a, gconstpointer b, gpointer user_data) static void destroy_grant(gpointer pgnt) { PersistentGrant *grant = pgnt; -xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev; +struct XenBlkDev *blkdev = grant->blkdev; +struct XenDevice *xendev = >xendev; -if (xengnttab_unmap(gnt, grant->page, 1) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_ref(xendev, grant->page); grant->blkdev->persistent_gnt_count--; -xen_pv_printf(>blkdev->xendev, 3, - "unmapped grant %p\n", grant->page); +xen_pv_printf(xendev, 3, "unmapped grant %p\n", grant->page); g_free(grant); } @@ -185,15 +179,10 @@ static void remove_persistent_region(gpointer data, gpointer dev) { PersistentRegion *region = data; struct XenBlkDev *blkdev = dev; -xengnttab_handle *gnt = blkdev->xendev.gnttabdev; +struct XenDevice *xendev = >xendev; -if (xengnttab_unmap(gnt, region->addr, region->num) != 0) { -xen_pv_printf(>xendev, 0, - "xengnttab_unmap region %p failed: %s\n", - region->addr, strerror(errno)); -} -xen_pv_printf(>xendev, 3, - "unmapped grant region %p with %d pages\n", +xen_be_unmap_grant_refs(xendev, region->addr, region->num); +xen_pv_printf(xendev, 3, "unmapped grant region %p with %d pages\n", region->addr, region->num); g_free(region); } @@ -304,7 +293,6 @@ static int ioreq_parse(struct ioreq *ioreq) goto err; } -ioreq->domids[i] = blkdev->xendev.dom; ioreq->refs[i] = ioreq->req.seg[i].gref; mem = ioreq->req.seg[i].first_sect * blkdev->file_blk; @@ -324,7 +312,8 @@ err: static void ioreq_unmap(struct ioreq *ioreq) { -xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev; +struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; int i; if (ioreq->num_unmap == 0 || ioreq->mapped == 0) { @@ -334,11 +323,7 @@ static void ioreq_unmap(struct ioreq *ioreq) if (!ioreq->pages) { return; } -if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_refs(xendev, ioreq->pages, ioreq->num_unmap); ioreq->blkdev->cnt_map -= ioreq->num_unmap; ioreq->pages = NULL; } else { @@ -346,11 +331,7 @@ static void ioreq_unmap(struct ioreq *ioreq) if (!ioreq->page[i]) { continue; } -if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) { -xen_pv_printf(>blkdev->xendev, 0, - "xengnttab_unmap failed: %s\n", - strerror(errno)); -} +xen_be_unmap_grant_ref(xendev, ioreq->page[i]); ioreq->blkdev->cnt_map--; ioreq->page[i] = NULL; } @@ -360,14 +341,14 @@ static void ioreq_unmap(struct ioreq *ioreq) static int ioreq_map(struct ioreq *ioreq) { -xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev; -uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST]; +struct XenBlkDev *blkdev = ioreq->blkdev; +struct XenDevice *xendev = >xendev; uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST]; void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
[Xen-devel] [PATCH v2 4/8] xen_backend: add an emulation of grant copy
Not all Xen environments support the xengnttab_grant_copy() operation. E.g. where the OS is FreeBSD or Xen is older than 4.8.0. This patch introduces an emulation of that operation using xengnttab_map_domain_grant_refs() and memcpy() for those environments. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 53 1 file changed, 53 insertions(+) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 50412d6..3c3fc2c 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -146,6 +146,55 @@ void xen_be_unmap_grant_refs(struct XenDevice *xendev, void *ptr, } } +static int compat_copy_grant_refs(struct XenDevice *xendev, + bool to_domain, + XenGrantCopySegment segs[], + unsigned int nr_segs) +{ +uint32_t *refs = g_new(uint32_t, nr_segs); +int prot = to_domain ? PROT_WRITE : PROT_READ; +void *pages; +unsigned int i; + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; + +refs[i] = to_domain ? +seg->dest.foreign.ref : seg->source.foreign.ref; +} + +pages = xengnttab_map_domain_grant_refs(xendev->gnttabdev, nr_segs, +xen_domid, refs, prot); +if (!pages) { +xen_pv_printf(xendev, 0, + "xengnttab_map_domain_grant_refs failed: %s\n", + strerror(errno)); +g_free(refs); +return -1; +} + +for (i = 0; i < nr_segs; i++) { +XenGrantCopySegment *seg = [i]; +void *page = pages + (i * XC_PAGE_SIZE); + +if (to_domain) { +memcpy(page + seg->dest.foreign.offset, seg->source.virt, + seg->len); +} else { +memcpy(seg->dest.virt, page + seg->source.foreign.offset, + seg->len); +} +} + +if (xengnttab_unmap(xendev->gnttabdev, pages, nr_segs)) { +xen_pv_printf(xendev, 0, "xengnttab_unmap failed: %s\n", + strerror(errno)); +} + +g_free(refs); +return 0; +} + int xen_be_copy_grant_refs(struct XenDevice *xendev, bool to_domain, XenGrantCopySegment segs[], @@ -157,6 +206,10 @@ int xen_be_copy_grant_refs(struct XenDevice *xendev, assert(xendev->ops->flags & DEVOPS_FLAG_NEED_GNTDEV); +if (!xen_feature_grant_copy) { +return compat_copy_grant_refs(xendev, to_domain, segs, nr_segs); +} + xengnttab_segs = g_new0(xengnttab_grant_copy_segment_t, nr_segs); for (i = 0; i < nr_segs; i++) { -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 3/8] xen: remove other open-coded use of libxengnttab
Now that helpers are available in xen_backend, use them throughout all Xen PV backends. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Greg Kurz Cc: Paolo Bonzini Cc: Jason Wang Cc: Gerd Hoffmann v2: - New in v2 --- hw/9pfs/xen-9p-backend.c | 32 +++- hw/char/xen_console.c| 9 - hw/net/xen_nic.c | 34 +++--- hw/usb/xen-usb.c | 37 + 4 files changed, 51 insertions(+), 61 deletions(-) diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c index 95e50c4..6026780 100644 --- a/hw/9pfs/xen-9p-backend.c +++ b/hw/9pfs/xen-9p-backend.c @@ -331,14 +331,14 @@ static int xen_9pfs_free(struct XenDevice *xendev) for (i = 0; i < xen_9pdev->num_rings; i++) { if (xen_9pdev->rings[i].data != NULL) { -xengnttab_unmap(xen_9pdev->xendev.gnttabdev, -xen_9pdev->rings[i].data, -(1 << xen_9pdev->rings[i].ring_order)); +xen_be_unmap_grant_refs(_9pdev->xendev, +xen_9pdev->rings[i].data, +(1 << xen_9pdev->rings[i].ring_order)); } if (xen_9pdev->rings[i].intf != NULL) { -xengnttab_unmap(xen_9pdev->xendev.gnttabdev, -xen_9pdev->rings[i].intf, -1); +xen_be_unmap_grant_refs(_9pdev->xendev, +xen_9pdev->rings[i].intf, +1); } if (xen_9pdev->rings[i].bh != NULL) { qemu_bh_delete(xen_9pdev->rings[i].bh); @@ -390,11 +390,10 @@ static int xen_9pfs_connect(struct XenDevice *xendev) } g_free(str); -xen_9pdev->rings[i].intf = xengnttab_map_grant_ref( -xen_9pdev->xendev.gnttabdev, -xen_9pdev->xendev.dom, -xen_9pdev->rings[i].ref, -PROT_READ | PROT_WRITE); +xen_9pdev->rings[i].intf = +xen_be_map_grant_ref(_9pdev->xendev, + xen_9pdev->rings[i].ref, + PROT_READ | PROT_WRITE); if (!xen_9pdev->rings[i].intf) { goto out; } @@ -403,12 +402,11 @@ static int xen_9pfs_connect(struct XenDevice *xendev) goto out; } xen_9pdev->rings[i].ring_order = ring_order; -xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs( -xen_9pdev->xendev.gnttabdev, -(1 << ring_order), -xen_9pdev->xendev.dom, -xen_9pdev->rings[i].intf->ref, -PROT_READ | PROT_WRITE); +xen_9pdev->rings[i].data = +xen_be_map_grant_refs(_9pdev->xendev, + xen_9pdev->rings[i].intf->ref, + (1 << ring_order), + PROT_READ | PROT_WRITE); if (!xen_9pdev->rings[i].data) { goto out; } diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index bdfaa40..8b4b4bf 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -233,12 +233,11 @@ static int con_initialise(struct XenDevice *xendev) if (!xendev->dev) { xen_pfn_t mfn = con->ring_ref; con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom, - PROT_READ|PROT_WRITE, + PROT_READ | PROT_WRITE, 1, , NULL); } else { -con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, con->xendev.dom, - con->ring_ref, - PROT_READ|PROT_WRITE); +con->sring = xen_be_map_grant_ref(xendev, con->ring_ref, + PROT_READ | PROT_WRITE); } if (!con->sring) return -1; @@ -267,7 +266,7 @@ static void con_disconnect(struct XenDevice *xendev) if (!xendev->dev) { xenforeignmemory_unmap(xen_fmem, con->sring, 1); } else { -xengnttab_unmap(xendev->gnttabdev, con->sring, 1); +xen_be_unmap_grant_ref(xendev, con->sring); } con->sring = NULL; } diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index 20c43a6..73d6f1b 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -160,9 +160,8 @@ static void net_tx_packets(struct XenNetDev *netdev) (txreq.flags & NETTXF_more_data) ? " more_data" : "", (txreq.flags & NETTXF_extra_info) ? " extra_info" : ""); -page =
[Xen-devel] [PATCH v2 6/8] xen_backend: make the xen_feature_grant_copy flag private
There is no longer any use of this flag outside of the xen_backend code. Signed-off-by: Paul Durrant--- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 2 +- include/hw/xen/xen_backend.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 3c3fc2c..9a8e877 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -44,9 +44,9 @@ BusState *xen_sysbus; /* public */ struct xs_handle *xenstore = NULL; const char *xen_protocol; -bool xen_feature_grant_copy; /* private */ +static bool xen_feature_grant_copy; static int debug; int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const char *val) diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h index 29bf1c3..9c17fdd 100644 --- a/include/hw/xen/xen_backend.h +++ b/include/hw/xen/xen_backend.h @@ -16,7 +16,6 @@ /* variables */ extern struct xs_handle *xenstore; extern const char *xen_protocol; -extern bool xen_feature_grant_copy; extern DeviceState *xen_sysdev; extern BusState *xen_sysbus; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 122580: tolerable FAIL - PUSHED
flight 122580 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122580/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122493 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122529 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122529 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122529 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122529 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122529 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122529 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122529 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122529 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122529 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 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-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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 0306a1311d02ea52b4a9a9bc339f8bab9354c5e3 baseline version: xen eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897 Last test of basis 122529 2018-04-30 05:28:55 Z4 days Testing same since 122580 2018-05-03 12:11:46 Z1 days1 attempts People who touched revisions under test: Andrew CooperBrian Woods Ian Jackson Jan
Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write
>>> On 04.05.18 at 05:53,wrote: >> > Thanks for your clarification. Please correct me if I have >> > something wrong. Guest may execute an instruction and this instruction >> > may produce an PT packet save in PT output buffer. An EPT violation >> > will be generated if the address of this PT buffer don't have EPT page >> > table mapping, but this EPT violations shouldn't be handled by >> > x86_emulate() because it no relate with the execute of this instruction. >> >> Plus - and that's very important - the EPT violation may be reported on some > later insn. > > You mean the "later instruction" is some new instruction in future hardware? No, I mean an instruction following later in the instruction stream. >> > In that case, can we build the EPT map when set the output buffer >> > address (IA32_RTIT_OUTPUT_BASE) and crash the guest if still happened >> > EPT violation with Intel PT output buffer read/write exit >> > qualification. Or add an exit qualification check before instruction >> > emulation? >> >> Imo you should add an exit qualification check in any case. Depending what > else you do, finding the new bit set may imply crashing >> the domain or doing something more sophisticated. > > Do you mean add this check at the beginning of any specific "exit_reason" > handler in vmx_vmexit_handler() function? That depends. Surely not for every exit reason, but only those for which this new bit is valid (iirc exit qualifications differ per exit reason anyway, so you can't unilaterally check the same bit everywhere). And even for those where the bit is valid, I'm not sure you can decide in the exit handler alone what to do if the bit is set. It may be necessary to propagate the flag down the call tree. > Another question is where to build this EPT mapping? Setting > IA32_RTIT_OUTPUT_BASE or handled by EPT violation? I have no idea - that's more a question for you to answer yourself. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 答复: [PATCH v3] x86/cpu: Add supports for zhaoxin x86 platform
>>> On 04.05.18 at 04:54,wrote: > 发件人: Jan Beulich > 发送时间: 2018年5月3日 23:09 >> +if ( cpu_has(c, X86_FEATURE_ITSC) ) >> +{ >> +__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); >> +__set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability); >> +__set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability); >> +} >> + >> +l2 = init_intel_cacheinfo(c); >> +} > > ... this is its only use? > Yes, it Only be used to save the return value. I think it is unnecessary but > calls of init_intel_cacheinfo() (in init_intel()) make me confused. Can i > delete it in patch v4? If you don't need the value, you should (not just "can") remove the variable. Also, I think I had mentioned this before: Please adjust your quoting style when replying to mails. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [GIT PULL] xen: one cleanup for 4.17-rc4
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.17-rc4-tag xen: one cleanup for 4.17-rc4 It contains one cleanup to remove VLAs from the kernel. Thanks. Juergen arch/x86/xen/enlighten_pv.c | 86 - 1 file changed, 31 insertions(+), 55 deletions(-) Laura Abbott (1): x86/xen: Remove use of VLAs ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 74672: tolerable FAIL
flight 74672 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74672/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74644 baseline version: flight 74644 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub 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. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 122578: regressions - FAIL
flight 122578 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122578/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324 test-armhf-armhf-libvirt-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl-credit2 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl-xsm 10 debian-install fail REGR. vs. 118324 test-armhf-armhf-xl 10 debian-install fail REGR. vs. 118324 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118324 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxf4ef6a438cee86ca0c6d1b889aa53bec9c1f9de6 baseline version: linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 Last test of basis 118324 2018-01-25 07:31:24 Z 99 days Failing since118362 2018-01-26 16:56:17 Z 97 days 78 attempts Testing same since 122578 2018-05-03 11:56:24 Z0 days1 attempts 3407 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt
[Xen-devel] [PATCH for-4.11 v3 0/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl
This version of this series addresses all comments on the mailing list, as well as some feedback I got in various personal conversations and/or on IRC. For the people who asked for specific features/workflows: Ian Jackson: use ./scripts/add_maintainers.pl -p none [-c top] Reads CCs from unmodified *.patch files and inserts them into the cover letter George Dunlap: use ./scripts/add_maintainers.pl -p cc--- Tends to add CC blocks after the --- line in *.patches. This option achieves this behavior/ Julien Grall: use ./scripts/add_maintainers.pl -c ccend As far as I recall, Julien adds CC blocks into the body of the cover letter. This option achieves this, but there is no place that always exists other than before "-- " where the CC block can be insterted. I made the processing code easily extendable via policies. So if there is any missed behavior, the tool can easily be extended. Also note that git send-email does not automatically add people in *=by: tags to CC lists (with the exception of Singed-off-by). For this I added the options -t|--tags and --tagscc. v2 of this patch contained some cleanup to MAINTAINERS which has been broken out into a separate series: see https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#00028 Lars Kurth (1): Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl scripts/add_maintainers.pl | 512 + 1 file changed, 512 insertions(+) create mode 100755 scripts/add_maintainers.pl -- 2.13.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl
The tool covers step 2 of the following workflow Step 1: git format-patch ... -o ... Step 2: ./scripts/add_maintainers.pl -d This overwrites *.patch files in Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm I manually tested all options and the most common combinations on Mac. Changes since v1: - Added RAB (indicated by Juergen on IRC that this is OK) - Remove trailing whitespaces - Renamed --prefix to --reroll-count - Cleaned up short options -v, ... to be in line with git - Added --tags|-t option to add AB, RAB and RB emails to CC list - Added --insert|-i mode to allow for people adding CCs to commit message instead of the e-mail header (the header is the default) - Moved common code into functions - Added logic, such that the tool only insert's To: and Cc: statements which were not there before, allowing for running the tool multiple times on the same Changes since v2: - Deleted --version and related infrastructure - Added subroutine prototypes - Removed AT and @lists declaration and used \@ in literals - Changed usage message and options based on feedback - Improved error handling - Removed occurances of index() and replaced with regex - Removed non-perl idioms - Moved uniq statements to normalize and added info on what normalize does - Read L: tags from MAINTAINERS file instead of using heuristic - Fixed issues related to metacharacters in getmaintainers() - Allow multiple -a | --arg values (because of this renamed --args) - Identify tags via regex - CC's from tags are only inserted in the mail header, never the body - That is unless the new option --tagscc is used - Added policy processing which includes reworking insert() - Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies - Added new policies to cover for all user requests - Rewrote help message to center around usage of policies - Reordered some code (e.g. help string first to make code more easily readable) Cc: Andrew CooperCc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Signed-off-by: Lars Kurth Release-acked-by: Juergen Gross --- scripts/add_maintainers.pl | 512 + 1 file changed, 512 insertions(+) create mode 100755 scripts/add_maintainers.pl diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl new file mode 100755 index 00..11ae60d888 --- /dev/null +++ b/scripts/add_maintainers.pl @@ -0,0 +1,512 @@ +#!/usr/bin/perl -w +# (c) 2018, Lars Kurth +# +# Add maintainers to patches generated with git format-patch +# +# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir +# +# Prerequisites: Execute +#git format-patch ... -o ... +# +#./scripts/get_maintainer.pl is present in the tree +# +# Licensed under the terms of the GNU GPL License version 2 + +use strict; + +use Getopt::Long qw(:config no_auto_abbrev); +use File::Basename; +use List::MoreUtils qw(uniq); + +sub getmaintainers ($$$); +sub gettagsfrompatch ($$$;$); +sub normalize ($$); +sub insert (); +sub hastag ($$); + +# Tool Variables +my $tool = $0; +my $usage = < 1: v*.patch + --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none) +Insert email addresses into *.patch files according to the POLICY +See section POLICY: + --inscover (top|ccend|none) | -c (top|ccend|none) +Insert email addresses into cover letteraccording to the POLICY +See section PROCESSING POLICY: + --tags | -t +Read email addresses from tags and add to CC list. +Note that git send-email does not do this. It will add the senders +email adress to the CC list though + --tagscc +Same as tags, only that in this case CCs extracted from tags +are treated like CCs that have come from the *.patch file + --arg | -a ... +Arguments passed on to get_maintainer.pl +This option can be used multiple times, e.g. -a -a ... + --verbose +Show more output + --help | -h +Show this help information + +PROCESSING POLICY: +-- + *.patch files consist of several sections relevant to processing: + : This is the email header containing email related information + It ends with the Subject: line + : This is the body that ends up in the commit message + It ends with --- + <--->: This section contains the actual patches. CCs added here are + processed
[Xen-devel] [xen-unstable baseline-only test] 74668: regressions - FAIL
This run is configured for baseline tests only. flight 74668 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74668/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 22 leak-check/checkfail REGR. vs. 74651 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 74651 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74651 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74651 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74651 test-armhf-armhf-libvirt 12 guest-start fail like 74651 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74651 test-armhf-armhf-xl-rtds 12 guest-start fail like 74651 test-armhf-armhf-xl 12 guest-start fail like 74651 test-armhf-armhf-xl-xsm 12 guest-start fail like 74651 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74651 test-armhf-armhf-xl-credit2 12 guest-start fail like 74651 test-armhf-armhf-xl-midway 12 guest-start fail like 74651 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74651 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74651 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74651 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74651 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 74651 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 74651 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen eff2fbe4dd71b3e4fe2dbb2696882252c1cc7897 baseline version: xen 0d16ece0c5adb960ee4e45f12183bcac8fe6d50a Last test of basis74651 2018-04-30 10:50:18 Z3 days Testing same since74668 2018-05-03 12:22:29 Z0 days1 attempts People who touched revisions under test: Andrew CooperGeorge Dunlap Ian Jackson Jan Beulich Juergen Gross Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass