[Xen-devel] [xen-unstable-smoke test] 125850: trouble: blocked/broken/pass
flight 125850 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125850/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 2a3b34ec47817048ab59586855cf0709fc77487e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 36 attempts Testing same since 125846 2018-08-10 14:00:58 Z0 days3 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 640 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 125824: regressions - trouble: blocked/broken/fail/pass
flight 125824 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125824/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 124328 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail in 125799 pass in 125824 test-amd64-i386-xl-qemut-ws16-amd64 14 guest-localmigrate fail in 125799 pass in 125824 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail pass in 125799 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 125799 Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 124328 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 124328 build-arm64 2 hosts-allocate broken REGR. vs. 124328 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 124328 build-arm64-pvops 3 capture-logs broken blocked in 124328 build-arm64 3 capture-logs broken blocked in 124328 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 125799 blocked in 124328 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail in 125799 like 124248 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 125799 like 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124328 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124328 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124328 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 16:31 > To: Paul Durrant > Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org> > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 17:08, wrote: > >> -Original Message- > >> From: Andrew Cooper > >> Sent: 10 August 2018 13:56 > >> To: Paul Durrant ; 'Jan Beulich' > >> > >> Cc: xen-devel > >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > >> On 10/08/18 13:43, Paul Durrant wrote: > >> >> -Original Message- > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 10 August 2018 13:37 > >> >> To: Paul Durrant > >> >> Cc: xen-devel > >> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> >> > >> > On 10.08.18 at 14:22, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:13 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > >> >>> On 10.08.18 at 14:08, wrote: > >> >> -Original Message- > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 10 August 2018 13:02 > >> >> To: Paul Durrant > >> >> Cc: xen-devel > >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> >> > >> > On 10.08.18 at 12:37, wrote: > >> >>> These are probably both candidates for back-port. > >> >>> > >> >>> Paul Durrant (2): > >> >>> x86/hvm/ioreq: MMIO range checking completely ignores > >> direction > >> >> flag > >> >>> x86/hvm/emulate: make sure rep I/O emulation does not cross > >> GFN > >> >>> boundaries > >> >>> > >> >>> xen/arch/x86/hvm/emulate.c | 17 - > >> >>> xen/arch/x86/hvm/ioreq.c | 15 ++- > >> >>> 2 files changed, 26 insertions(+), 6 deletions(-) > >> >> I take it this isn't yet what we've talked about yesterday on irc? > >> >> > >> > This is the band-aid fix. I can now show correct handling of a rep > mov > >> > walking off MMIO into RAM. > >> But that's not the problem we're having. In our case the bad > behavior > >> is with a single MOV. That's why I had assumed that your plan to > fiddle > >> with null_handler would help in our case as well, while this series > >> clearly > >> won't (afaict). > >> > >> >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined > >> behaviour > >> >> though > >> >>> as I understand it. Am I incorrect? > >> >> I'm not aware of SDM or PM saying anything like this. Anyway, the > >> >> specific case where this is being observed as an issue is when > >> >> accessing the last few bytes of a normal RAM page followed by a > >> >> ballooned out one. The balloon driver doesn't remove the virtual > >> >> mapping of such pages (presumably in order to not shatter super > >> >> pages); observation is with the old XenoLinux one, but from code > >> >> inspection the upstream one behaves the same. > >> >> > >> >> Unless we want to change the balloon driver's behavior, at least > >> >> this specific case needs to be considered having defined behavior, > >> >> I think. > >> >> > >> > Ok. I'll see what I can do. > >> > >> It is a software error to try and cross boundaries. Modern processors > >> do their best to try and cause the correct behaviour to occur, albeit > >> with a massive disclaimer about the performance hit. Older processors > >> didn't cope. > >> > >> As far as I'm concerned, its fine to terminate a emulation which crosses > >> a boundary with the null ops. > > > > Alas we never even get as far as the I/O handlers in some circumstances... > > > > I just set up a variant of an XTF test doing a backwards rep movsd into a > > well aligned stack buffer where source buffer starts 1 byte before a > boundary > > between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) > detects that > > both the source and dest of the initial rep are RAM, skips over the I/O > > emulation calls, and then fails when the hvm_copy_from_guest_phys() > > (unsurprisingly) fails to grab the 8 bytes for the initial rep. > > So, any logic we add to deal with handling page spanning ops is going to > > have to go in at the top level of instruction emulation... which I fear is > > going to be quite a major change and not something that's going to be easy > to > > back-port. > > Well, wasn't it clear from the beginning that a proper fix would be too > invasive to backport? And wasn't it for that reason that you intended > to add a small hack first, to deal with just the case(s) that we currently > have issues with? Well, given that I mistakenly understood you were hitting the same rep issue that I was, I thought I could deal with it in a reasonably straightforward way. Maybe I can still do a point fix for what you are hitting though. What precisely are
Re: [Xen-devel] [PATCH] x86/hvm/viridian: set shutdown_code in response to CrashNotify
On 10/08/18 16:43, Paul Durrant wrote: > When Windows writes the CrashNotify bit in the CRASH_CTL MSR then we know > it is crashing, so set the domain shutdown code appropriately. > > Signed-off-by: Paul Durrant > --- > Cc: Jan Beulich > Cc: Andrew Cooper > --- > xen/arch/x86/hvm/viridian.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c > index 486065182c..294cf486cc 100644 > --- a/xen/arch/x86/hvm/viridian.c > +++ b/xen/arch/x86/hvm/viridian.c > @@ -645,6 +645,10 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val) > if ( !ctl.u.CrashNotify ) > break; > > +spin_lock(>shutdown_lock); > +d->shutdown_code = SHUTDOWN_crash; > +spin_unlock(>shutdown_lock); How does the domain eventually shut down? It feels slightly odd to have a shutdown code before the domain has finished executing code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125849: trouble: blocked/broken/pass
flight 125849 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125849/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 2a3b34ec47817048ab59586855cf0709fc77487e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 35 attempts Testing same since 125846 2018-08-10 14:00:58 Z0 days2 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 640 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125844: all pass - PUSHED
flight 125844 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125844/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 10ea1b6853f977ce4ed0193230ad7953edbb1894 baseline version: ovmf b3e1e343fe34d0173a53a61b10296e6522ce1f7c Last test of basis 125837 2018-08-10 03:49:38 Z0 days Testing same since 125844 2018-08-10 13:11:27 Z0 days1 attempts People who touched revisions under test: Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git b3e1e343fe..10ea1b6853 10ea1b6853f977ce4ed0193230ad7953edbb1894 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75061: tolerable FAIL
This run is configured for baseline tests only. flight 75061 ovmf real [real] http://osstest.xensource.com/osstest/logs/75061/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75060 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75060 version targeted for testing: ovmf 10ea1b6853f977ce4ed0193230ad7953edbb1894 baseline version: ovmf b3e1e343fe34d0173a53a61b10296e6522ce1f7c Last test of basis75060 2018-08-10 12:53:44 Z0 days Testing same since75061 2018-08-10 19:50:04 Z0 days1 attempts People who touched revisions under test: Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 10ea1b6853f977ce4ed0193230ad7953edbb1894 Author: Michael D Kinney Date: Thu Aug 9 14:09:15 2018 -0700 Maintainers.txt: Add FmpDevicePkg maintainers This patch adds maintainers for the FmpDevicePkg. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Star Zeng ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 125825: regressions - trouble: blocked/broken/fail/pass
flight 125825 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125825/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64 broken build-arm64-xsm broken build-arm64-pvops 3 capture-logs broken REGR. vs. 125658 test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 125658 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail REGR. vs. 125658 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken REGR. vs. 125658 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125658 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125658 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-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125658 build-arm64 3 capture-logs broken blocked in 125658 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125658 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail like 125658 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125658 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125658 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125658 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125658 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125658 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-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-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-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-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail 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
[Xen-devel] [PATCH] x86/hvm/viridian: set shutdown_code in response to CrashNotify
When Windows writes the CrashNotify bit in the CRASH_CTL MSR then we know it is crashing, so set the domain shutdown code appropriately. Signed-off-by: Paul Durrant --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/hvm/viridian.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c index 486065182c..294cf486cc 100644 --- a/xen/arch/x86/hvm/viridian.c +++ b/xen/arch/x86/hvm/viridian.c @@ -645,6 +645,10 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val) if ( !ctl.u.CrashNotify ) break; +spin_lock(>shutdown_lock); +d->shutdown_code = SHUTDOWN_crash; +spin_unlock(>shutdown_lock); + gprintk(XENLOG_WARNING, "VIRIDIAN CRASH: %lx %lx %lx %lx %lx\n", v->arch.hvm_vcpu.viridian.crash_param[0], v->arch.hvm_vcpu.viridian.crash_param[1], -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125846: trouble: blocked/broken/pass
flight 125846 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125846/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 2a3b34ec47817048ab59586855cf0709fc77487e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 34 attempts Testing same since 125846 2018-08-10 14:00:58 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 640 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>> On 10.08.18 at 17:08, wrote: >> -Original Message- >> From: Andrew Cooper >> Sent: 10 August 2018 13:56 >> To: Paul Durrant ; 'Jan Beulich' >> >> Cc: xen-devel >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> On 10/08/18 13:43, Paul Durrant wrote: >> >> -Original Message- >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 10 August 2018 13:37 >> >> To: Paul Durrant >> >> Cc: xen-devel >> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> > On 10.08.18 at 14:22, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:13 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >>> On 10.08.18 at 14:08, wrote: >> >> -Original Message- >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 10 August 2018 13:02 >> >> To: Paul Durrant >> >> Cc: xen-devel >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> > On 10.08.18 at 12:37, wrote: >> >>> These are probably both candidates for back-port. >> >>> >> >>> Paul Durrant (2): >> >>> x86/hvm/ioreq: MMIO range checking completely ignores >> direction >> >> flag >> >>> x86/hvm/emulate: make sure rep I/O emulation does not cross >> GFN >> >>> boundaries >> >>> >> >>> xen/arch/x86/hvm/emulate.c | 17 - >> >>> xen/arch/x86/hvm/ioreq.c | 15 ++- >> >>> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> I take it this isn't yet what we've talked about yesterday on irc? >> >> >> > This is the band-aid fix. I can now show correct handling of a rep mov >> > walking off MMIO into RAM. >> But that's not the problem we're having. In our case the bad behavior >> is with a single MOV. That's why I had assumed that your plan to fiddle >> with null_handler would help in our case as well, while this series >> clearly >> won't (afaict). >> >> >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined >> behaviour >> >> though >> >>> as I understand it. Am I incorrect? >> >> I'm not aware of SDM or PM saying anything like this. Anyway, the >> >> specific case where this is being observed as an issue is when >> >> accessing the last few bytes of a normal RAM page followed by a >> >> ballooned out one. The balloon driver doesn't remove the virtual >> >> mapping of such pages (presumably in order to not shatter super >> >> pages); observation is with the old XenoLinux one, but from code >> >> inspection the upstream one behaves the same. >> >> >> >> Unless we want to change the balloon driver's behavior, at least >> >> this specific case needs to be considered having defined behavior, >> >> I think. >> >> >> > Ok. I'll see what I can do. >> >> It is a software error to try and cross boundaries. Modern processors >> do their best to try and cause the correct behaviour to occur, albeit >> with a massive disclaimer about the performance hit. Older processors >> didn't cope. >> >> As far as I'm concerned, its fine to terminate a emulation which crosses >> a boundary with the null ops. > > Alas we never even get as far as the I/O handlers in some circumstances... > > I just set up a variant of an XTF test doing a backwards rep movsd into a > well aligned stack buffer where source buffer starts 1 byte before a boundary > between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) detects that > both the source and dest of the initial rep are RAM, skips over the I/O > emulation calls, and then fails when the hvm_copy_from_guest_phys() > (unsurprisingly) fails to grab the 8 bytes for the initial rep. > So, any logic we add to deal with handling page spanning ops is going to > have to go in at the top level of instruction emulation... which I fear is > going to be quite a major change and not something that's going to be easy to > back-port. Well, wasn't it clear from the beginning that a proper fix would be too invasive to backport? And wasn't it for that reason that you intended to add a small hack first, to deal with just the case(s) that we currently have issues with? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
On 08/10/2018 05:00 PM, Jan Beulich wrote: On 10.08.18 at 17:35, wrote: >>> -Original Message- >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> Sent: 10 August 2018 16:31 >>> To: Paul Durrant >>> Cc: Andrew Cooper ; xen-devel >> de...@lists.xenproject.org> >>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> >> On 10.08.18 at 17:08, wrote: > -Original Message- > From: Andrew Cooper > Sent: 10 August 2018 13:56 > To: Paul Durrant ; 'Jan Beulich' > > Cc: xen-devel > Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > On 10/08/18 13:43, Paul Durrant wrote: >>> -Original Message- >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> Sent: 10 August 2018 13:37 >>> To: Paul Durrant >>> Cc: xen-devel >>> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> >> On 10.08.18 at 14:22, wrote: > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:13 > To: Paul Durrant > Cc: xen-devel > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > On 10.08.18 at 14:08, wrote: >>> -Original Message- >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> Sent: 10 August 2018 13:02 >>> To: Paul Durrant >>> Cc: xen-devel >>> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> >> On 10.08.18 at 12:37, wrote: These are probably both candidates for back-port. Paul Durrant (2): x86/hvm/ioreq: MMIO range checking completely ignores > direction >>> flag x86/hvm/emulate: make sure rep I/O emulation does not cross > GFN boundaries xen/arch/x86/hvm/emulate.c | 17 - xen/arch/x86/hvm/ioreq.c | 15 ++- 2 files changed, 26 insertions(+), 6 deletions(-) >>> I take it this isn't yet what we've talked about yesterday on irc? >>> >> This is the band-aid fix. I can now show correct handling of a rep >>> mov >> walking off MMIO into RAM. > But that's not the problem we're having. In our case the bad >>> behavior > is with a single MOV. That's why I had assumed that your plan to >>> fiddle > with null_handler would help in our case as well, while this series > clearly > won't (afaict). > Oh, I see. A single MOV spanning MMIO and RAM has undefined > behaviour >>> though as I understand it. Am I incorrect? >>> I'm not aware of SDM or PM saying anything like this. Anyway, the >>> specific case where this is being observed as an issue is when >>> accessing the last few bytes of a normal RAM page followed by a >>> ballooned out one. The balloon driver doesn't remove the virtual >>> mapping of such pages (presumably in order to not shatter super >>> pages); observation is with the old XenoLinux one, but from code >>> inspection the upstream one behaves the same. >>> >>> Unless we want to change the balloon driver's behavior, at least >>> this specific case needs to be considered having defined behavior, >>> I think. >>> >> Ok. I'll see what I can do. > > It is a software error to try and cross boundaries. Modern processors > do their best to try and cause the correct behaviour to occur, albeit > with a massive disclaimer about the performance hit. Older processors > didn't cope. > > As far as I'm concerned, its fine to terminate a emulation which crosses > a boundary with the null ops. Alas we never even get as far as the I/O handlers in some circumstances... I just set up a variant of an XTF test doing a backwards rep movsd into a well aligned stack buffer where source buffer starts 1 byte before a >>> boundary between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) >>> detects that both the source and dest of the initial rep are RAM, skips over the I/O emulation calls, and then fails when the hvm_copy_from_guest_phys() (unsurprisingly) fails to grab the 8 bytes for the initial rep. So, any logic we add to deal with handling page spanning ops is going to have to go in at the top level of instruction emulation... which I fear is going to be quite a major change and not something that's going to be easy >>> to back-port. >>> >>> Well, wasn't it clear from the beginning that a proper fix would be too >>> invasive to backport? And wasn't it for that reason that you intended >>> to add a small hack first, to deal with just the case(s) that we currently >>> have issues with? >> >> Well, given that I mistakenly understood you were hitting the same rep issue >> that I
Re: [Xen-devel] [PATCH] x86/hvm/viridian: set shutdown_code in response to CrashNotify
> -Original Message- > From: Andrew Cooper > Sent: 10 August 2018 16:57 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Jan Beulich > Subject: Re: [PATCH] x86/hvm/viridian: set shutdown_code in response to > CrashNotify > > On 10/08/18 16:43, Paul Durrant wrote: > > When Windows writes the CrashNotify bit in the CRASH_CTL MSR then we > know > > it is crashing, so set the domain shutdown code appropriately. > > > > Signed-off-by: Paul Durrant > > --- > > Cc: Jan Beulich > > Cc: Andrew Cooper > > --- > > xen/arch/x86/hvm/viridian.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c > > index 486065182c..294cf486cc 100644 > > --- a/xen/arch/x86/hvm/viridian.c > > +++ b/xen/arch/x86/hvm/viridian.c > > @@ -645,6 +645,10 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val) > > if ( !ctl.u.CrashNotify ) > > break; > > > > +spin_lock(>shutdown_lock); > > +d->shutdown_code = SHUTDOWN_crash; > > +spin_unlock(>shutdown_lock); > > How does the domain eventually shut down? I assume it shuts down when the guest writes to the PIIX. > It feels slightly odd to have > a shutdown code before the domain has finished executing code. > That's the norm. The PV drivers (if they are installed) set it via a schedop. This just makes sure it is set even if the PV drivers aren't there. Paul > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75060: tolerable FAIL
This run is configured for baseline tests only. flight 75060 ovmf real [real] http://osstest.xensource.com/osstest/logs/75060/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75057 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75057 version targeted for testing: ovmf b3e1e343fe34d0173a53a61b10296e6522ce1f7c baseline version: ovmf 3781f14c31e00f4f1a195c7ad427be4f84f5cdf5 Last test of basis75057 2018-08-10 03:50:07 Z0 days Testing same since75060 2018-08-10 12:53:44 Z0 days1 attempts People who touched revisions under test: Zhang, Chao B jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit b3e1e343fe34d0173a53a61b10296e6522ce1f7c Author: Zhang, Chao B Date: Thu Aug 9 14:01:44 2018 +0800 SecurityPkg: HashLib: Update HashLib file GUID 2 file GUIDs conflict with existing SHA256 Lib. Update them. Cc: Long Qin Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhang, Chao B Reviewed-by: Long, Qin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 125820: regressions - trouble: blocked/broken/fail/pass
flight 125820 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125820/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvopsbroken build-arm64-xsm broken build-armhf-libvirt 6 libvirt-build fail in 125795 REGR. vs. 125183 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail in 125795 pass in 125820 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 125795 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 14 guest-localmigrate fail pass in 125795 Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125183 build-arm64 2 hosts-allocate broken REGR. vs. 125183 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125183 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 1 build-check(1) blocked in 125795 n/a test-armhf-armhf-libvirt 1 build-check(1) blocked in 125795 n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125183 build-arm64 3 capture-logs broken blocked in 125183 build-arm64-pvops 3 capture-logs broken blocked in 125183 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125183 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125183 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125183 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-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-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
> -Original Message- > From: Andrew Cooper > Sent: 10 August 2018 13:56 > To: Paul Durrant ; 'Jan Beulich' > > Cc: xen-devel > Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > On 10/08/18 13:43, Paul Durrant wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:37 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > > On 10.08.18 at 14:22, wrote: > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:13 > To: Paul Durrant > Cc: xen-devel > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 14:08, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:02 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > > On 10.08.18 at 12:37, wrote: > >>> These are probably both candidates for back-port. > >>> > >>> Paul Durrant (2): > >>> x86/hvm/ioreq: MMIO range checking completely ignores > direction > >> flag > >>> x86/hvm/emulate: make sure rep I/O emulation does not cross > GFN > >>> boundaries > >>> > >>> xen/arch/x86/hvm/emulate.c | 17 - > >>> xen/arch/x86/hvm/ioreq.c | 15 ++- > >>> 2 files changed, 26 insertions(+), 6 deletions(-) > >> I take it this isn't yet what we've talked about yesterday on irc? > >> > > This is the band-aid fix. I can now show correct handling of a rep mov > > walking off MMIO into RAM. > But that's not the problem we're having. In our case the bad behavior > is with a single MOV. That's why I had assumed that your plan to fiddle > with null_handler would help in our case as well, while this series > clearly > won't (afaict). > > >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined > behaviour > >> though > >>> as I understand it. Am I incorrect? > >> I'm not aware of SDM or PM saying anything like this. Anyway, the > >> specific case where this is being observed as an issue is when > >> accessing the last few bytes of a normal RAM page followed by a > >> ballooned out one. The balloon driver doesn't remove the virtual > >> mapping of such pages (presumably in order to not shatter super > >> pages); observation is with the old XenoLinux one, but from code > >> inspection the upstream one behaves the same. > >> > >> Unless we want to change the balloon driver's behavior, at least > >> this specific case needs to be considered having defined behavior, > >> I think. > >> > > Ok. I'll see what I can do. > > It is a software error to try and cross boundaries. Modern processors > do their best to try and cause the correct behaviour to occur, albeit > with a massive disclaimer about the performance hit. Older processors > didn't cope. > > As far as I'm concerned, its fine to terminate a emulation which crosses > a boundary with the null ops. Alas we never even get as far as the I/O handlers in some circumstances... I just set up a variant of an XTF test doing a backwards rep movsd into a well aligned stack buffer where source buffer starts 1 byte before a boundary between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) detects that both the source and dest of the initial rep are RAM, skips over the I/O emulation calls, and then fails when the hvm_copy_from_guest_phys() (unsurprisingly) fails to grab the 8 bytes for the initial rep. So, any logic we add to deal with handling page spanning ops is going to have to go in at the top level of instruction emulation... which I fear is going to be quite a major change and not something that's going to be easy to back-port. Paul > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>> On 10.08.18 at 17:35, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 16:31 >> To: Paul Durrant >> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >>> On 10.08.18 at 17:08, wrote: >> >> -Original Message- >> >> From: Andrew Cooper >> >> Sent: 10 August 2018 13:56 >> >> To: Paul Durrant ; 'Jan Beulich' >> >> >> >> Cc: xen-devel >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> >> On 10/08/18 13:43, Paul Durrant wrote: >> >> >> -Original Message- >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> >> Sent: 10 August 2018 13:37 >> >> >> To: Paul Durrant >> >> >> Cc: xen-devel >> >> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> >> >> > On 10.08.18 at 14:22, wrote: >> >> -Original Message- >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 10 August 2018 13:13 >> >> To: Paul Durrant >> >> Cc: xen-devel >> >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> >> >>> On 10.08.18 at 14:08, wrote: >> >> >> -Original Message- >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> >> Sent: 10 August 2018 13:02 >> >> >> To: Paul Durrant >> >> >> Cc: xen-devel >> >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> >> >> > On 10.08.18 at 12:37, wrote: >> >> >>> These are probably both candidates for back-port. >> >> >>> >> >> >>> Paul Durrant (2): >> >> >>> x86/hvm/ioreq: MMIO range checking completely ignores >> >> direction >> >> >> flag >> >> >>> x86/hvm/emulate: make sure rep I/O emulation does not cross >> >> GFN >> >> >>> boundaries >> >> >>> >> >> >>> xen/arch/x86/hvm/emulate.c | 17 - >> >> >>> xen/arch/x86/hvm/ioreq.c | 15 ++- >> >> >>> 2 files changed, 26 insertions(+), 6 deletions(-) >> >> >> I take it this isn't yet what we've talked about yesterday on irc? >> >> >> >> >> > This is the band-aid fix. I can now show correct handling of a rep >> mov >> >> > walking off MMIO into RAM. >> >> But that's not the problem we're having. In our case the bad >> behavior >> >> is with a single MOV. That's why I had assumed that your plan to >> fiddle >> >> with null_handler would help in our case as well, while this series >> >> clearly >> >> won't (afaict). >> >> >> >> >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined >> >> behaviour >> >> >> though >> >> >>> as I understand it. Am I incorrect? >> >> >> I'm not aware of SDM or PM saying anything like this. Anyway, the >> >> >> specific case where this is being observed as an issue is when >> >> >> accessing the last few bytes of a normal RAM page followed by a >> >> >> ballooned out one. The balloon driver doesn't remove the virtual >> >> >> mapping of such pages (presumably in order to not shatter super >> >> >> pages); observation is with the old XenoLinux one, but from code >> >> >> inspection the upstream one behaves the same. >> >> >> >> >> >> Unless we want to change the balloon driver's behavior, at least >> >> >> this specific case needs to be considered having defined behavior, >> >> >> I think. >> >> >> >> >> > Ok. I'll see what I can do. >> >> >> >> It is a software error to try and cross boundaries. Modern processors >> >> do their best to try and cause the correct behaviour to occur, albeit >> >> with a massive disclaimer about the performance hit. Older processors >> >> didn't cope. >> >> >> >> As far as I'm concerned, its fine to terminate a emulation which crosses >> >> a boundary with the null ops. >> > >> > Alas we never even get as far as the I/O handlers in some circumstances... >> > >> > I just set up a variant of an XTF test doing a backwards rep movsd into a >> > well aligned stack buffer where source buffer starts 1 byte before a >> boundary >> > between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) >> detects that >> > both the source and dest of the initial rep are RAM, skips over the I/O >> > emulation calls, and then fails when the hvm_copy_from_guest_phys() >> > (unsurprisingly) fails to grab the 8 bytes for the initial rep. >> > So, any logic we add to deal with handling page spanning ops is going to >> > have to go in at the top level of instruction emulation... which I fear is >> > going to be quite a major change and not something that's going to be easy >> to >> > back-port. >> >> Well, wasn't it clear from the beginning that a proper fix would be too >> invasive to backport? And wasn't it for that reason that you intended >> to add a small hack first, to deal with just the case(s) that we currently >> have issues with? > > Well, given that I mistakenly understood you were hitting the same rep issue > that I was,
Re: [Xen-devel] [PATCH 06/10] x86/paravirt: introduce new config option PARAVIRT_XXL
On 10/08/18 16:22, Boris Ostrovsky wrote: > On 08/10/2018 07:52 AM, Juergen Gross wrote: >> A large amount of paravirt ops is used by Xen PV guests only. Add a new >> config option PARAVIRT_XXL which is selected by XEN_PV. Later we can >> put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. > > What does "XXL" stand for? My immediate thought was "extra extra large" > but I suspect it's something else. No, your immediate thought was correct. :-) Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 06/10] x86/paravirt: introduce new config option PARAVIRT_XXL
On 08/10/2018 07:52 AM, Juergen Gross wrote: > A large amount of paravirt ops is used by Xen PV guests only. Add a new > config option PARAVIRT_XXL which is selected by XEN_PV. Later we can > put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. What does "XXL" stand for? My immediate thought was "extra extra large" but I suspect it's something else. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee that. This is something that should almost certainly be fixed,
but in the meantime this patch makes sure that MMIO is truncated at GFN
boundaries and hence the appropriate device model is re-evaluated for each
target GFN.
NOTE: This patch does not deal with the case of a single MMIO operation
spanning a GFN boundary. That is more complex to deal with and is
deferred to a subsequent patch.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
v2:
- Cosmetic fixes suggested by Andrew.
- Make sure we don't end up with p.count == 0, and make sure we end
up with p.count == 1 where a single op spans a GFN boundary.
---
xen/arch/x86/hvm/emulate.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 8385c62145..602c21ce2a 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -184,6 +184,25 @@ static int hvmemul_do_io(
hvmtrace_io_assist();
}
+/*
+ * Make sure that we truncate rep MMIO at any GFN boundary. This is
+ * necessary to ensure that the correct device model is targetted
+ * or that we correctly handle a rep op spanning MMIO and RAM.
+ */
+if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
+{
+unsigned long off = p.addr & ~PAGE_MASK;
+
+if ( PAGE_SIZE - off < p.size ) /* single rep spans GFN */
+p.count = 1;
+else
+p.count = min_t(unsigned long,
+p.count,
+((p.df ? (off + p.size) : (PAGE_SIZE - off)) /
+ p.size));
+}
+ASSERT(p.count);
+
vio->io_req = p;
rc = hvm_io_intercept();
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/2] MMIO emulation fixes
These are probably both candidates for back-port. Paul Durrant (2): x86/hvm/ioreq: MMIO range checking completely ignores direction flag x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries xen/arch/x86/hvm/emulate.c | 19 +++ xen/arch/x86/hvm/ioreq.c | 15 ++- 2 files changed, 29 insertions(+), 5 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/2] x86/hvm/ioreq: MMIO range checking completely ignores direction flag
hvm_select_ioreq_server() is used to route an ioreq to the appropriate
ioreq server. For MMIO this is done by comparing the range of the ioreq
to the ranges registered by the device models of each ioreq server.
Unfortunately the calculation of the range if the ioreq completely ignores
the direction flag and thus may calculate the wrong range for comparison.
Thus the ioreq may either be routed to the wrong server or erroneously
terminated by null_ops.
NOTE: The patch also fixes whitespace in the switch statement to make it
style compliant.
Signed-off-by: Paul Durrant
Reviewed-by: Andrew Cooper
---
Cc: Jan Beulich
---
xen/arch/x86/hvm/ioreq.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 7c515b3ef7..940a2c9728 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1353,20 +1353,25 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct
domain *d,
switch ( type )
{
-unsigned long end;
+unsigned long start, end;
case XEN_DMOP_IO_RANGE_PORT:
-end = addr + p->size - 1;
-if ( rangeset_contains_range(r, addr, end) )
+start = addr;
+end = start + p->size - 1;
+if ( rangeset_contains_range(r, start, end) )
return s;
break;
+
case XEN_DMOP_IO_RANGE_MEMORY:
-end = addr + (p->size * p->count) - 1;
-if ( rangeset_contains_range(r, addr, end) )
+start = hvm_mmio_first_byte(p);
+end = hvm_mmio_last_byte(p);
+
+if ( rangeset_contains_range(r, start, end) )
return s;
break;
+
case XEN_DMOP_IO_RANGE_PCI:
if ( rangeset_contains_singleton(r, addr >> 32) )
{
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
On 10/08/18 17:30, George Dunlap wrote: > On 08/10/2018 05:00 PM, Jan Beulich wrote: > On 10.08.18 at 17:35, wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 10 August 2018 16:31 To: Paul Durrant Cc: Andrew Cooper ; xen-devel >>> de...@lists.xenproject.org> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> On 10.08.18 at 17:08, wrote: >> -Original Message- >> From: Andrew Cooper >> Sent: 10 August 2018 13:56 >> To: Paul Durrant ; 'Jan Beulich' >> >> Cc: xen-devel >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> On 10/08/18 13:43, Paul Durrant wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 10 August 2018 13:37 To: Paul Durrant Cc: xen-devel Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> On 10.08.18 at 14:22, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:13 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> > On 10.08.18 at 14:08, wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 10 August 2018 13:02 To: Paul Durrant Cc: xen-devel Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> On 10.08.18 at 12:37, wrote: > These are probably both candidates for back-port. > > Paul Durrant (2): > x86/hvm/ioreq: MMIO range checking completely ignores >> direction flag > x86/hvm/emulate: make sure rep I/O emulation does not cross >> GFN > boundaries > > xen/arch/x86/hvm/emulate.c | 17 - > xen/arch/x86/hvm/ioreq.c | 15 ++- > 2 files changed, 26 insertions(+), 6 deletions(-) I take it this isn't yet what we've talked about yesterday on irc? >>> This is the band-aid fix. I can now show correct handling of a rep mov >>> walking off MMIO into RAM. >> But that's not the problem we're having. In our case the bad behavior >> is with a single MOV. That's why I had assumed that your plan to fiddle >> with null_handler would help in our case as well, while this series >> clearly >> won't (afaict). >> > Oh, I see. A single MOV spanning MMIO and RAM has undefined >> behaviour though > as I understand it. Am I incorrect? I'm not aware of SDM or PM saying anything like this. Anyway, the specific case where this is being observed as an issue is when accessing the last few bytes of a normal RAM page followed by a ballooned out one. The balloon driver doesn't remove the virtual mapping of such pages (presumably in order to not shatter super pages); observation is with the old XenoLinux one, but from code inspection the upstream one behaves the same. Unless we want to change the balloon driver's behavior, at least this specific case needs to be considered having defined behavior, I think. >>> Ok. I'll see what I can do. >> It is a software error to try and cross boundaries. Modern processors >> do their best to try and cause the correct behaviour to occur, albeit >> with a massive disclaimer about the performance hit. Older processors >> didn't cope. >> >> As far as I'm concerned, its fine to terminate a emulation which crosses >> a boundary with the null ops. > Alas we never even get as far as the I/O handlers in some circumstances... > > I just set up a variant of an XTF test doing a backwards rep movsd into a > well aligned stack buffer where source buffer starts 1 byte before a boundary > between RAM and MMIO. The code in hvmemul_rep_movs() (rightly) detects that > both the source and dest of the initial rep are RAM, skips over the I/O > emulation calls, and then fails when the hvm_copy_from_guest_phys() > (unsurprisingly) fails to grab the 8 bytes for the initial rep. > So, any logic we add to deal with handling page spanning ops is going to > have to go in at the top level of instruction emulation... which I fear is > going to be quite a major change and not something that's going to be easy to > back-port. Well, wasn't it clear from the beginning that a proper fix would be too invasive to backport? And wasn't it for that reason that you intended to add a small hack first, to deal with just the
[Xen-devel] [linux-linus test] 125818: regressions - trouble: blocked/broken/fail/pass
flight 125818 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125818/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64 broken build-arm64-pvopsbroken test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125702 Regressions which are regarded as allowable (not blocking): build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125702 build-arm64 2 hosts-allocate broken REGR. vs. 125702 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125702 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 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 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 125702 build-arm64-pvops 3 capture-logs broken blocked in 125702 build-arm64-xsm 3 capture-logs broken blocked in 125702 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125702 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125702 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125702 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125702 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125702 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125702 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-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 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass version targeted for testing: linuxfedb8da96355f5f64353625bf96dc69423ad1826 baseline version: linux
[Xen-devel] [PATCH] x86/ptwr: Misc cleanup to ptwr_emulated_update()
All but one user wants mfn as mfn_t, so switch its type. offset is only ever
used when multipled by 8, so fold that into its initial calculation. Fold all
the pointer arithmic on pl1e together, to avoid needless casts.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/ro-page-fault.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c
index aa8d5a7..efb5c1a 100644
--- a/xen/arch/x86/pv/ro-page-fault.c
+++ b/xen/arch/x86/pv/ro-page-fault.c
@@ -67,7 +67,7 @@ static int ptwr_emulated_update(unsigned long addr, intpte_t
*p_old,
intpte_t val, unsigned int bytes,
struct x86_emulate_ctxt *ctxt)
{
-unsigned long mfn;
+mfn_t mfn;
unsigned long unaligned_addr = addr;
struct page_info *page;
l1_pgentry_t pte, ol1e, nl1e, *pl1e;
@@ -93,7 +93,7 @@ static int ptwr_emulated_update(unsigned long addr, intpte_t
*p_old,
intpte_t full;
unsigned int rc;
-offset = addr & (sizeof(full) - 1);
+offset = (addr & (sizeof(full) - 1)) * 8;
/* Align address; read full word. */
addr &= ~(sizeof(full) - 1);
@@ -105,24 +105,24 @@ static int ptwr_emulated_update(unsigned long addr,
intpte_t *p_old,
return X86EMUL_EXCEPTION;
}
/* Mask out bits provided by caller. */
-full &= ~intpte_t)1 << (bytes * 8)) - 1) << (offset * 8));
+full &= ~intpte_t)1 << (bytes * 8)) - 1) << offset);
/* Shift the caller value and OR in the missing bits. */
val &= (((intpte_t)1 << (bytes * 8)) - 1);
-val <<= (offset) * 8;
+val <<= offset;
val |= full;
/* Also fill in missing parts of the cmpxchg old value. */
old &= (((intpte_t)1 << (bytes * 8)) - 1);
-old <<= (offset) * 8;
+old <<= offset;
old |= full;
}
pte = ptwr_ctxt->pte;
-mfn = l1e_get_pfn(pte);
-page = mfn_to_page(_mfn(mfn));
+mfn = l1e_get_mfn(pte);
+page = mfn_to_page(mfn);
/* We are looking only for read-only mappings of p.t. pages. */
ASSERT((l1e_get_flags(pte) & (_PAGE_RW|_PAGE_PRESENT)) == _PAGE_PRESENT);
-ASSERT(mfn_valid(_mfn(mfn)));
+ASSERT(mfn_valid(mfn));
ASSERT((page->u.inuse.type_info & PGT_type_mask) == PGT_l1_page_table);
ASSERT((page->u.inuse.type_info & PGT_count_mask) != 0);
ASSERT(page_get_owner(page) == d);
@@ -162,20 +162,18 @@ static int ptwr_emulated_update(unsigned long addr,
intpte_t *p_old,
nl1e = adjust_guest_l1e(nl1e, d);
/* Checked successfully: do the update (write or cmpxchg). */
-pl1e = map_domain_page(_mfn(mfn));
-pl1e = (l1_pgentry_t *)((unsigned long)pl1e + (addr & ~PAGE_MASK));
+pl1e = map_domain_page(mfn) + (addr & ~PAGE_MASK);
if ( p_old )
{
-
ol1e = l1e_from_intpte(old);
if ( !paging_cmpxchg_guest_entry(v, _get_intpte(*pl1e),
- , l1e_get_intpte(nl1e),
_mfn(mfn)) )
+ , l1e_get_intpte(nl1e), mfn) )
ret = X86EMUL_UNHANDLEABLE;
else if ( l1e_get_intpte(ol1e) == old )
ret = X86EMUL_OKAY;
else
{
-*p_old = old >> (offset * 8);
+*p_old = old >> offset;
ret = X86EMUL_CMPXCHG_FAILED;
}
@@ -189,7 +187,7 @@ static int ptwr_emulated_update(unsigned long addr,
intpte_t *p_old,
else
{
ol1e = *pl1e;
-if ( !UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, mfn, v, 0) )
+if ( !UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, mfn_x(mfn), v, 0) )
BUG();
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125853: trouble: blocked/broken/pass
flight 125853 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125853/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 2a3b34ec47817048ab59586855cf0709fc77487e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 37 attempts Testing same since 125846 2018-08-10 14:00:58 Z0 days4 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 640 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125855: trouble: blocked/broken/pass
flight 125855 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125855/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 2a3b34ec47817048ab59586855cf0709fc77487e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 38 attempts Testing same since 125846 2018-08-10 14:00:58 Z0 days5 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 640 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/6] zynqmp: Add forwarding of platform specific firmware calls
Hi all, This patch is an update over this old patch series: https://marc.info/?l=xen-devel=148579695530482 I inherited the seriest from Edgar, I made significant changes over the old version, including addressing (almost) all comments. The main changes are: - split the largest patch into multiple smaller patches - remove all #defines and enum entries which aren't required - always specify .size in pm_mmio_access - always specify either .hwdom_access or .node in pm_mmio_access - remove NODE_UNKNOWN - simplify domain_has_mmio_access, assuming that addresses only match one entry - use arm_smccc_1_1_smc and set/get_user_reg Cheers, Stefano The following changes since commit 6aaa9fb308171ec58ddf4cf058ad5341f81a65cf: hvm/altp2m: Clarify the proper way to extend the altp2m interface (2018-07-31 16:14:01 +0100) are available in the git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git zynqmp-v3 for you to fetch changes up to a94ee86ff3e37e332a8f22a756f2978e10b5e2a8: xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node (2018-08-10 14:48:02 -0700) Edgar E. Iglesias (6): xen/arm: introduce platform_smc xen/arm: zynqmp: Forward plaform specific firmware calls xen/arm: zynqmp: introduce zynqmp specific defines xen/arm: zynqmp: eemi access control xen/arm: zynqmp: implement zynqmp_eemi xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node xen/arch/arm/platform.c| 8 + xen/arch/arm/platforms/Makefile| 1 + xen/arch/arm/platforms/xilinx-zynqmp-eemi.c| 962 + xen/arch/arm/platforms/xilinx-zynqmp.c | 18 +- xen/arch/arm/vsmc.c| 4 + xen/include/asm-arm/platform.h | 3 + xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 386 + 7 files changed, 1376 insertions(+), 6 deletions(-) create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c create mode 100644 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 5/8] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files
From: Zhongze Liu
Author: Zhongze Liu
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by: Zhongze Liu
Signed-off-by: Stefano Stabellini
Cc: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- remove alignment checks, they were moved to libxl
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxlu_sshm.c | 207 ++
tools/libxl/libxlutil.h | 6 ++
tools/xl/xl_parse.c | 25 +-
4 files changed, 238 insertions(+), 2 deletions(-)
create mode 100644 tools/libxl/libxlu_sshm.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 53af186..f3de189 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -177,7 +177,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
_paths.h \
AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
- libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
+ libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o libxlu_sshm.o
$(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
$(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog)
$(CFLAGS_libxentoolcore)
diff --git a/tools/libxl/libxlu_sshm.c b/tools/libxl/libxlu_sshm.c
new file mode 100644
index 000..cc709a7
--- /dev/null
+++ b/tools/libxl/libxlu_sshm.c
@@ -0,0 +1,207 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
+#include "libxlu_internal.h"
+#include "xenctrl.h"
+
+#include
+
+#define PARAM_RE(EXPR) "^\\s*" EXPR "\\s*(,|$)"
+#define WORD_RE "([_a-zA-Z0-9]+)"
+#define EQU_RE PARAM_RE(WORD_RE "\\s*=\\s*" WORD_RE)
+
+#define RET_INVAL(msg, curr_str) do { \
+xlu__sshm_err(cfg, msg, curr_str); \
+rc = EINVAL;\
+goto out; \
+} while(0)
+
+/* set a member in libxl_static_shm and report an error if it's respecified,
+ * @curr_str indicates the head of the remaining string. */
+#define SET_VAL(var, name, type, value, curr_str) do { \
+if ((var) != LIBXL_SSHM_##type##_UNKNOWN && (var) != value) { \
+RET_INVAL("\"" name "\" respecified", curr_str);\
+} \
+(var) = value; \
+} while(0)
+
+
+static void xlu__sshm_err(XLU_Config *cfg, const char *msg,
+ const char *curr_str) {
+fprintf(cfg->report,
+"%s: config parsing error in shared_memory: %s at '%s'\n",
+cfg->config_source, msg, curr_str);
+}
+
+static int parse_prot(XLU_Config *cfg, char *str, libxl_sshm_prot *prot)
+{
+int rc;
+libxl_sshm_prot new_prot;
+
+if (!strcmp(str, "rw")) {
+new_prot = LIBXL_SSHM_PROT_RW;
+} else {
+RET_INVAL("invalid permission flags", str);
+}
+
+SET_VAL(*prot, "permission flags", PROT, new_prot, str);
+
+rc = 0;
+
+ out:
+return rc;
+}
+
+static int parse_cachepolicy(XLU_Config *cfg, char *str,
+ libxl_sshm_cachepolicy *policy)
+{
+int rc;
+libxl_sshm_cachepolicy new_policy;
+
+if (!strcmp(str, "ARM_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+} else if (!strcmp(str, "x86_normal")) {
+new_policy = LIBXL_SSHM_CACHEPOLICY_X86_NORMAL;
+} else {
+RET_INVAL("invalid cache policy", str);
+}
+
+SET_VAL(*policy, "cache policy", CACHEPOLICY, new_policy, str);
+rc = 0;
+
+ out:
+return rc;
+}
+
+/* handle key = value pairs */
+static int handle_equ(XLU_Config *cfg, char *key, char *val,
+ libxl_static_shm *sshm)
+{
+int rc;
+
+if (!strcmp(key, "id")) {
+if (strlen(val) > LIBXL_SSHM_ID_MAXLEN) { RET_INVAL("id too long",
val); }
+if (sshm->id && !strcmp(sshm->id, val)) {
+RET_INVAL("id respecified", val);
+}
+
+sshm->id = strdup(val);
+if (!sshm->id) {
+fprintf(stderr, "sshm parser out of memory\n");
+rc = ENOMEM;
+goto out;
+}
+} else if (!strcmp(key, "role")) {
+libxl_sshm_role new_role;
+
+if (!strcmp("master", val)) {
+new_role = LIBXL_SSHM_ROLE_MASTER;
+} else if (!strcmp("slave", val)) {
+new_role = LIBXL_SSHM_ROLE_SLAVE;
+} else {
+RET_INVAL("invalid role", val);
+}
+
+
[Xen-devel] [PATCH v7 6/8] docs: documentation about static shared memory regions
From: Zhongze Liu Author: Zhongze Liu Add docs to document the motivation, usage, use cases and other relevant information about the static shared memory feature. This is for the proposal "Allow setting up shared memory areas between VMs from xl config file". See: https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html Signed-off-by: Zhongze Liu Signed-off-by: Stefano Stabellini Cc: Ian Jackson Cc: Wei Liu Cc: Stefano Stabellini Cc: Julien Grall Cc: xen-de...@lists.xen.org --- Changes in v6: - add clarifications on memory allocation Changes in v5: - fix typos --- docs/man/xl-static-shm-configuration.pod.5 | 264 + docs/man/xl.cfg.pod.5.in | 8 + docs/misc/xenstore-paths.markdown | 47 + 3 files changed, 319 insertions(+) create mode 100644 docs/man/xl-static-shm-configuration.pod.5 diff --git a/docs/man/xl-static-shm-configuration.pod.5 b/docs/man/xl-static-shm-configuration.pod.5 new file mode 100644 index 000..81ff3f1 --- /dev/null +++ b/docs/man/xl-static-shm-configuration.pod.5 @@ -0,0 +1,264 @@ +=head1 NAME + +xl-static-shm-configuration - XL Static Shared Memory Configuration Syntax + + +(B: This is currently only available to ARM guests.) + +=head1 DESCRIPTION + +The static_shm option allows users to statically setup shared memory regions +among a group of VMs, enabling guests without grant table support to do +shm-based communication. + +Every shared region is: + +=over 4 + +* Uniquely identified by a string that is no longer than 128 characters, which +is called an B in this document. + +* Backed by exactly one domain, which is called a B domain, and all +the other domains who are also sharing this region are called Bs. + +=back + +=head1 SYNTAX + +This document specifies syntax of the static shared memory configuration in +the xl config file. It has the following form: + +static_shm = [ "SSHM_SPEC", "SSHM_SPEC", ... ] + +where each C is in this form: + +[=,]* + +Valid examples of C are: + +id=ID1, begin=0x10, size=0x10, role=master, cache_policy=x86_normal +id=ID1, offset = 0, begin=0x50, size=0x10, role=slave, prot=rw +id=ID2, begin=0x30, size=0x10, role=master +id=ID2, offset = 0x1, begin=0x69, size=0x11, role=slave +id=ID2, offset = 0x1, begin=0x69, size=0x11, role=slave + +These might be specified in the domain config file like this: + +static_shm = ["id=ID2, offset = 0x1, begin=0x69, size=0x11, +role=slave"] + + +More formally, the string is a series of comma-separated keyword/value +pairs. Each parameter may be specified at most once. Default values apply if +the parameter is not specified. + +=head1 Parameters + +=over 4 + +=item B + +=over 4 + +=item Description + +The unique identifier of the shared memory region. + +Every identifier could appear only once in each xl config file. + +=item Supported values + +A string that contains alphanumerics and "_"s, and is no longer than 128 +characters. + +=item Default value + +None, this parameter is mandatory. + +=back + +=item B/B + +=over 4 + +=item Description + +The boundaries of the shared memory area. + +=item Supported values + +Same with B. + +=item Default Value + +None, this parameter is mandatory. + +=back + +=item B + +=over 4 + +=item Description + +Can only appear when B = slave. If set, the address mapping will not +start from the beginning the backing memory region, but from the middle +(B bytes away from the beginning) of it. See the graph below: + +With B = 0, the mapping will look like: + + backing memory region: # + | | + | | + | | + V V + slave's shared region: # + +With B > 0: + + backing memory region: # + |<-- offset -->|| | + | | + | | + V V + slave's memory region: # + +=item Supported values + +Decimals or hexadecimals with a prefix "0x", and should be the multiple of the +hypervisor page granularity (currently 4K on both ARM and x86). + +=item Default value + +0x0 + +=back + +=item B + +=over 4 + +=item Description + +The backing area would be taken from one domain, which we will mark as +the "master domain", and this domain should be created prior to any +other slave domains that depend on it. The master's shared memory range +is NOT allocated in addition to its regular memory. Hence, it is usually +a good idea to choose a subrange of the regular guest
[Xen-devel] [PATCH v7 2/8] libxl: introduce a new structure to represent static shared memory regions
From: Zhongze Liu
Author: Zhongze Liu
Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
And deleted some trailing white spaces.
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by: Zhongze Liu
Reviewed-by: Stefano Stabellini
Acked-by: Wei Liu
Signed-off-by: Stefano Stabellini
Cc: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix typos
- add LIBXL_HAVE_SSHM
- replace end with size
---
tools/libxl/libxl.h | 6 ++
tools/libxl/libxl_types.idl | 32 ++--
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index ae2d63d..a9a523e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2455,6 +2455,12 @@ int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int
nonblock);
int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
+#define LIBXL_HAVE_SSHM 1
+
+/* Constants for libxl_static_shm */
+#define LIBXL_SSHM_RANGE_UNKNOWN UINT64_MAX
+#define LIBXL_SSHM_ID_MAXLEN128
+
#include
#endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a38580..e1fb975 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -565,10 +565,10 @@ libxl_domain_build_info = Struct("domain_build_info",[
("keymap", string),
("sdl", libxl_sdl_info),
("spice",libxl_spice_info),
-
+
("gfx_passthru", libxl_defbool),
("gfx_passthru_kind",
libxl_gfx_passthru_kind),
-
+
("serial", string),
("boot", string),
("usb", libxl_defbool),
@@ -903,6 +903,33 @@ libxl_device_vsnd = Struct("device_vsnd", [
("pcms", Array(libxl_vsnd_pcm, "num_vsnd_pcms"))
])
+libxl_sshm_cachepolicy = Enumeration("sshm_cachepolicy", [
+(-1, "UNKNOWN"),
+(0, "ARM_NORMAL"), # ARM policies should be < 32
+(32, "X86_NORMAL"), # X86 policies should be >= 32
+], init_val = "LIBXL_SSHM_CHCHE_POLICY_UNKNOWN")
+
+libxl_sshm_prot = Enumeration("sshm_prot", [
+(-1, "UNKNOWN"),
+(3, "RW"),
+], init_val = "LIBXL_SSHM_PROT_UNKNOWN")
+
+libxl_sshm_role = Enumeration("sshm_role", [
+(-1, "UNKNOWN"),
+(0, "MASTER"),
+(1, "SLAVE"),
+], init_val = "LIBXL_SSHM_ROLE_UNKNOWN")
+
+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("size", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("prot", libxl_sshm_prot, {'init_val': 'LIBXL_SSHM_PROT_UNKNOWN'}),
+("cache_policy", libxl_sshm_cachepolicy, {'init_val':
'LIBXL_SSHM_CACHEPOLICY_UNKNOWN'}),
+("role", libxl_sshm_role, {'init_val': 'LIBXL_SSHM_ROLE_UNKNOWN'}),
+])
+
libxl_domain_config = Struct("domain_config", [
("c_info", libxl_domain_create_info),
("b_info", libxl_domain_build_info),
@@ -924,6 +951,7 @@ libxl_domain_config = Struct("domain_config", [
("channels", Array(libxl_device_channel, "num_channels")),
("usbctrls", Array(libxl_device_usbctrl, "num_usbctrls")),
("usbdevs", Array(libxl_device_usbdev, "num_usbdevs")),
+("sshms", Array(libxl_static_shm, "num_sshms")),
("on_poweroff", libxl_action_on_shutdown),
("on_reboot", libxl_action_on_shutdown),
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 7/8] xen/arm: export shared memory regions as reserved-memory on device tree
Shared memory regions need to be advertised to the guest. Fortunately, a
device tree binding for special memory regions already exist:
reserved-memory.
Add a reserved-memory node for each shared memory region, for both
masters and slaves.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- change node name to xen-shmem
- add compatible property
- add id property
---
tools/libxl/libxl_arch.h | 2 +-
tools/libxl/libxl_arm.c | 59 +---
tools/libxl/libxl_dom.c | 2 +-
tools/libxl/libxl_x86.c | 2 +-
4 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 6a07ccf..3626e4a 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -36,7 +36,7 @@ int libxl__arch_domain_create(libxl__gc *gc,
libxl_domain_config *d_config,
/* setup arch specific hardware description, i.e. DTB on ARM */
_hidden
int libxl__arch_domain_init_hw_description(libxl__gc *gc,
- libxl_domain_build_info *info,
+ libxl_domain_config *d_config,
libxl__domain_build_state *state,
struct xc_dom_image *dom);
/* finalize arch specific hardware description. */
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 5f62e78..72dd0d2 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -461,6 +461,56 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
return 0;
}
+static int make_reserved_nodes(libxl__gc *gc, void *fdt,
+ libxl_domain_config *d_config)
+{
+int res, i;
+const char *name;
+
+if (d_config->num_sshms == 0)
+return 0;
+
+res = fdt_begin_node(fdt, "reserved-memory");
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#address-cells", ROOT_ADDRESS_CELLS);
+if (res) return res;
+
+res = fdt_property_cell(fdt, "#size-cells", ROOT_SIZE_CELLS);
+if (res) return res;
+
+res = fdt_property(fdt, "ranges", NULL, 0);
+if (res) return res;
+
+for (i = 0; i < d_config->num_sshms; i++) {
+uint64_t start = d_config->sshms[i].begin;
+if (d_config->sshms[i].role == LIBXL_SSHM_ROLE_SLAVE)
+start += d_config->sshms[i].offset;
+name = GCSPRINTF("xen-shmem@%"PRIx64, start);
+
+res = fdt_begin_node(fdt, name);
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1, start, d_config->sshms[i].size);
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "xen,shared-memory");
+if (res) return res;
+
+res = fdt_property_string(fdt, "id", d_config->sshms[i].id);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+}
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
+
static int make_gicv2_node(libxl__gc *gc, void *fdt,
uint64_t gicd_base, uint64_t gicd_size,
uint64_t gicc_base, uint64_t gicc_size)
@@ -836,10 +886,11 @@ static int copy_partial_fdt(libxl__gc *gc, void *fdt,
void *pfdt)
#define FDT_MAX_SIZE (1<<20)
-static int libxl__prepare_dtb(libxl__gc *gc, libxl_domain_build_info *info,
+static int libxl__prepare_dtb(libxl__gc *gc, libxl_domain_config *d_config,
libxl__domain_build_state *state,
struct xc_dom_image *dom)
{
+libxl_domain_build_info *info = _config->b_info;
void *fdt = NULL;
void *pfdt = NULL;
int rc, res;
@@ -922,6 +973,7 @@ next_resize:
FDT( make_psci_node(gc, fdt) );
FDT( make_memory_nodes(gc, fdt, dom) );
+FDT( make_reserved_nodes(gc, fdt, d_config) );
switch (info->arch_arm.gic_version) {
case LIBXL_GIC_VERSION_V2:
@@ -971,12 +1023,13 @@ out:
}
int libxl__arch_domain_init_hw_description(libxl__gc *gc,
- libxl_domain_build_info *info,
+ libxl_domain_config *d_config,
libxl__domain_build_state *state,
struct xc_dom_image *dom)
{
int rc;
uint64_t val;
+libxl_domain_build_info *info = _config->b_info;
assert(info->type == LIBXL_DOMAIN_TYPE_PV);
@@ -992,7 +1045,7 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
if (rc)
return rc;
-rc = libxl__prepare_dtb(gc, info, state, dom);
+rc = libxl__prepare_dtb(gc, d_config, state, dom);
if (rc) goto out;
if (!libxl_defbool_val(info->acpi)) {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3cfe0d4..4ab52df 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
[Xen-devel] [PATCH v7 8/8] xen/arm: add xen,dmabuf nodes
Add a "xen-dmabuf" device node for every shared region, compatible
"xen,dmabuf". Each of these nodes refers to the corresponding
reserved-memory node using a phandle.
These device nodes can be used to bind drivers that export the region to
userspace, or do other operations based on the reserved memory region.
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- new patch
---
tools/libxl/libxl_arm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 72dd0d2..e09a049 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -466,6 +466,7 @@ static int make_reserved_nodes(libxl__gc *gc, void *fdt,
{
int res, i;
const char *name;
+uint32_t phandle;
if (d_config->num_sshms == 0)
return 0;
@@ -482,7 +483,9 @@ static int make_reserved_nodes(libxl__gc *gc, void *fdt,
res = fdt_property(fdt, "ranges", NULL, 0);
if (res) return res;
-for (i = 0; i < d_config->num_sshms; i++) {
+for (i = 0, phandle = PHANDLE_GIC - 1;
+ i < d_config->num_sshms;
+ i++, phandle--) {
uint64_t start = d_config->sshms[i].begin;
if (d_config->sshms[i].role == LIBXL_SSHM_ROLE_SLAVE)
start += d_config->sshms[i].offset;
@@ -501,6 +504,9 @@ static int make_reserved_nodes(libxl__gc *gc, void *fdt,
res = fdt_property_string(fdt, "id", d_config->sshms[i].id);
if (res) return res;
+res = fdt_property_cell(fdt, "phandle", phandle);
+if (res) return res;
+
res = fdt_end_node(fdt);
if (res) return res;
}
@@ -508,6 +514,27 @@ static int make_reserved_nodes(libxl__gc *gc, void *fdt,
res = fdt_end_node(fdt);
if (res) return res;
+for (i = 0, phandle = PHANDLE_GIC - 1;
+ i < d_config->num_sshms;
+ i++, phandle--) {
+uint64_t start = d_config->sshms[i].begin;
+if (d_config->sshms[i].role == LIBXL_SSHM_ROLE_SLAVE)
+start += d_config->sshms[i].offset;
+name = GCSPRINTF("xen-dmabuf@%"PRIx64, start);
+
+res = fdt_begin_node(fdt, name);
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "xen,dmabuf");
+if (res) return res;
+
+res = fdt_property_cell(fdt, "memory-region", phandle);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+}
+
return 0;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7 3/8] libxl: support mapping static shared memory areas during domain creation
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated master domain,
not page aligned, no master domain etc.
* Use xc_domain_add_to_physmap_batch to map the shared pages to slaves
* When some of the pages can't be successfully mapped, roll back any
successfully mapped pages so that the system stays in a consistent state.
* Write information about static shared memory areas into the appropriate
xenstore paths and set the refcount of the shared region accordingly.
Temporarily mark this as unsupported on x86 because calling p2m_add_foreign on
two domU's is currently not allowd on x86 (see the comments in
x86/mm/p2m.c:p2m_add_foreign for more details).
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by: Zhongze Liu
Signed-off-by: Stefano Stabellini
Cc: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix typos
- add comments
- add value checks (including alignment checks) in sshm_setdefaults
---
tools/libxl/Makefile | 3 +-
tools/libxl/libxl_arch.h | 6 +
tools/libxl/libxl_arm.c | 15 ++
tools/libxl/libxl_create.c | 27 +++
tools/libxl/libxl_internal.h | 14 ++
tools/libxl/libxl_sshm.c | 405 +++
tools/libxl/libxl_x86.c | 19 ++
7 files changed, 488 insertions(+), 1 deletion(-)
create mode 100644 tools/libxl/libxl_sshm.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6da342e..53af186 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
- libxl_pvcalls.o libxl_vsnd.o libxl_vkb.o $(LIBXL_OBJS-y)
+ libxl_pvcalls.o libxl_vsnd.o libxl_vkb.o libxl_sshm.o \
+ $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 74a5af3..6a07ccf 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -73,6 +73,12 @@ int libxl__arch_extra_memory(libxl__gc *gc,
const libxl_domain_build_info *info,
uint64_t *out);
+_hidden
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info);
+
+_hidden
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm);
+
#if defined(__i386__) || defined(__x86_64__)
#define LAPIC_BASE_ADDRESS 0xfee0
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8af9f6f..5f62e78 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1141,6 +1141,21 @@ void libxl__arch_domain_build_info_acpi_setdefault(
libxl_defbool_setdefault(_info->acpi, false);
}
+bool libxl__arch_domain_support_sshm(const libxl_domain_build_info *b_info)
+{
+return true;
+}
+
+int libxl__arch_domain_sshm_cachepolicy_setdefault(libxl_static_shm *sshm)
+{
+if (sshm->cache_policy == LIBXL_SSHM_CACHEPOLICY_UNKNOWN)
+sshm->cache_policy = LIBXL_SSHM_CACHEPOLICY_ARM_NORMAL;
+if (sshm->cache_policy >= LIBXL_SSHM_CACHEPOLICY_X86_NORMAL)
+return ERROR_INVAL;
+
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1ccb3e3..2acc86a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -532,6 +532,14 @@ int libxl__domain_build(libxl__gc *gc,
ret = ERROR_INVAL;
goto out;
}
+
+/* The p2m has been setup, we could map the static shared memory now. */
+ret = libxl__sshm_add(gc, domid, d_config->sshms, d_config->num_sshms);
+if (ret != 0) {
+LOG(ERROR, "failed to map static shared memory");
+goto out;
+}
+
ret = libxl__build_post(gc, domid, info, state, vments, localents);
out:
return ret;
@@ -959,6 +967,25 @@ static void initiate_domain_create(libxl__egc *egc,
goto error_out;
}
+if (d_config->num_sshms != 0 &&
+!libxl__arch_domain_support_sshm(_config->b_info)) {
+LOGD(ERROR, domid, "static_shm is not supported by this domain type.");
+ret = ERROR_INVAL;
+goto error_out;
+}
+
+for (i = 0; i < d_config->num_sshms; ++i) {
+ret = libxl__sshm_setdefault(gc, domid, _config->sshms[i]);
[Xen-devel] [PATCH v3 1/6] xen/arm: introduce platform_smc
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/platform.c| 8
xen/arch/arm/vsmc.c| 4
xen/include/asm-arm/platform.h | 3 +++
3 files changed, 15 insertions(+)
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 3f2989e..9e19023 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,14 @@ void platform_poweroff(void)
platform->poweroff();
}
+bool platform_smc(struct cpu_user_regs *regs)
+{
+if ( platform && platform->smc )
+return platform->smc(regs);
+
+return false;
+}
+
bool platform_has_quirk(uint32_t quirk)
{
uint32_t quirks = 0;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c4ccae6..c72b9a0 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* Number of functions currently supported by Hypervisor Service. */
#define XEN_SMCCC_FUNCTION_COUNT 3
@@ -272,6 +273,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
case ARM_SMCCC_OWNER_STANDARD:
handled = handle_sssc(regs);
break;
+case ARM_SMCCC_OWNER_SIP:
+handled = platform_smc(regs);
+break;
}
}
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index 2591d7b..dc55b6d 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -26,6 +26,8 @@ struct platform_desc {
void (*reset)(void);
/* Platform power-off */
void (*poweroff)(void);
+/* Platform specific SMC handler */
+bool (*smc)(struct cpu_user_regs *regs);
/*
* Platform quirks
* Defined has a function because a platform can support multiple
@@ -55,6 +57,7 @@ int platform_cpu_up(int cpu);
#endif
void platform_reset(void);
void platform_poweroff(void);
+bool platform_smc(struct cpu_user_regs *regs);
bool platform_has_quirk(uint32_t quirk);
bool platform_device_is_blacklisted(const struct dt_device_node *node);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/6] xen/arm: zynqmp: introduce zynqmp specific defines
From: "Edgar E. Iglesias" From: Edgar E. Iglesias Introduce zynqmp specific defines for the firmware calls. See EEMI: https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf The error codes are described, under XIlPM Error Codes: https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf Signed-off-by: Edgar E. Iglesias Signed-off-by: Stefano Stabellini --- xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 383 + 1 file changed, 383 insertions(+) diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h index 6630dc8..70fad7a 100644 --- a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h +++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h @@ -1,3 +1,386 @@ #include +#define MM_CRL_APB 0xff5e +#define MM_RPU 0xff9a +#define MM_RTC 0xffa6 +#define MM_ADMA_CH00xffa8 + +#define MM_USB3_0_XHCI 0xfe20 +#define MM_USB3_1_XHCI 0xfe30 + +#define MM_SATA_AHCI_HBA 0xfd0c +#define MM_AXIPCIE_MAIN0xfd0e +#define MM_CRF_APB 0xfd1a +#define MM_PCIE_ATTRIB 0xfd48 +#define MM_DP 0xfd4a +#define MM_GPU 0xfd4b +#define MM_GDMA_CH00xfd50 + +#define MM_UART0 0xff00 +#define MM_UART1 0xff01 +#define MM_I2C00xff02 +#define MM_I2C10xff03 +#define MM_SPI00xff04 +#define MM_SPI10xff05 +#define MM_CAN00xff06 +#define MM_CAN10xff07 +#define MM_GPIO0xff0a +#define MM_GEM00xff0b +#define MM_GEM10xff0c +#define MM_GEM20xff0d +#define MM_GEM30xff0e +#define MM_QSPI0xff0f +#define MM_NAND0xff10 +#define MM_TTC00xff11 +#define MM_TTC10xff12 +#define MM_TTC20xff13 +#define MM_TTC30xff14 +#define MM_SWDT0xff15 +#define MM_SD0 0xff16 +#define MM_SD1 0xff17 +#define MM_IOU_SLCR0xff18 + +#define MM_PMU_GLOBAL 0xffd8 + +/* Selected set of register definitions: */ +#define R_CRF_APLL_CTRL 0x20 +#define R_CRF_ACPU_CTRL 0x60 +#define R_CRF_DP_VIDEO_REF_CTRL 0x70 +#define R_CRF_DP_AUDIO_REF_CTRL 0x74 +#define R_CRF_DP_STC_REF_CTRL 0x7c +#define R_CRF_GPU_REF_CTRL0x84 +#define R_CRF_SATA_REF_CTRL 0xa0 +#define R_CRF_PCIE_REF_CTRL 0xb4 +#define R_CRF_GDMA_REF_CTRL 0xb8 +#define R_CRF_DPDMA_REF_CTRL 0xbc + +#define R_CRL_IOPLL_CTRL 0x20 +#define R_CRL_RPLL_TO_FPD_CTRL0x48 +#define R_CRL_USB3_DUAL_REF_CTRL 0x4c +#define R_CRL_GEM0_REF_CTRL 0x50 +#define R_CRL_GEM1_REF_CTRL 0x54 +#define R_CRL_GEM2_REF_CTRL 0x58 +#define R_CRL_GEM3_REF_CTRL 0x5c +#define R_CRL_USB0_BUS_REF_CTRL 0x60 +#define R_CRL_USB1_BUS_REF_CTRL 0x64 +#define R_CRL_QSPI_REF_CTRL 0x68 +#define R_CRL_SDIO0_REF_CTRL 0x6c +#define R_CRL_SDIO1_REF_CTRL 0x70 +#define R_CRL_UART0_REF_CTRL 0x74 +#define R_CRL_UART1_REF_CTRL 0x78 +#define R_CRL_SPI0_REF_CTRL 0x7c +#define R_CRL_SPI1_REF_CTRL 0x80 +#define R_CRL_CAN0_REF_CTRL 0x84 +#define R_CRL_CAN1_REF_CTRL 0x88 +#define R_CRL_CPU_R5_CTRL 0x90 +#define R_CRL_IOU_SWITCH_CTRL 0x9c +#define R_CRL_CSU_PLL_CTRL0xa0 +#define R_CRL_PCAP_CTRL 0xa4 +#define R_CRL_LPD_SWITCH_CTRL 0xa8 +#define R_CRL_LPD_LSBUS_CTRL 0xac +#define R_CRL_DBG_LPD_CTRL0xb0 +#define R_CRL_NAND_REF_CTRL 0xb4 +#define R_CRL_ADMA_REF_CTRL 0xb8 +#define R_CRL_PL0_REF_CTRL0xc0 +#define R_CRL_PL1_REF_CTRL0xc4 +#define R_CRL_PL2_REF_CTRL0xc8 +#define R_CRL_PL3_REF_CTRL0xcc +#define R_CRL_PL0_THR_CTRL0xd0 +#define R_CRL_PL0_THR_CNT 0xd4 +#define R_CRL_PL1_THR_CTRL0xd8 +#define R_CRL_PL1_THR_CNT 0xdc +#define R_CRL_PL2_THR_CTRL0xe0 +#define R_CRL_PL2_THR_CNT 0xe4 +#define R_CRL_PL3_THR_CTRL0xe8 +#define R_CRL_PL3_THR_CNT 0xfc +#define R_CRL_GEM_TSU_REF_CTRL0x100 +#define R_CRL_DLL_REF_CTRL0x104 +#define R_CRL_AMS_REF_CTRL0x108 +#define R_CRL_I2C0_REF_CTRL 0x120 +#define R_CRL_I2C1_REF_CTRL 0x124 +#define R_CRL_TIMESTAMP_REF_CTRL 0x128 + +#define R_PMU_GLOBAL_GLOBAL_GEN_STORAGE00x30 +#define R_PMU_GLOBAL_PERS_GLOB_GEN_STORAGE7 0x6c + +#define R_PMU_GLOBAL_PWR_STATE 0x100 + +#define R_IOU_SLCR_MIO_PIN_0 0x0 +#define R_IOU_SLCR_MIO_MST_TRI2 0x20c +#define R_IOU_SLCR_WDT_CLK_SEL0x300 +#define R_IOU_SLCR_CAN_MIO_CTRL 0x304 +#define R_IOU_SLCR_GEM_CLK_CTRL 0x308 +#define R_IOU_SLCR_SDIO_CLK_CTRL 0x30c +#define R_IOU_SLCR_CTRL_REG_SD 0x310 +#define R_IOU_SLCR_SD_ITAPDLY0x314 +#define R_IOU_SLCR_SD_CDN_CTRL0x35c +#define R_IOU_SLCR_GEM_CTRL
[Xen-devel] [PATCH v3 2/6] xen/arm: zynqmp: Forward plaform specific firmware calls
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function resposible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/platforms/Makefile| 1 +
xen/arch/arm/platforms/xilinx-zynqmp-eemi.c| 38 ++
xen/arch/arm/platforms/xilinx-zynqmp.c | 14
xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 3 ++
4 files changed, 56 insertions(+)
create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
create mode 100644 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 80e555c..703f915 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,3 +9,4 @@ obj-y += sunxi.o
obj-$(CONFIG_ARM_64) += thunderx.o
obj-$(CONFIG_ARM_64) += xgene-storm.o
obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_ARM_64) += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
new file mode 100644
index 000..c3a19e9
--- /dev/null
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -0,0 +1,38 @@
+/*
+ * xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+ *
+ * Xilinx ZynqMP EEMI API
+ *
+ * Copyright (c) 2018 Xilinx Inc.
+ * Written by Edgar E. Iglesias
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+bool zynqmp_eemi(struct cpu_user_regs *regs)
+{
+return false;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index d8ceded..c318cf5 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -18,6 +18,8 @@
*/
#include
+#include
+#include
static const char * const zynqmp_dt_compat[] __initconst =
{
@@ -32,8 +34,20 @@ static const struct dt_device_match zynqmp_blacklist_dev[]
__initconst =
{ /* sentinel */ },
};
+static bool zynqmp_smc(struct cpu_user_regs *regs)
+{
+if ( !is_64bit_domain(current->domain) )
+return false;
+/* Only support platforms with SMCCC >= 1.1 */
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+return zynqmp_eemi(regs);
+}
+
PLATFORM_START(xilinx_zynqmp, "Xilinx ZynqMP")
.compatible = zynqmp_dt_compat,
+.smc = zynqmp_smc,
.blacklist_dev = zynqmp_blacklist_dev,
PLATFORM_END
diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
new file mode 100644
index 000..6630dc8
--- /dev/null
+++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
@@ -0,0 +1,3 @@
+#include
+
+extern bool zynqmp_eemi(struct cpu_user_regs *regs);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 4/6] xen/arm: zynqmp: eemi access control
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following three functions:
domain_has_node_access: check access to the node
domain_has_reset_access: check access to the reset line
domain_has_mmio_access: check access to the register
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 783
1 file changed, 783 insertions(+)
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
index c3a19e9..62cc15c 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -16,6 +16,74 @@
* GNU General Public License for more details.
*/
+/*
+ * EEMI Power Management API access
+ *
+ * Refs:
+ * https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
+ *
+ * Background:
+ * The ZynqMP has a subsystem named the PMU with a CPU and special devices
+ * dedicated to running Power Management Firmware. Other masters in the
+ * system need to send requests to the PMU in order to for example:
+ * * Manage power state
+ * * Configure clocks
+ * * Program bitstreams for the programmable logic
+ * * etc
+ *
+ * Although the details of the setup are configurable, in the common case
+ * the PMU lives in the Secure world. NS World cannot directly communicate
+ * with it and must use proxy services from ARM Trusted Firmware to reach
+ * the PMU.
+ *
+ * Power Management on the ZynqMP is implemented in a layered manner.
+ * The PMU knows about various masters and will enforce access controls
+ * based on a pre-configured partitioning. This configuration dictates
+ * which devices are owned by the various masters and the PMU FW makes sure
+ * that a given master cannot turn off a device that it does not own or that
+ * is in use by other masters.
+ *
+ * The PMU is not aware of multiple execution states in masters.
+ * For example, it treats the ARMv8 cores as single units and does not
+ * distinguish between Secure vs NS OS's nor does it know about Hypervisors
+ * and multiple guests. It is up to software on the ARMv8 cores to present
+ * a unified view of its power requirements.
+ *
+ * To implement this unified view, ARM Trusted Firmware at EL3 provides
+ * access to the PM API via SMC calls. ARM Trusted Firmware is responsible
+ * for mediating between the Secure and the NS world, rejecting SMC calls
+ * that request changes that are not allowed.
+ *
+ * Xen running above ATF owns the NS world and is responsible for presenting
+ * unified PM requests taking all guests and the hypervisor into account.
+ *
+ * Implementation:
+ * The PM API contains different classes of calls.
+ * Certain calls are harmless to expose to any guest.
+ * These include calls to get the PM API Version, or to read out the version
+ * of the chip we're running on.
+ *
+ * In order to correctly virtualize these calls, we need to know if
+ * guests issuing these calls have ownership of the given device.
+ * The approach taken here is to map PM API Nodes identifying
+ * a device into base addresses for registers that belong to that
+ * same device.
+ *
+ * If the guest has access to devices registers, we give the guest
+ * access to PM API calls that affect that device. This is implemented
+ * by pm_node_access and domain_has_node_access().
+ *
+ * MMIO access:
+ * These calls allow guests to access certain memory ranges. These ranges
+ * are typically protected for secure-world access only and also from
+ * certain masters only, so guests cannot access them directly.
+ * Registers within the memory regions affect certain nodes. In this case,
+ * our input is an address and we map that address into a node. If the
+ * guest has ownership of that node, the access is allowed.
+ * Some registers contain bitfields and a single register may contain
+ * bits that affect multiple nodes.
+ */
+
#include
#include
#include
@@ -23,6 +91,721 @@
#include
#include
+struct pm_access
+{
+paddr_t addr;
+bool hwdom_access;/* HW domain gets access regardless. */
+};
+
+/*
+ * This table maps a node into a memory address.
+ * If a guest has access to the address, it has enough control
+ * over the node to grant it access to EEMI calls for that node.
+ */
+static const struct pm_access pm_node_access[] = {
+/* MM_RPU grants access to all RPU Nodes. */
+[NODE_RPU] = { MM_RPU },
+[NODE_RPU_0] = { MM_RPU },
+[NODE_RPU_1] = { MM_RPU },
+[NODE_IPI_RPU_0] = { MM_RPU },
+
+/* GPU nodes. */
+[NODE_GPU] = { MM_GPU },
+[NODE_GPU_PP_0] = { MM_GPU },
+[NODE_GPU_PP_1] = { MM_GPU },
+
+[NODE_USB_0] = { MM_USB3_0_XHCI },
+[NODE_USB_1] = { MM_USB3_1_XHCI },
+[NODE_TTC_0] = { MM_TTC0 },
+[NODE_TTC_1] = { MM_TTC1 },
+[NODE_TTC_2] = { MM_TTC2 },
+[NODE_TTC_3] = { MM_TTC3 },
+[NODE_SATA] = { MM_SATA_AHCI_HBA },
+
[Xen-devel] [PATCH v3 5/6] xen/arm: zynqmp: implement zynqmp_eemi
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 143 +++-
1 file changed, 142 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
index 62cc15c..1dbdf04 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
@@ -808,7 +808,148 @@ static bool domain_has_mmio_access(struct domain *d,
bool zynqmp_eemi(struct cpu_user_regs *regs)
{
-return false;
+struct arm_smccc_res res;
+bool is_mmio_write = false;
+uint32_t fid = get_user_reg(regs, 0);
+uint32_t nodeid = get_user_reg(regs, 1);
+unsigned int pm_fn = fid & 0x;
+enum pm_ret_status ret;
+
+switch ( pm_fn )
+{
+/*
+ * We can't allow CPUs to suspend without Xen knowing about it.
+ * We accept but ignore the request and wait for the guest to issue
+ * a WFI which Xen will trap and act accordingly upon.
+ */
+case PM_SELF_SUSPEND:
+ret = XST_PM_SUCCESS;
+goto done;
+
+case PM_GET_NODE_STATUS:
+/* API for PUs. */
+case PM_REQ_SUSPEND:
+case PM_FORCE_POWERDOWN:
+case PM_ABORT_SUSPEND:
+case PM_REQ_WAKEUP:
+case PM_SET_WAKEUP_SOURCE:
+/* API for slaves. */
+case PM_REQ_NODE:
+case PM_RELEASE_NODE:
+case PM_SET_REQUIREMENT:
+case PM_SET_MAX_LATENCY:
+if ( !domain_has_node_access(current->domain, nodeid) )
+{
+gprintk(XENLOG_WARNING,
+"zynqmp-pm: fn=%u No access to node %u\n", pm_fn, nodeid);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+goto forward_to_fw;
+
+case PM_RESET_ASSERT:
+case PM_RESET_GET_STATUS:
+if ( !domain_has_reset_access(current->domain, nodeid) )
+{
+gprintk(XENLOG_WARNING,
+"zynqmp-pm: fn=%u No access to reset %u\n", pm_fn, nodeid);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+goto forward_to_fw;
+
+/* These calls are safe and always allowed. */
+case ZYNQMP_SIP_SVC_CALL_COUNT:
+case ZYNQMP_SIP_SVC_UID:
+case ZYNQMP_SIP_SVC_VERSION:
+case PM_GET_TRUSTZONE_VERSION:
+case PM_GET_API_VERSION:
+case PM_GET_CHIPID:
+goto forward_to_fw;
+
+/* Mediated MMIO access. */
+case PM_MMIO_WRITE:
+is_mmio_write = true;
+/* Fallthrough. */
+case PM_MMIO_READ:
+{
+uint32_t mask = get_user_reg(regs, 1) >> 32;
+if ( !domain_has_mmio_access(current->domain,
+ is_mmio_write,
+ nodeid, ) )
+{
+gprintk(XENLOG_WARNING,
+"eemi: fn=%u No access to MMIO %s %u\n",
+pm_fn, is_mmio_write ? "write" : "read", nodeid);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+set_user_reg(regs, 1, ((uint64_t)mask << 32) | nodeid);
+goto forward_to_fw;
+}
+
+/* Exclusive to the hardware domain. */
+case PM_INIT:
+case PM_SET_CONFIGURATION:
+case PM_FPGA_LOAD:
+case PM_FPGA_GET_STATUS:
+case PM_SECURE_SHA:
+case PM_SECURE_RSA:
+case PM_PINCTRL_SET_FUNCTION:
+case PM_PINCTRL_REQUEST:
+case PM_PINCTRL_RELEASE:
+case PM_PINCTRL_GET_FUNCTION:
+case PM_PINCTRL_CONFIG_PARAM_GET:
+case PM_PINCTRL_CONFIG_PARAM_SET:
+case PM_IOCTL:
+case PM_QUERY_DATA:
+case PM_CLOCK_ENABLE:
+case PM_CLOCK_DISABLE:
+case PM_CLOCK_GETSTATE:
+case PM_CLOCK_GETDIVIDER:
+case PM_CLOCK_SETDIVIDER:
+case PM_CLOCK_SETRATE:
+case PM_CLOCK_GETRATE:
+case PM_CLOCK_SETPARENT:
+case PM_CLOCK_GETPARENT:
+if ( !is_hardware_domain(current->domain) )
+{
+gprintk(XENLOG_WARNING, "eemi: fn=%u No access", pm_fn);
+ret = XST_PM_NO_ACCESS;
+goto done;
+}
+goto forward_to_fw;
+
+/* These calls are never allowed. */
+case PM_SYSTEM_SHUTDOWN:
+ret = XST_PM_NO_ACCESS;
+goto done;
+
+default:
+gprintk(XENLOG_WARNING, "zynqmp-pm: Unhandled PM Call: %u\n", fid);
+return false;
+}
+
+forward_to_fw:
+arm_smccc_1_1_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg(regs, 6),
+ get_user_reg(regs, 7),
+ );
+
+set_user_reg(regs, 0, res.a0);
+set_user_reg(regs, 1, res.a1);
+
[Xen-devel] [PATCH v7 4/8] libxl: support unmapping static shared memory areas during domain destruction
From: Zhongze Liu
Author: Zhongze Liu
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a master: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a slave:
1) unmap the shared pages, and cleanup related xs entries. If the
system works normally, all the shared pages will be unmapped, so there
won't be page leaks. In case of errors, the unmapping process will go
on and unmap all the other pages that can be unmapped, so the other
pages won't be leaked, either.
2) Decrease the refcount of the sshm region, if the refcount reaches
0, cleanup the whole sshm path.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by: Zhongze Liu
Signed-off-by: Stefano Stabellini
Cc: Ian Jackson
Cc: Wei Liu
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: xen-de...@lists.xen.org
---
Changes in v5:
- fix typos
- add comments
- cannot move unmap before xenstore transaction because it needs to
retrieve begin/size values from xenstore
---
tools/libxl/libxl_domain.c | 5 ++
tools/libxl/libxl_internal.h | 2 +
tools/libxl/libxl_sshm.c | 107 +++
3 files changed, 114 insertions(+)
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 533bcdf..053bbe2 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1060,6 +1060,11 @@ void libxl__destroy_domid(libxl__egc *egc,
libxl__destroy_domid_state *dis)
goto out;
}
+rc = libxl__sshm_del(gc, domid);
+if (rc) {
+LOGD(ERROR, domid, "Deleting static shm failed.");
+}
+
if (libxl__device_pci_destroy_all(gc, domid) < 0)
LOGD(ERROR, domid, "Pci shutdown failed");
rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bb6b840..937b743 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4431,6 +4431,8 @@ static inline bool libxl__string_is_default(char **s)
_hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
libxl_static_shm *sshm, int len);
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
+
_hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
libxl_static_shm *sshms, int len);
_hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index f61b80c..9672056 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -94,6 +94,113 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
return 0;
}
+/*
+ * Decrease the refcount of an sshm. When refcount reaches 0,
+ * clean up the whole sshm path.
+ * Xenstore operations are done within the same transaction.
+ */
+static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
+ const char *sshm_path)
+{
+int count;
+const char *count_path, *count_string;
+
+count_path = GCSPRINTF("%s/usercnt", sshm_path);
+if (libxl__xs_read_checked(gc, xt, count_path, _string))
+return;
+count = atoi(count_string);
+
+if (--count == 0) {
+libxl__xs_path_cleanup(gc, xt, sshm_path);
+return;
+}
+
+count_string = GCSPRINTF("%d", count);
+libxl__xs_write_checked(gc, xt, count_path, count_string);
+
+return;
+}
+
+static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char *id,
+ uint64_t begin, uint64_t size)
+{
+uint64_t end;
+begin >>= XC_PAGE_SHIFT;
+size >>= XC_PAGE_SHIFT;
+end = begin + size;
+for (; begin < end; ++begin) {
+if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
+SSHM_ERROR(domid, id,
+ "unable to unmap shared page at 0x%"PRIx64".",
+ begin);
+}
+}
+}
+
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+ uint32_t domid, const char *id, bool isretry)
+{
+const char *slave_path, *begin_str, *size_str;
+uint64_t begin, size;
+
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+size_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/size", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+size = strtoull(size_str, NULL, 16);
+
+libxl__sshm_do_unmap(gc, domid, id, begin, size);
+libxl__xs_path_cleanup(gc, xt, slave_path);
+}
+
+/* Delete static_shm entries in the xensotre. */
+int libxl__sshm_del(libxl__gc *gc, uint32_t domid)
+{
+int rc, i;
+bool isretry;
+
[Xen-devel] [PATCH v7 1/8] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing
From: Zhongze Liu
Author: Zhongze Liu
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.
This patch introduces XENMAPSPACE_gmfn_share to address this inconvenience,
which is mostly the same as XENMAPSPACE_gmfn_foreign but has its own xsm check.
Specifically, the patch:
* Introduces a new av permission MMU__SHARE_MEM to denote if two domains can
share memory by using the new subop;
* Introduces xsm_map_gmfn_share() to check if (current) has proper permission
over (t) AND MMU__SHARE_MEM is allowed between (d) and (t);
* Modify the default xen.te to allow MMU__SHARE_MEM for normal domains that
allow grant mapping/event channels.
The new subop is marked unsupported for x86 because calling p2m_add_foregin
on two DomU's is currently not supported on x86.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by: Zhongze Liu
Signed-off-by: Stefano Stabellini
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Stefano Stabellini
Cc: Julien Grall
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Tim Deegan
Cc: xen-de...@lists.xen.org
---
Changes in v7:
- add additional checks
- update comments to reflect that
Changes in v5:
- fix coding style
- remove useless x86 hypervisor message for the unimplemented op
- code style
- improve/add comments
---
tools/flask/policy/modules/xen.if | 2 ++
xen/arch/arm/mm.c | 7 ++-
xen/include/public/memory.h | 8
xen/include/xsm/dummy.h | 13 +
xen/include/xsm/xsm.h | 6 ++
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 9 +
xen/xsm/flask/policy/access_vectors | 5 +
8 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/tools/flask/policy/modules/xen.if
b/tools/flask/policy/modules/xen.if
index 7aefd00..f841125 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -128,6 +128,8 @@ define(`domain_comms', `
domain_event_comms($1, $2)
allow $1 $2:grant { map_read map_write copy unmap };
allow $2 $1:grant { map_read map_write copy unmap };
+ allow $1 $2:mmu share_mem;
+ allow $2 $1:mmu share_mem;
')
# domain_self_comms(domain)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index d234c46..aa2e067 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1245,6 +1245,7 @@ int xenmem_add_to_physmap_one(
break;
case XENMAPSPACE_gmfn_foreign:
+case XENMAPSPACE_gmfn_share:
{
struct domain *od;
p2m_type_t p2mt;
@@ -1259,7 +1260,11 @@ int xenmem_add_to_physmap_one(
return -EINVAL;
}
-rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+if ( space == XENMAPSPACE_gmfn_foreign )
+rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
+else
+rc = xsm_map_gmfn_share(XSM_TARGET, d, od);
+
if ( rc )
{
rcu_unlock_domain(od);
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index bf2f81f..a706e3c 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -227,6 +227,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
Stage-2 using the Normal Memory
Inner/Outer Write-Back Cacheable
memory attribute. */
+#define XENMAPSPACE_gmfn_share 6 /* GMFN from another dom,
+ XENMEM_add_to_physmap_batch (and
+ currently ARM) only. Unlike
+ XENMAPSPACE_gmfn_foreign, it
+ requires current to have mapping
+ privileges instead of the
+ destination domain. */
+
/* ` } */
/*
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..352a886 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -535,6 +535,19 @@ static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG
struct domain *d, str
return xsm_default_action(action, d, t);
}
+/*
+ * Be aware that this is not an exact default equivalence of its flask variant
+ * which also checks if @d and @t "are allowed to share memory pages", for we
+ * don't have a proper default equivalence of such a check.
+ */
+static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
+ struct domain *t)
+{
+
[Xen-devel] [PATCH v7 0/8] Allow setting up shared memory areas between VMs from xl config files
Hi, This series implements a new xl config entry. Users can use the new config entry to statically setup shared memory areas among VMs that don't have grant table support so that they could communicate with each other through the static shared memory areas. It was originally developed by Zhongze, I am just updating the last few issued that were address during the last round of reviews in January. I tested the feature on ARM and works fine. Cheers, Stefano Changes in v7: - add additional checks in XSM - update comments to reflect that in XSM code - change DT node name to xen-shmem - add compatible property - add id property - new patch to add "xen,dmabuf" nodes The following changes since commit 6aaa9fb308171ec58ddf4cf058ad5341f81a65cf: hvm/altp2m: Clarify the proper way to extend the altp2m interface (2018-07-31 16:14:01 +0100) are available in the git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git share_mem-v7 for you to fetch changes up to 5129db1bd0dfca8aa83e37f5a21a8c1b47a000f6: xen/arm: add xen,dmabuf nodes (2018-08-10 14:28:48 -0700) Stefano Stabellini (2): xen/arm: export shared memory regions as reserved-memory on device tree xen/arm: add xen,dmabuf nodes Zhongze Liu (6): xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing libxl: introduce a new structure to represent static shared memory regions libxl: support mapping static shared memory areas during domain creation libxl: support unmapping static shared memory areas during domain destruction libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files docs: documentation about static shared memory regions docs/man/xl-static-shm-configuration.pod.5 | 264 +++ docs/man/xl.cfg.pod.5.in | 8 + docs/misc/xenstore-paths.markdown | 47 +++ tools/flask/policy/modules/xen.if | 2 + tools/libxl/Makefile | 5 +- tools/libxl/libxl.h| 6 + tools/libxl/libxl_arch.h | 8 +- tools/libxl/libxl_arm.c| 101 +- tools/libxl/libxl_create.c | 27 ++ tools/libxl/libxl_dom.c| 2 +- tools/libxl/libxl_domain.c | 5 + tools/libxl/libxl_internal.h | 16 + tools/libxl/libxl_sshm.c | 512 + tools/libxl/libxl_types.idl| 32 +- tools/libxl/libxl_x86.c| 21 +- tools/libxl/libxlu_sshm.c | 207 tools/libxl/libxlutil.h| 6 + tools/xl/xl_parse.c| 25 +- xen/arch/arm/mm.c | 7 +- xen/include/public/memory.h| 8 + xen/include/xsm/dummy.h| 13 + xen/include/xsm/xsm.h | 6 + xen/xsm/dummy.c| 1 + xen/xsm/flask/hooks.c | 9 + xen/xsm/flask/policy/access_vectors| 5 + 25 files changed, 1331 insertions(+), 12 deletions(-) create mode 100644 docs/man/xl-static-shm-configuration.pod.5 create mode 100644 tools/libxl/libxl_sshm.c create mode 100644 tools/libxl/libxlu_sshm.c ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 8
1 file changed, 8 deletions(-)
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index c318cf5..845e143 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -27,13 +27,6 @@ static const char * const zynqmp_dt_compat[] __initconst =
NULL
};
-static const struct dt_device_match zynqmp_blacklist_dev[] __initconst =
-{
-/* Power management is not yet supported. */
-DT_MATCH_COMPATIBLE("xlnx,zynqmp-pm"),
-{ /* sentinel */ },
-};
-
static bool zynqmp_smc(struct cpu_user_regs *regs)
{
if ( !is_64bit_domain(current->domain) )
@@ -48,7 +41,6 @@ static bool zynqmp_smc(struct cpu_user_regs *regs)
PLATFORM_START(xilinx_zynqmp, "Xilinx ZynqMP")
.compatible = zynqmp_dt_compat,
.smc = zynqmp_smc,
-.blacklist_dev = zynqmp_blacklist_dev,
PLATFORM_END
/*
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125851: all pass - PUSHED
flight 125851 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125851/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1aa9314e3a84b27f74f239155fc0ec3f58b66be0 baseline version: ovmf 10ea1b6853f977ce4ed0193230ad7953edbb1894 Last test of basis 125844 2018-08-10 13:11:27 Z0 days Testing same since 125851 2018-08-10 20:10:59 Z0 days1 attempts People who touched revisions under test: Kinney, Michael D Michael D Kinney jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 10ea1b6853..1aa9314e3a 1aa9314e3a84b27f74f239155fc0ec3f58b66be0 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/ptwr: Misc cleanup to ptwr_emulated_update()
On Fri, Aug 10, 2018 at 06:49:12PM +0100, Andrew Cooper wrote: > All but one user wants mfn as mfn_t, so switch its type. offset is only ever > used when multipled by 8, so fold that into its initial calculation. Fold all > the pointer arithmic on pl1e together, to avoid needless casts. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios test] 125827: tolerable FAIL - PUSHED
flight 125827 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/125827/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125181 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125181 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125181 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125181 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-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-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: seabios 95f850c2377968ad951121ceaab76d40a9eed593 baseline version: seabios 8c3f57ea1217ea0c80a72898bc35baa0e14af0e0 Last test of basis 125181 2018-07-15 14:40:57 Z 25 days Testing same since 125827 2018-08-09 12:40:50 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictfail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 8c3f57e..95f850c 95f850c2377968ad951121ceaab76d40a9eed593 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/spec-ctrl: Yet more fixes for xpti= parsing
>>> On 09.08.18 at 18:38, wrote: > As it currently stands, 'xpti=dom0' is indistinguishable from the default > value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed > hardware. > > Switch opt_xpti to use -1 as a default like all our other related options, and > clobber it as soon as we have a string to parse. > > In addition, 'xpti' alone should be interpreted in its positive boolean form, > rather than resulting in a parse error. But e.g. "xpti=dom0," should not be. I.e. ... > @@ -439,6 +438,10 @@ static __init int parse_xpti(const char *s) > const char *ss; > int val, rc = 0; > > +/* Inhibit the defaults as an explicit choice has been given. */ > +if ( opt_xpti == -1 ) > +opt_xpti = 0; ... the check for an empty string pointed to by s needs to be put here, ahead of the loop. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 75058: tolerable FAIL
flight 75058 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/75058/ 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 75042 baseline version: flight 75042 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.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/spec-ctrl: Yet more fixes for xpti= parsing
On 09/08/18 18:38, Andrew Cooper wrote: > As it currently stands, 'xpti=dom0' is indistinguishable from the default > value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed > hardware. > > Switch opt_xpti to use -1 as a default like all our other related options, and > clobber it as soon as we have a string to parse. > > In addition, 'xpti' alone should be interpreted in its positive boolean form, > rather than resulting in a parse error. > > (XEN) parameter "xpti" has invalid value "", rc=-22! > > Signed-off-by: Andrew Cooper Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125838: trouble: blocked/broken/pass
flight 125838 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125838/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 4b60c40659b34b6577a6bc91eb4115458a0e425f baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z8 days Failing since125741 2018-08-02 10:01:09 Z7 days 31 attempts Testing same since 125802 2018-08-08 11:00:47 Z1 days 15 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 512 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit
On 08/09/2018 05:41 AM, David Woodhouse wrote:
> On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
>> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
>>
>> This version applies to v4.9.
>
> I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
> this does want to go to 4.9 and earlier because the 'Fixes:' tag is a
> bit of a lie — the problem existed before that, at least in theory.
The commit 2140a9942 "x86/entry/64: Relax pvops stub clobber
specifications" was what removed the "movl %ebx, %eax" line later on
originally, but it was the commit 3ac6d8c787b8 that removed the
'xorl %ebx,%ebx'. So these weren't matched.
I don't know if it's a concern, but if someone had gone to the effort of
backporting the original commit 3ac6d8c787b83, adding the removal of
'xorl %ebx,%ebx' to this patch would create merge conflicts.
For that reason and given the line is harmless, should it be left in?
>
>> From Andy Lutomirski, original author:
>>
>> error_entry and error_exit communicate the user vs kernel status of
>> the frame using %ebx. This is unnecessary -- the information is in
>> regs->cs. Just use regs->cs.
>>
>> This makes error_entry simpler and makes error_exit more robust.
>>
>> It also fixes a nasty bug. Before all the Spectre nonsense, The
>> xen_failsafe_callback entry point returned like this:
>>
>> ALLOC_PT_GPREGS_ON_STACK
>> SAVE_C_REGS
>> SAVE_EXTRA_REGS
>> ENCODE_FRAME_POINTER
>> jmp error_exit
>>
>> And it did not go through error_entry. This was bogus: RBX
>> contained garbage, and error_exit expected a flag in RBX.
>> Fortunately, it generally contained *nonzero* garbage, so the
>> correct code path was used. As part of the Spectre fixes, code was
>> added to clear RBX to mitigate certain speculation attacks. Now,
>> depending on kernel configuration, RBX got zeroed and, when running
>> some Wine workloads, the kernel crashes. This was introduced by:
>>
>> commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
>> exceptions/interrupts, to reduce speculation attack surface")
>>
>> With this patch applied, RBX is no longer needed as a flag, and the
>> problem goes away.
>>
>> I suspect that malicious userspace could use this bug to crash the
>> kernel even without the offending patch applied, though.
>>
>> [Historical note: I wrote this patch as a cleanup before I was aware
>> of the bug it fixed.]
>>
>> [Note to stable maintainers: this should probably get applied to all
>> kernels.]
>>
>> Cc: Brian Gerst
>> Cc: Borislav Petkov
>> Cc: Dominik Brodowski
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: Thomas Gleixner
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: xen-devel@lists.xenproject.org
>> Cc: x...@kernel.org
>> Cc: sta...@vger.kernel.org
>> Cc: Andy Lutomirski
>> Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for
>> exceptions/interrupts, to reduce speculation attack surface")
>> Reported-and-tested-by: "M. Vefa Bicakci"
>> Signed-off-by: Andy Lutomirski
>> Signed-off-by: Sarah Newman
>> ---
>> arch/x86/entry/entry_64.S | 19 ---
>> 1 file changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index d58d8dc..0dab47a 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -774,7 +774,7 @@ ENTRY(\sym)
>>
>> call\do_sym
>>
>> -jmp error_exit /* %ebx: no
>> swapgs flag */
>> +jmp error_exit
>> .endif
>> END(\sym)
>> .endm
>> @@ -1043,7 +1043,6 @@ END(paranoid_exit)
>>
>> /*
>> * Save all registers in pt_regs, and switch gs if needed.
>> - * Return: EBX=0: came from user mode; EBX=1: otherwise
>> */
>> ENTRY(error_entry)
>> cld
>> @@ -1087,7 +1086,6 @@ ENTRY(error_entry)
>> * for these here too.
>> */
>> .Lerror_kernelspace:
>> -incl%ebx
>> leaqnative_irq_return_iret(%rip), %rcx
>> cmpq%rcx, RIP+8(%rsp)
>> je .Lerror_bad_iret
>> @@ -1119,28 +1117,19 @@ ENTRY(error_entry)
>>
>> /*
>> * Pretend that the exception came from user mode: set up
>> pt_regs
>> - * as if we faulted immediately after IRET and clear EBX so
>> that
>> - * error_exit knows that we will be returning to user mode.
>> + * as if we faulted immediately after IRET.
>> */
>> mov %rsp, %rdi
>> callfixup_bad_iret
>> mov %rax, %rsp
>> -decl%ebx
>> jmp .Lerror_entry_from_usermode_after_swapgs
>> END(error_entry)
>>
>> -
>> -/*
>> - * On entry, EBX is a "return to kernel mode" flag:
>> - * 1: already in kernel mode, don't need SWAPGS
>> - * 0: user gsbase is loaded, we need SWAPGS and standard
>> preparation for return to usermode
>> - */
>> ENTRY(error_exit)
>> -movl%ebx, %eax
>> DISABLE_INTERRUPTS(CLBR_NONE)
>> TRACE_IRQS_OFF
>> -testl %eax, %eax
>> -jnz retint_kernel
>> +testb
[Xen-devel] [ovmf test] 125837: all pass - PUSHED
flight 125837 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125837/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b3e1e343fe34d0173a53a61b10296e6522ce1f7c baseline version: ovmf 3781f14c31e00f4f1a195c7ad427be4f84f5cdf5 Last test of basis 125830 2018-08-09 17:40:42 Z0 days Testing same since 125837 2018-08-10 03:49:38 Z0 days1 attempts People who touched revisions under test: Zhang, Chao B jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 3781f14c31..b3e1e343fe b3e1e343fe34d0173a53a61b10296e6522ce1f7c -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board
Hi Oleksandr,
On 08/10/2018 12:47 PM, Oleksandr Tyshchenko wrote:
On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall wrote:
On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
I am quite confused here. If a CPU will be in hypervisor mode for Xen, how
come the same CPU will boot in monitor mode for Linux? Surely there should
be no difference in term of boot here. Are you using different firmware
here?
Yes, in order to run modified U-Boot is used. You can see here what
exactly was modified.
This instruction [1] contains link to patches [2] (see "Apply
additional patches" step)
which should be applied to bare U-Boot.
I don't think it is reasonable to request a specific U-boot just for
Xen. What if the user decide to run Linux on baremetal? Will he have to
switch back and forth between firmware?
[1]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-01/msg02475.html
U-Boot brings non-boot cores up (using ported from Linux's
platsmp-apmu code functions). Then U-Boot switches all cores to HYP
mode.
Who did the port? Is it upstream?
AFAIR Iurii Konovalenko did this port, he is also an author of
xen/arch/arm/platforms/rcar2.c.
I don't think U-Boot changes are upsteamed. But anybody who wants to
run Xen on Lager board is able (I think) to apply
published patches [2] to U-Boot and build it.
The same way anybody who will want to run Xen on Stout board will be able
to apply U-Boot patches I will attach to the future Wiki page for Stout board.
I am a bit concerned that patch for lager has never been upstreamed. Is
it at least part of the Renesas BSP?
What's the plan for Stout support?
While jump into Xen on a boot core, all non-boot cores are left in
U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
used for).
Platform R-Car2 code in Xen doesn't power on cores, it just "brings
them to Xen".
What does the address 0xe63c corresponds too? From the DT it seems it is
part of the ICRAM. But it is not clear why you write in there.
Yes, it is a part of the ICRAM.
Unfortunately, I am not an expert in such code to definitively say how
it is supposed to work.
But it seems that 0xE63C0FFC is an address which is being polled by
non-boot core in U-Boot. It was set to zero value
beforehand. So, writing an actual value to this address, Xen triggers
an action for bringing non-boot core up to Xen.
Waiting loop in U-Boot:
asm(".arm \n"
".align 2 \n"
".global smp_waitloop \n"
"smp_waitloop: \n"
"1: wfe \n"
"ldr r0, =0xE63C0FFC \n"
"ldr r0, [r0] \n"
"teq r0, #0x0 \n"
"beq 1b \n"
"b _do_nonsec_entry \n"
".type smp_waitloop, %function \n"
".size smp_waitloop, .-smp_waitloop \n");
Trigger code in Xen:
writel(__pa(init_secondary), 0xE63C0FFC);
Could you point to any relevant documentation?
I am afraid, I can't point to documentation.
While the code was added for Lager and you just piggy-back on it,
if you already hack U-boot to bring-up CPUs in hyp mode, then you better
add PSCI support.
To be honest, the lager support was likely accepted based on the code
would make the way to Upstream. It is now been 3 years without any
change. If there are no plan to address that, then I will send a patch
to drop the support for Lager in Xen.
Cheers,
--
Julien Gral
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
On 10/08/18 13:43, Paul Durrant wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:37 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> > On 10.08.18 at 14:22, wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: 10 August 2018 13:13 To: Paul Durrant Cc: xen-devel Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >>> On 10.08.18 at 14:08, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:02 >> To: Paul Durrant >> Cc: xen-devel >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> > On 10.08.18 at 12:37, wrote: >>> These are probably both candidates for back-port. >>> >>> Paul Durrant (2): >>> x86/hvm/ioreq: MMIO range checking completely ignores direction >> flag >>> x86/hvm/emulate: make sure rep I/O emulation does not cross GFN >>> boundaries >>> >>> xen/arch/x86/hvm/emulate.c | 17 - >>> xen/arch/x86/hvm/ioreq.c | 15 ++- >>> 2 files changed, 26 insertions(+), 6 deletions(-) >> I take it this isn't yet what we've talked about yesterday on irc? >> > This is the band-aid fix. I can now show correct handling of a rep mov > walking off MMIO into RAM. But that's not the problem we're having. In our case the bad behavior is with a single MOV. That's why I had assumed that your plan to fiddle with null_handler would help in our case as well, while this series clearly won't (afaict). >>> Oh, I see. A single MOV spanning MMIO and RAM has undefined behaviour >> though >>> as I understand it. Am I incorrect? >> I'm not aware of SDM or PM saying anything like this. Anyway, the >> specific case where this is being observed as an issue is when >> accessing the last few bytes of a normal RAM page followed by a >> ballooned out one. The balloon driver doesn't remove the virtual >> mapping of such pages (presumably in order to not shatter super >> pages); observation is with the old XenoLinux one, but from code >> inspection the upstream one behaves the same. >> >> Unless we want to change the balloon driver's behavior, at least >> this specific case needs to be considered having defined behavior, >> I think. >> > Ok. I'll see what I can do. It is a software error to try and cross boundaries. Modern processors do their best to try and cause the correct behaviour to occur, albeit with a massive disclaimer about the performance hit. Older processors didn't cope. As far as I'm concerned, its fine to terminate a emulation which crosses a boundary with the null ops. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/spec-ctrl: Yet more fixes for xpti= parsing
>>> On 10.08.18 at 14:42, wrote: > As it currently stands, 'xpti=dom0' is indistinguishable from the default > value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed > hardware. > > Switch opt_xpti to use -1 as a default like all our other related options, and > clobber it as soon as we have a string to parse. > > In addition, 'xpti' alone should be interpreted in its positive boolean form, > rather than resulting in a parse error. > > (XEN) parameter "xpti" has invalid value "", rc=-22! > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125843: trouble: blocked/broken/pass
flight 125843 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125843/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 4b60c40659b34b6577a6bc91eb4115458a0e425f baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z9 days Failing since125741 2018-08-02 10:01:09 Z8 days 33 attempts Testing same since 125802 2018-08-08 11:00:47 Z2 days 17 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 512 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [seabios baseline-only test] 75059: regressions - FAIL
This run is configured for baseline tests only. flight 75059 seabios real [real] http://osstest.xensource.com/osstest/logs/75059/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 74972 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 74972 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 74972 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail REGR. vs. 74972 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 74972 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 74972 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail never pass version targeted for testing: seabios 95f850c2377968ad951121ceaab76d40a9eed593 baseline version: seabios 8c3f57ea1217ea0c80a72898bc35baa0e14af0e0 Last test of basis74972 2018-07-15 19:25:28 Z 25 days Testing same since75059 2018-08-10 07:53:01 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictfail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 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.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 95f850c2377968ad951121ceaab76d40a9eed593 Author: Kevin O'Connor Date: Thu Aug 9 08:29:20 2018 -0400 docs: Update download file link Released versions are now at: https://www.seabios.org/downloads/ Signed-off-by: Kevin O'Connor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 125841: regressions - trouble: blocked/fail
flight 125841 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125841/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd 0645c33e3ecbd94e5fdeaa82b56f3c96bf4e637d baseline version: freebsd bf65d05707104df94117a293327d797d71a0118d Last test of basis 125317 2018-07-18 09:19:47 Z 23 days Failing since125467 2018-07-20 09:19:59 Z 21 days 10 attempts Testing same since 125841 2018-08-10 09:19:03 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae alc allanjude andrew antoine araujo asomers avg bapt bde bdrewery br brd brooks bwidawsk bz cem cognet cperciva cy dab daichi davidcs delphij dim eadler emaste eugen fsu ganbold gavin gjb glebius hselasky ian imp jhb jhibbits jhixson jtl kevans kevlo kib kp leitao luporl lwhsu manu marius markj Matthew Ahrens mav mckusick mm mmacy mmel np obrien oshogbo pfg phk pkelsey pstef rmacklem royger rpokala rrs sef shurd sjg trasz truckman tsoome tuexen uqs will woodsb02 wulf zleslie jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 9026 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>> On 10.08.18 at 12:37, wrote: > These are probably both candidates for back-port. > > Paul Durrant (2): > x86/hvm/ioreq: MMIO range checking completely ignores direction flag > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN > boundaries > > xen/arch/x86/hvm/emulate.c | 17 - > xen/arch/x86/hvm/ioreq.c | 15 ++- > 2 files changed, 26 insertions(+), 6 deletions(-) I take it this isn't yet what we've talked about yesterday on irc? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/paravirt: use a single ops structure
>>> On 10.08.18 at 13:52, wrote:
> --- a/arch/x86/hyperv/mmu.c
> +++ b/arch/x86/hyperv/mmu.c
> @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void)
>
> if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
> pr_info("Using hypercall for remote TLB flush\n");
> - pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
> + pv_ops.pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
Taking just this as example, why not
pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others;
? Both pv_ and _ops are redundant on the field names.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:02 > To: Paul Durrant > Cc: xen-devel > Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 12:37, wrote: > > These are probably both candidates for back-port. > > > > Paul Durrant (2): > > x86/hvm/ioreq: MMIO range checking completely ignores direction flag > > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN > > boundaries > > > > xen/arch/x86/hvm/emulate.c | 17 - > > xen/arch/x86/hvm/ioreq.c | 15 ++- > > 2 files changed, 26 insertions(+), 6 deletions(-) > > I take it this isn't yet what we've talked about yesterday on irc? > This is the band-aid fix. I can now show correct handling of a rep mov walking off MMIO into RAM. Paul > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 12:59
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> >>> On 10.08.18 at 12:37, wrote:
> > --- a/xen/arch/x86/hvm/emulate.c
> > +++ b/xen/arch/x86/hvm/emulate.c
> > @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> > hvmtrace_io_assist();
> > }
> >
> > -vio->io_req = p;
> > +/*
> > + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> > + * necessary to ensure that the correct device model is targetted
> > + * or that we correctly handle a rep op spanning MMIO and RAM.
> > + */
> > +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> > +{
> > +unsigned long off = p.addr & ~PAGE_MASK;
> >
> > +p.count = min_t(unsigned long,
> > +p.count,
> > +p.df ?
> > +(off + p.size) / p.size :
> > +(PAGE_SIZE - off) / p.size);
>
> For misaligned requests you need to make sure p.count doesn't end
> up as zero (which can now happen in the forwards case). Or do you
> rely on callers (hvmemul_do_io_addr() in particular) splitting such
> requests already?
Well I have a test case where that split is not happening. Adding a safety
check for p.count == 0 at this point should be done.
> Yet in that case it's not clear to me whether
> anything needs changing here in the first place. (Similarly in the
> backwards case I think the first iteration risks crossing a page
> boundary, and then the batch should be clipped to count 1.)
>
Ok. Sounds like clipping to 1 rep in both circumstances would be best.
Paul
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>> On 10.08.18 at 14:08, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:02 >> To: Paul Durrant >> Cc: xen-devel >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >>> On 10.08.18 at 12:37, wrote: >> > These are probably both candidates for back-port. >> > >> > Paul Durrant (2): >> > x86/hvm/ioreq: MMIO range checking completely ignores direction flag >> > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN >> > boundaries >> > >> > xen/arch/x86/hvm/emulate.c | 17 - >> > xen/arch/x86/hvm/ioreq.c | 15 ++- >> > 2 files changed, 26 insertions(+), 6 deletions(-) >> >> I take it this isn't yet what we've talked about yesterday on irc? >> > > This is the band-aid fix. I can now show correct handling of a rep mov > walking off MMIO into RAM. But that's not the problem we're having. In our case the bad behavior is with a single MOV. That's why I had assumed that your plan to fiddle with null_handler would help in our case as well, while this series clearly won't (afaict). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:13 > To: Paul Durrant > Cc: xen-devel > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 14:08, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:02 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > >> >>> On 10.08.18 at 12:37, wrote: > >> > These are probably both candidates for back-port. > >> > > >> > Paul Durrant (2): > >> > x86/hvm/ioreq: MMIO range checking completely ignores direction flag > >> > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN > >> > boundaries > >> > > >> > xen/arch/x86/hvm/emulate.c | 17 - > >> > xen/arch/x86/hvm/ioreq.c | 15 ++- > >> > 2 files changed, 26 insertions(+), 6 deletions(-) > >> > >> I take it this isn't yet what we've talked about yesterday on irc? > >> > > > > This is the band-aid fix. I can now show correct handling of a rep mov > > walking off MMIO into RAM. > > But that's not the problem we're having. In our case the bad behavior > is with a single MOV. That's why I had assumed that your plan to fiddle > with null_handler would help in our case as well, while this series clearly > won't (afaict). > Oh, I see. A single MOV spanning MMIO and RAM has undefined behaviour though as I understand it. Am I incorrect? Paul > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/paravirt: use a single ops structure
On 10/08/18 14:06, Jan Beulich wrote:
On 10.08.18 at 13:52, wrote:
>> --- a/arch/x86/hyperv/mmu.c
>> +++ b/arch/x86/hyperv/mmu.c
>> @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void)
>>
>> if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
>> pr_info("Using hypercall for remote TLB flush\n");
>> -pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
>> +pv_ops.pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
>
> Taking just this as example, why not
>
> pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others;
>
> ? Both pv_ and _ops are redundant on the field names.
Good idea.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
>>> On 10.08.18 at 14:22, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 10 August 2018 13:13 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >>> On 10.08.18 at 14:08, wrote: >> >> -Original Message- >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 10 August 2018 13:02 >> >> To: Paul Durrant >> >> Cc: xen-devel >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes >> >> >> >> >>> On 10.08.18 at 12:37, wrote: >> >> > These are probably both candidates for back-port. >> >> > >> >> > Paul Durrant (2): >> >> > x86/hvm/ioreq: MMIO range checking completely ignores direction flag >> >> > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN >> >> > boundaries >> >> > >> >> > xen/arch/x86/hvm/emulate.c | 17 - >> >> > xen/arch/x86/hvm/ioreq.c | 15 ++- >> >> > 2 files changed, 26 insertions(+), 6 deletions(-) >> >> >> >> I take it this isn't yet what we've talked about yesterday on irc? >> >> >> > >> > This is the band-aid fix. I can now show correct handling of a rep mov >> > walking off MMIO into RAM. >> >> But that's not the problem we're having. In our case the bad behavior >> is with a single MOV. That's why I had assumed that your plan to fiddle >> with null_handler would help in our case as well, while this series clearly >> won't (afaict). >> > > Oh, I see. A single MOV spanning MMIO and RAM has undefined behaviour though > as I understand it. Am I incorrect? I'm not aware of SDM or PM saying anything like this. Anyway, the specific case where this is being observed as an issue is when accessing the last few bytes of a normal RAM page followed by a ballooned out one. The balloon driver doesn't remove the virtual mapping of such pages (presumably in order to not shatter super pages); observation is with the old XenoLinux one, but from code inspection the upstream one behaves the same. Unless we want to change the balloon driver's behavior, at least this specific case needs to be considered having defined behavior, I think. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/spec-ctrl: Yet more fixes for xpti= parsing
As it currently stands, 'xpti=dom0' is indistinguishable from the default
value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on fixed
hardware.
Switch opt_xpti to use -1 as a default like all our other related options, and
clobber it as soon as we have a string to parse.
In addition, 'xpti' alone should be interpreted in its positive boolean form,
rather than resulting in a parse error.
(XEN) parameter "xpti" has invalid value "", rc=-22!
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
v2:
* Don't intepret "xpti=dom0," as "xpti"
---
xen/arch/x86/spec_ctrl.c| 15 +++
xen/include/asm-x86/spec_ctrl.h | 2 +-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 32a4ea6..32213ac 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -420,8 +420,7 @@ static bool __init should_use_eager_fpu(void)
}
}
-#define OPT_XPTI_DEFAULT 0xff
-uint8_t __read_mostly opt_xpti = OPT_XPTI_DEFAULT;
+int8_t __read_mostly opt_xpti = -1;
static __init void xpti_init_default(uint64_t caps)
{
@@ -439,6 +438,14 @@ static __init int parse_xpti(const char *s)
const char *ss;
int val, rc = 0;
+/* Inhibit the defaults as an explicit choice has been given. */
+if ( opt_xpti == -1 )
+opt_xpti = 0;
+
+/* Interpret 'xpti' alone in its positive boolean form. */
+if ( *s == '\0' )
+opt_xpti = OPT_XPTI_DOM0 | OPT_XPTI_DOMU;
+
do {
ss = strchr(s, ',');
if ( !ss )
@@ -456,7 +463,7 @@ static __init int parse_xpti(const char *s)
default:
if ( !strcmp(s, "default") )
-opt_xpti = OPT_XPTI_DEFAULT;
+opt_xpti = -1;
else if ( (val = parse_boolean("dom0", s, ss)) >= 0 )
opt_xpti = (opt_xpti & ~OPT_XPTI_DOM0) |
(val ? OPT_XPTI_DOM0 : 0);
@@ -618,7 +625,7 @@ void __init init_speculation_mitigations(void)
if ( default_xen_spec_ctrl )
setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
-if ( opt_xpti == OPT_XPTI_DEFAULT )
+if ( opt_xpti == -1 )
xpti_init_default(caps);
if ( opt_xpti == 0 )
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 5b40afb..fea8260 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -34,7 +34,7 @@ extern bool bsp_delay_spec_ctrl;
extern uint8_t default_xen_spec_ctrl;
extern uint8_t default_spec_ctrl_flags;
-extern uint8_t opt_xpti;
+extern int8_t opt_xpti;
#define OPT_XPTI_DOM0 0x01
#define OPT_XPTI_DOMU 0x02
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/spec-ctrl: Yet more fixes for xpti= parsing
On 10/08/2018 09:08, Jan Beulich wrote: On 09.08.18 at 18:38, wrote: >> As it currently stands, 'xpti=dom0' is indistinguishable from the default >> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on >> fixed >> hardware. >> >> Switch opt_xpti to use -1 as a default like all our other related options, >> and >> clobber it as soon as we have a string to parse. >> >> In addition, 'xpti' alone should be interpreted in its positive boolean form, >> rather than resulting in a parse error. > But e.g. "xpti=dom0," should not be. I.e. ... > >> @@ -439,6 +438,10 @@ static __init int parse_xpti(const char *s) >> const char *ss; >> int val, rc = 0; >> >> +/* Inhibit the defaults as an explicit choice has been given. */ >> +if ( opt_xpti == -1 ) >> +opt_xpti = 0; > ... the check for an empty string pointed to by s needs to be put here, > ahead of the loop. There are 3 options: 1) What is presented here. 2) Unroll the start of the loop to be able to reach case 1: 3) Double up the positive case. Given how you review code generally, options 2 and 3 are off the table. If someone typo's the command like, nothing is going to work as they intended in the first place. Therefore, "xpti=dom0," doing the wrong thing is not a problem. I don't see why we should go out of our way to cover that specific corner case, or do you suggest we start putting a spellchecker into the parsing and start guessing at what the user meant? This would be far more useful if you want to start second guessing what the user wrote... ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
On 10/08/18 11:37, Paul Durrant wrote:
> When emulating a rep I/O operation it is possible that the ioreq will
> describe a single operation that spans multiple GFNs. This is fine as long
> as all those GFNs fall within an MMIO region covered by a single device
> model, but unfortunately the higher levels of the emulation code do not
> guarantee that. This is something that should almost certainly be fixed,
> but in the meantime this patch makes sure that MMIO is truncated at GFN
> boundaries and hence the appropriate device model is re-evaluated for each
> target GFN.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/hvm/emulate.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 8385c62145..d6a81ec4d1 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> hvmtrace_io_assist();
> }
>
> -vio->io_req = p;
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> + * necessary to ensure that the correct device model is targetted
> + * or that we correctly handle a rep op spanning MMIO and RAM.
> + */
> +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> +{
> +unsigned long off = p.addr & ~PAGE_MASK;
>
> +p.count = min_t(unsigned long,
> +p.count,
> +p.df ?
> +(off + p.size) / p.size :
> +(PAGE_SIZE - off) / p.size);
(p.df ? (off + p.size) : (PAGE_SIZE - off)) / p.size
?
> +}
> +
> +vio->io_req = p;
You'll get a cleaner patch if you retain the newline between these two.
Both can be fixed up on commit. From a functional point of view, this
looks fine.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:37 > To: Paul Durrant > Cc: xen-devel > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 14:22, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:13 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > >> >>> On 10.08.18 at 14:08, wrote: > >> >> -Original Message- > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 10 August 2018 13:02 > >> >> To: Paul Durrant > >> >> Cc: xen-devel > >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> >> > >> >> >>> On 10.08.18 at 12:37, wrote: > >> >> > These are probably both candidates for back-port. > >> >> > > >> >> > Paul Durrant (2): > >> >> > x86/hvm/ioreq: MMIO range checking completely ignores direction > flag > >> >> > x86/hvm/emulate: make sure rep I/O emulation does not cross GFN > >> >> > boundaries > >> >> > > >> >> > xen/arch/x86/hvm/emulate.c | 17 - > >> >> > xen/arch/x86/hvm/ioreq.c | 15 ++- > >> >> > 2 files changed, 26 insertions(+), 6 deletions(-) > >> >> > >> >> I take it this isn't yet what we've talked about yesterday on irc? > >> >> > >> > > >> > This is the band-aid fix. I can now show correct handling of a rep mov > >> > walking off MMIO into RAM. > >> > >> But that's not the problem we're having. In our case the bad behavior > >> is with a single MOV. That's why I had assumed that your plan to fiddle > >> with null_handler would help in our case as well, while this series clearly > >> won't (afaict). > >> > > > > Oh, I see. A single MOV spanning MMIO and RAM has undefined behaviour > though > > as I understand it. Am I incorrect? > > I'm not aware of SDM or PM saying anything like this. Anyway, the > specific case where this is being observed as an issue is when > accessing the last few bytes of a normal RAM page followed by a > ballooned out one. The balloon driver doesn't remove the virtual > mapping of such pages (presumably in order to not shatter super > pages); observation is with the old XenoLinux one, but from code > inspection the upstream one behaves the same. > > Unless we want to change the balloon driver's behavior, at least > this specific case needs to be considered having defined behavior, > I think. > Ok. I'll see what I can do. Paul > Jan > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board
On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote: Hi Julien. Hi Oleksandr, On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote: On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote: On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall wrote: Somehow I thought the platform was 64-bit and found a SOC name very similar to it. Sorry for the confusion. PSCI seems indeed not supported for that platform. R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI. But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790) However, the code looks fairly different than what we have in Xen. For instance secondary CPU seems to require to initialize CNTVOFF, the function to power on a CPU also looks different. Sorry, which code you are taking about, U-Boot or Linux? The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of the cases, Xen should replicate what Linux does. I am trying to understand why such differences at the moment. As I understand, the SMP code for Linux can't be used in Xen, since the requirement is to boot into Xen with cores already being in Hypervisor mode. But, all cores seems to start in Monitor mode after powering them up. So, they must be switched into Hypervisor mode beforehand, correct? I am quite confused here. If a CPU will be in hypervisor mode for Xen, how come the same CPU will boot in monitor mode for Linux? Surely there should be no difference in term of boot here. Are you using different firmware here? U-Boot brings non-boot cores up (using ported from Linux's platsmp-apmu code functions). Then U-Boot switches all cores to HYP mode. Who did the port? Is it upstream? While jump into Xen on a boot core, all non-boot cores are left in U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is used for). Platform R-Car2 code in Xen doesn't power on cores, it just "brings them to Xen". What does the address 0xe63c corresponds too? From the DT it seems it is part of the ICRAM. But it is not clear why you write in there. Could you point to any relevant documentation? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote: > >>> On 08.08.18 at 12:07, wrote: > > So it's done before the iommu is initialized. This is required in > > order to be able to fetch the MMCFG regions from the domain struct. > > Is this a useful change to make? Regions not reported through the MCFG > table will need punching holes anyway, so why not punch holes uniformly > in all cases, allowing the hole punching code to be tested even on systems > without non-boot-time-available regions? I can add this hole-punching code to register_vpci_mmcfg_handler so I can remove this reordering. I'm however struggling to find a function that will set a p2m range to p2m_invalid. All the functions that I find to deal with this assume that you know the memory type you are trying to remove (for example clear_identity_p2m_entry) and fail if the current type is different than expected. In this case it's quite likely that the MMCFG region is not mapped to anything, should I introduce a new helper that sets a p2m range to p2m_invalid regardless of the current type? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125839: trouble: blocked/broken/pass
flight 125839 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125839/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125729 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken blocked in 125729 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 4b60c40659b34b6577a6bc91eb4115458a0e425f baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125729 2018-08-01 11:00:39 Z8 days Failing since125741 2018-08-02 10:01:09 Z8 days 32 attempts Testing same since 125802 2018-08-08 11:00:47 Z1 days 16 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Doug Goldstein George Dunlap Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Roger Pau Monné Stefano Stabellini 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 hosts-allocate broken-step build-arm64-xsm capture-logs Not pushing. (No revision log; it would be 512 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] MMIO emulation fixes
These are probably both candidates for back-port. Paul Durrant (2): x86/hvm/ioreq: MMIO range checking completely ignores direction flag x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries xen/arch/x86/hvm/emulate.c | 17 - xen/arch/x86/hvm/ioreq.c | 15 ++- 2 files changed, 26 insertions(+), 6 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH net-next] xen-netfront: fix warn message as irq device name has '/'
On 09/08/18 08:03, Xiao Liang wrote:
> There is a call trace generated after commit
> 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file
> found
> under /proc/irq/xx/.
>
> This patch only picks up device type and id as its name.
>
> With the patch, now /proc/interrupts looks like and the warning message gone:
> 70: 21 0 0 0 xen-dyn-event
> vif0-q0-tx
> 71: 15 0 0 0 xen-dyn-event
> vif0-q0-rx
> 72: 14 0 0 0 xen-dyn-event
> vif0-q1-tx
> 73: 33 0 0 0 xen-dyn-event
> vif0-q1-rx
> 74: 12 0 0 0 xen-dyn-event
> vif0-q2-tx
> 75: 24 0 0 0 xen-dyn-event
> vif0-q2-rx
> 76: 19 0 0 0 xen-dyn-event
> vif0-q3-tx
> 77: 21 0 0 0 xen-dyn-event
> vif0-q3-rx
>
> Below is call trace information without this patch:
>
> name 'device/vif/0-q0-tx'
> WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
> RIP: 0010:__xlate_proc_name+0x85/0xa0
> RSP: 0018:b85c40473c18 EFLAGS: 00010286
> RAX: RBX: 0006 RCX: 0006
> RDX: 0007 RSI: 0096 RDI: 984c7f516930
> RBP: b85c40473cb8 R08: 002c R09: 0229
> R10: R11: 0001 R12: b85c40473c98
> R13: b85c40473cb8 R14: b85c40473c50 R15:
> FS: () GS:984c7f50() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f69b6899038 CR3: 1c20a006 CR4: 001606e0
> Call Trace:
> __proc_create+0x45/0x230
> ? snprintf+0x49/0x60
> proc_mkdir_data+0x35/0x90
> register_handler_proc+0xef/0x110
> ? proc_register+0xfc/0x110
> ? proc_create_data+0x70/0xb0
> __setup_irq+0x39b/0x660
> ? request_threaded_irq+0xad/0x160
> request_threaded_irq+0xf5/0x160
> ? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
> bind_evtchn_to_irqhandler+0x3d/0x70
> ? xenbus_alloc_evtchn+0x41/0xa0
> netback_changed+0xa46/0xcda [xen_netfront]
> ? find_watch+0x40/0x40
> xenwatch_thread+0xc5/0x160
> ? finish_wait+0x80/0x80
> kthread+0x112/0x130
> ? kthread_create_worker_on_cpu+0x70/0x70
> ret_from_fork+0x35/0x40
> Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41
> 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff
> ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
> ---[ end trace 650e5561b0caab3a ]---
>
> Signed-off-by: Xiao Liang
> ---
> drivers/net/xen-netfront.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 799cba4624a5..6f40df4a452e 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1604,14 +1604,16 @@ static int xennet_init_queue(struct netfront_queue
> *queue)
> {
> unsigned short i;
> int err = 0;
> + int devid = 0;
>
> spin_lock_init(>tx_lock);
> spin_lock_init(>rx_lock);
>
> timer_setup(>rx_refill_timer, rx_refill_timeout, 0);
>
> - snprintf(queue->name, sizeof(queue->name), "%s-q%u",
> - queue->info->xbdev->nodename, queue->id);
> + kstrtoint(strrchr(queue->info->xbdev->nodename,'/')+1, 10, );
Please add blanks before '/' and around the +.
With that you can add my:
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 4/4] xen/arm: Reuse R-Car Gen2 platform code for Stout board
On Fri, Aug 10, 2018 at 12:44 PM, Julien Grall wrote:
> On 08/09/2018 07:18 PM, Oleksandr Tyshchenko wrote:
>>
>> Hi Julien.
>
>
> Hi Oleksandr,
Hi Julien
>
>> On Thu, Aug 9, 2018 at 7:20 PM, Julien Grall wrote:
>>>
>>>
>>>
>>> On 08/09/2018 05:18 PM, Oleksandr Tyshchenko wrote:
On Thu, Aug 9, 2018 at 7:10 PM, Julien Grall
wrote:
>
>
> Somehow I thought the platform was 64-bit and found a SOC name very
> similar
> to it. Sorry for the confusion. PSCI seems indeed not supported for
> that
> platform.
R-Car Gen3 is ARM64 (H2 SoC -> r8a7790) and does support PSCI.
But R-Car Gen2 is ARM32 (H2 SoC -> r8a7790)
>
> However, the code looks fairly different than what we have in Xen. For
> instance secondary CPU seems to require to initialize CNTVOFF, the
> function
> to power on a CPU also looks different.
Sorry, which code you are taking about, U-Boot or Linux?
>>>
>>>
>>>
>>> The SMP code in Linux vs the SMP code in Xen for the R-Car. In most of
>>> the
>>> cases, Xen should replicate what Linux does.
>>>
>>> I am trying to understand why such differences at the moment.
>>
>>
>> As I understand, the SMP code for Linux can't be used in Xen, since
>> the requirement is to boot into Xen with cores already being in
>> Hypervisor mode.
>> But, all cores seems to start in Monitor mode after powering them up.
>> So, they must be switched into Hypervisor mode beforehand, correct?
>
>
> I am quite confused here. If a CPU will be in hypervisor mode for Xen, how
> come the same CPU will boot in monitor mode for Linux? Surely there should
> be no difference in term of boot here. Are you using different firmware
> here?
Yes, in order to run modified U-Boot is used. You can see here what
exactly was modified.
This instruction [1] contains link to patches [2] (see "Apply
additional patches" step)
which should be applied to bare U-Boot.
[1]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-01/msg02475.html
>
>>
>> U-Boot brings non-boot cores up (using ported from Linux's
>> platsmp-apmu code functions). Then U-Boot switches all cores to HYP
>> mode.
>
>
> Who did the port? Is it upstream?
AFAIR Iurii Konovalenko did this port, he is also an author of
xen/arch/arm/platforms/rcar2.c.
I don't think U-Boot changes are upsteamed. But anybody who wants to
run Xen on Lager board is able (I think) to apply
published patches [2] to U-Boot and build it.
The same way anybody who will want to run Xen on Stout board will be able
to apply U-Boot patches I will attach to the future Wiki page for Stout board.
>
>> While jump into Xen on a boot core, all non-boot cores are left in
>> U-Boot to wait to be "woken up by Xen" (actually rcar2_smp_init() is
>> used for).
>> Platform R-Car2 code in Xen doesn't power on cores, it just "brings
>> them to Xen".
>
>
> What does the address 0xe63c corresponds too? From the DT it seems it is
> part of the ICRAM. But it is not clear why you write in there.
Yes, it is a part of the ICRAM.
Unfortunately, I am not an expert in such code to definitively say how
it is supposed to work.
But it seems that 0xE63C0FFC is an address which is being polled by
non-boot core in U-Boot. It was set to zero value
beforehand. So, writing an actual value to this address, Xen triggers
an action for bringing non-boot core up to Xen.
Waiting loop in U-Boot:
asm(".arm \n"
".align 2 \n"
".global smp_waitloop \n"
"smp_waitloop: \n"
"1: wfe \n"
"ldr r0, =0xE63C0FFC \n"
"ldr r0, [r0] \n"
"teq r0, #0x0 \n"
"beq 1b \n"
"b _do_nonsec_entry \n"
".type smp_waitloop, %function \n"
".size smp_waitloop, .-smp_waitloop \n");
Trigger code in Xen:
writel(__pa(init_secondary), 0xE63C0FFC);
>
> Could you point to any relevant documentation?
I am afraid, I can't point to documentation.
>
> Cheers,
>
> --
> Julien Grall
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
On 10/08/18 12:50, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 12:14
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich
>> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
>> does not cross GFN boundaries
>>
>> On 10/08/18 11:37, Paul Durrant wrote:
>>> When emulating a rep I/O operation it is possible that the ioreq will
>>> describe a single operation that spans multiple GFNs. This is fine as long
>>> as all those GFNs fall within an MMIO region covered by a single device
>>> model, but unfortunately the higher levels of the emulation code do not
>>> guarantee that. This is something that should almost certainly be fixed,
>>> but in the meantime this patch makes sure that MMIO is truncated at GFN
>>> boundaries and hence the appropriate device model is re-evaluated for
>> each
>>> target GFN.
>>>
>>> Signed-off-by: Paul Durrant
>>> ---
>>> Cc: Jan Beulich
>>> Cc: Andrew Cooper
>>> ---
>>> xen/arch/x86/hvm/emulate.c | 17 -
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>>> index 8385c62145..d6a81ec4d1 100644
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -184,8 +184,23 @@ static int hvmemul_do_io(
>>> hvmtrace_io_assist();
>>> }
>>>
>>> -vio->io_req = p;
>>> +/*
>>> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
>>> + * necessary to ensure that the correct device model is targetted
>>> + * or that we correctly handle a rep op spanning MMIO and RAM.
>>> + */
>>> +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
>>> +{
>>> +unsigned long off = p.addr & ~PAGE_MASK;
>>>
>>> +p.count = min_t(unsigned long,
>>> +p.count,
>>> +p.df ?
>>> +(off + p.size) / p.size :
>>> +(PAGE_SIZE - off) / p.size);
>> (p.df ? (off + p.size) : (PAGE_SIZE - off)) / p.size
>>
> Yes, I suppose so.
>
>> ?
>>
>>> +}
>>> +
>>> +vio->io_req = p;
>> You'll get a cleaner patch if you retain the newline between these two.
>>
>> Both can be fixed up on commit. From a functional point of view, this
>> looks fine.
>>
> Ok. I'll leave to you then :-)
Sure.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 12:14
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> On 10/08/18 11:37, Paul Durrant wrote:
> > When emulating a rep I/O operation it is possible that the ioreq will
> > describe a single operation that spans multiple GFNs. This is fine as long
> > as all those GFNs fall within an MMIO region covered by a single device
> > model, but unfortunately the higher levels of the emulation code do not
> > guarantee that. This is something that should almost certainly be fixed,
> > but in the meantime this patch makes sure that MMIO is truncated at GFN
> > boundaries and hence the appropriate device model is re-evaluated for
> each
> > target GFN.
> >
> > Signed-off-by: Paul Durrant
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > ---
> > xen/arch/x86/hvm/emulate.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> > index 8385c62145..d6a81ec4d1 100644
> > --- a/xen/arch/x86/hvm/emulate.c
> > +++ b/xen/arch/x86/hvm/emulate.c
> > @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> > hvmtrace_io_assist();
> > }
> >
> > -vio->io_req = p;
> > +/*
> > + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> > + * necessary to ensure that the correct device model is targetted
> > + * or that we correctly handle a rep op spanning MMIO and RAM.
> > + */
> > +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> > +{
> > +unsigned long off = p.addr & ~PAGE_MASK;
> >
> > +p.count = min_t(unsigned long,
> > +p.count,
> > +p.df ?
> > +(off + p.size) / p.size :
> > +(PAGE_SIZE - off) / p.size);
>
> (p.df ? (off + p.size) : (PAGE_SIZE - off)) / p.size
>
Yes, I suppose so.
> ?
>
> > +}
> > +
> > +vio->io_req = p;
>
> You'll get a cleaner patch if you retain the newline between these two.
>
> Both can be fixed up on commit. From a functional point of view, this
> looks fine.
>
Ok. I'll leave to you then :-)
Paul
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/10] x86/paravirt: make paravirt_patch_call() and paravirt_patch_jmp() static
paravirt_patch_call() and paravirt_patch_jmp() are used in paravirt.c
only. Convert them to static.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 6 --
arch/x86/kernel/paravirt.c| 12 ++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 180bc0bff0fb..036b2f88f105 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -370,12 +370,6 @@ extern struct pv_lock_ops pv_lock_ops;
unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
-unsigned paravirt_patch_call(void *insnbuf,
-const void *target, u16 tgt_clobbers,
-unsigned long addr, u16 site_clobbers,
-unsigned len);
-unsigned paravirt_patch_jmp(void *insnbuf, const void *target,
- unsigned long addr, unsigned len);
unsigned paravirt_patch_default(u8 type, u16 clobbers, void *insnbuf,
unsigned long addr, unsigned len);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 930c88341e4e..ce560b916b1f 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -80,10 +80,10 @@ struct branch {
u32 delta;
} __attribute__((packed));
-unsigned paravirt_patch_call(void *insnbuf,
-const void *target, u16 tgt_clobbers,
-unsigned long addr, u16 site_clobbers,
-unsigned len)
+static unsigned paravirt_patch_call(void *insnbuf,
+ const void *target, u16 tgt_clobbers,
+ unsigned long addr, u16 site_clobbers,
+ unsigned len)
{
struct branch *b = insnbuf;
unsigned long delta = (unsigned long)target - (addr+5);
@@ -102,8 +102,8 @@ unsigned paravirt_patch_call(void *insnbuf,
return 5;
}
-unsigned paravirt_patch_jmp(void *insnbuf, const void *target,
- unsigned long addr, unsigned len)
+static unsigned paravirt_patch_jmp(void *insnbuf, const void *target,
+ unsigned long addr, unsigned len)
{
struct branch *b = insnbuf;
unsigned long delta = (unsigned long)target - (addr+5);
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/10] x86/paravirt: use a single ops structure
Instead of using six globally visible paravirt ops structures combine
them in a single structure, keeping the original structures as
sub-structures.
This avoids the need to assemble struct paravirt_patch_template at
runtime on the stack each time apply_paravirt() is being called (i.e.
when loading a module).
Signed-off-by: Juergen Gross
---
arch/x86/hyperv/mmu.c | 4 +-
arch/x86/include/asm/paravirt.h | 51 ---
arch/x86/include/asm/paravirt_types.h | 13 +-
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/asm-offsets.c | 14 +-
arch/x86/kernel/asm-offsets_64.c | 7 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/vmware.c | 4 +-
arch/x86/kernel/kvm.c | 18 ++-
arch/x86/kernel/kvmclock.c| 4 +-
arch/x86/kernel/paravirt-spinlocks.c | 15 +-
arch/x86/kernel/paravirt.c| 278 +-
arch/x86/kernel/tsc.c | 2 +-
arch/x86/kernel/vsmp_64.c | 11 +-
arch/x86/xen/enlighten_pv.c | 32 ++--
arch/x86/xen/irq.c| 2 +-
arch/x86/xen/mmu_hvm.c| 2 +-
arch/x86/xen/mmu_pv.c | 28 ++--
arch/x86/xen/spinlock.c | 12 +-
arch/x86/xen/time.c | 4 +-
drivers/xen/time.c| 2 +-
21 files changed, 249 insertions(+), 258 deletions(-)
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index de27615c51ea..b34768cfb204 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void)
if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) {
pr_info("Using hypercall for remote TLB flush\n");
- pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
+ pv_ops.pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
} else {
pr_info("Using ext hypercall for remote TLB flush\n");
- pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others_ex;
+ pv_ops.pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others_ex;
}
}
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 76b4b5c056f3..1b86bb319393 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -265,11 +265,11 @@ static inline void set_iopl_mask(unsigned mask)
/* The paravirtualized I/O functions */
static inline void slow_down_io(void)
{
- pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
#ifdef REALLY_SLOW_IO
- pv_cpu_ops.io_delay();
- pv_cpu_ops.io_delay();
- pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
#endif
}
@@ -432,7 +432,7 @@ static inline void ptep_modify_prot_commit(struct mm_struct
*mm, unsigned long a
{
if (sizeof(pteval_t) > sizeof(long))
/* 5 arg words */
- pv_mmu_ops.ptep_modify_prot_commit(mm, addr, ptep, pte);
+ pv_ops.pv_mmu_ops.ptep_modify_prot_commit(mm, addr, ptep, pte);
else
PVOP_VCALL4(pv_mmu_ops.ptep_modify_prot_commit,
mm, addr, ptep, pte.pte);
@@ -453,7 +453,7 @@ static inline void set_pte_at(struct mm_struct *mm,
unsigned long addr,
{
if (sizeof(pteval_t) > sizeof(long))
/* 5 arg words */
- pv_mmu_ops.set_pte_at(mm, addr, ptep, pte);
+ pv_ops.pv_mmu_ops.set_pte_at(mm, addr, ptep, pte);
else
PVOP_VCALL4(pv_mmu_ops.set_pte_at, mm, addr, ptep, pte.pte);
}
@@ -663,7 +663,7 @@ static inline void arch_flush_lazy_mmu_mode(void)
static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,
phys_addr_t phys, pgprot_t flags)
{
- pv_mmu_ops.set_fixmap(idx, phys, flags);
+ pv_ops.pv_mmu_ops.set_fixmap(idx, phys, flags);
}
#if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
@@ -694,6 +694,9 @@ static __always_inline bool pv_vcpu_is_preempted(long cpu)
return PVOP_CALLEE1(bool, pv_lock_ops.vcpu_is_preempted, cpu);
}
+void __raw_callee_save___native_queued_spin_unlock(struct qspinlock *lock);
+bool __raw_callee_save___native_vcpu_is_preempted(long cpu);
+
#endif /* SMP && PARAVIRT_SPINLOCKS */
#ifdef CONFIG_X86_32
@@ -862,7 +865,7 @@ extern void default_banner(void);
COND_POP(set, CLBR_RCX, rcx); \
COND_POP(set, CLBR_RAX, rax)
-#define PARA_PATCH(struct, off)((PARAVIRT_PATCH_##struct + (off)) / 8)
+#define PARA_PATCH(off)((off) / 8)
#define PARA_SITE(ptype, ops) _PVSITE(ptype, ops, .quad, 8)
#define PARA_INDIRECT(addr)*addr(%rip)
#else
@@ -877,35 +880,35 @@ extern void default_banner(void);
COND_POP(set, CLBR_EDI, edi); \
COND_POP(set,
[Xen-devel] [PATCH 02/10] x86/paravirt: remove clobbers parameter from paravirt patch functions
The clobbers parameter from paravirt_patch_default() et al isn't used
any longer. Remove it.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 7 +++
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/paravirt.c| 14 +-
arch/x86/kernel/paravirt_patch_32.c | 5 ++---
arch/x86/kernel/paravirt_patch_64.c | 5 ++---
arch/x86/kernel/vsmp_64.c | 6 +++---
6 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 036b2f88f105..f6e24e78633b 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -84,7 +84,7 @@ struct pv_init_ops {
* the number of bytes of code generated, as we nop pad the
* rest in generic code.
*/
- unsigned (*patch)(u8 type, u16 clobber, void *insnbuf,
+ unsigned (*patch)(u8 type, void *insnbuf,
unsigned long addr, unsigned len);
} __no_randomize_layout;
@@ -370,14 +370,13 @@ extern struct pv_lock_ops pv_lock_ops;
unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
-unsigned paravirt_patch_default(u8 type, u16 clobbers, void *insnbuf,
+unsigned paravirt_patch_default(u8 type, void *insnbuf,
unsigned long addr, unsigned len);
unsigned paravirt_patch_insns(void *insnbuf, unsigned len,
const char *start, const char *end);
-unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
- unsigned long addr, unsigned len);
+unsigned native_patch(u8 type, void *ibuf, unsigned long addr, unsigned len);
int paravirt_disable_iospace(void);
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index a481763a3776..9729cee11149 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -594,7 +594,7 @@ void __init_or_module apply_paravirt(struct
paravirt_patch_site *start,
BUG_ON(p->len > MAX_PATCH_LEN);
/* prep the buffer with the original instructions */
memcpy(insnbuf, p->instr, p->len);
- used = pv_init_ops.patch(p->instrtype, p->clobbers, insnbuf,
+ used = pv_init_ops.patch(p->instrtype, insnbuf,
(unsigned long)p->instr, p->len);
BUG_ON(used > p->len);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index ce560b916b1f..f0c462fe2808 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -80,10 +80,8 @@ struct branch {
u32 delta;
} __attribute__((packed));
-static unsigned paravirt_patch_call(void *insnbuf,
- const void *target, u16 tgt_clobbers,
- unsigned long addr, u16 site_clobbers,
- unsigned len)
+static unsigned paravirt_patch_call(void *insnbuf, const void *target,
+ unsigned long addr, unsigned len)
{
struct branch *b = insnbuf;
unsigned long delta = (unsigned long)target - (addr+5);
@@ -148,7 +146,7 @@ static void *get_call_destination(u8 type)
return *((void **) + type);
}
-unsigned paravirt_patch_default(u8 type, u16 clobbers, void *insnbuf,
+unsigned paravirt_patch_default(u8 type, void *insnbuf,
unsigned long addr, unsigned len)
{
void *opfunc = get_call_destination(type);
@@ -171,10 +169,8 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers,
void *insnbuf,
/* If operation requires a jmp, then jmp */
ret = paravirt_patch_jmp(insnbuf, opfunc, addr, len);
else
- /* Otherwise call the function; assume target could
- clobber any caller-save reg */
- ret = paravirt_patch_call(insnbuf, opfunc, CLBR_ANY,
- addr, clobbers, len);
+ /* Otherwise call the function. */
+ ret = paravirt_patch_call(insnbuf, opfunc, addr, len);
return ret;
}
diff --git a/arch/x86/kernel/paravirt_patch_32.c
b/arch/x86/kernel/paravirt_patch_32.c
index 758e69d72ebf..e5c3a438149e 100644
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -30,8 +30,7 @@ unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len)
extern bool pv_is_native_spin_unlock(void);
extern bool pv_is_native_vcpu_is_preempted(void);
-unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
- unsigned long addr, unsigned len)
+unsigned native_patch(u8 type, void *ibuf, unsigned long addr, unsigned len)
{
const unsigned char *start, *end;
unsigned ret;
@@ -70,7 +69,7 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
[Xen-devel] [PATCH 09/10] x86/paravirt: move the Xen-only pv_irq_ops under the PARAVIRT_XXL umbrella
Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 38 ++-
arch/x86/include/asm/paravirt.h | 2 --
arch/x86/include/asm/paravirt_types.h | 2 ++
arch/x86/kernel/paravirt.c| 2 ++
4 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index 03bb451e4e6b..205e43e55144 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -88,24 +88,6 @@ static inline notrace void arch_local_irq_enable(void)
}
/*
- * Used in the idle loop; sti takes one instruction cycle
- * to complete:
- */
-static inline __cpuidle void arch_safe_halt(void)
-{
- native_safe_halt();
-}
-
-/*
- * Used when interrupts are already enabled or to
- * shutdown the processor:
- */
-static inline __cpuidle void halt(void)
-{
- native_halt();
-}
-
-/*
* For spinlocks, etc:
*/
static inline notrace unsigned long arch_local_irq_save(void)
@@ -154,6 +136,26 @@ static inline notrace unsigned long
arch_local_irq_save(void)
#define INTERRUPT_RETURN iret
#endif
+#else
+
+/*
+ * Used in the idle loop; sti takes one instruction cycle
+ * to complete:
+ */
+static inline __cpuidle void arch_safe_halt(void)
+{
+ native_safe_halt();
+}
+
+/*
+ * Used when interrupts are already enabled or to
+ * shutdown the processor:
+ */
+static inline __cpuidle void halt(void)
+{
+ native_halt();
+}
+
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_PARAVIRT_XXL */
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index bc9a72a767c8..220c13d7e846 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -91,7 +91,6 @@ static inline void write_cr8(unsigned long x)
PVOP_VCALL1(pv_cpu_ops.write_cr8, x);
}
#endif
-#endif
static inline void arch_safe_halt(void)
{
@@ -103,7 +102,6 @@ static inline void halt(void)
PVOP_VCALL0(pv_irq_ops.halt);
}
-#ifdef CONFIG_PARAVIRT_XXL
static inline void wbinvd(void)
{
PVOP_VCALL0(pv_cpu_ops.wbinvd);
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index be356aacc82c..938ac2bece81 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -197,8 +197,10 @@ struct pv_irq_ops {
struct paravirt_callee_save irq_disable;
struct paravirt_callee_save irq_enable;
+#ifdef CONFIG_PARAVIRT_XXL
void (*safe_halt)(void);
void (*halt)(void);
+#endif
} __no_randomize_layout;
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 437be9454cab..19bfb3d2083f 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -379,8 +379,10 @@ struct paravirt_patch_template pv_ops = {
.pv_irq_ops.restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
.pv_irq_ops.irq_disable = __PV_IS_CALLEE_SAVE(native_irq_disable),
.pv_irq_ops.irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
+#ifdef CONFIG_PARAVIRT_XXL
.pv_irq_ops.safe_halt = native_safe_halt,
.pv_irq_ops.halt = native_halt,
+#endif
/* Mmu ops. */
.pv_mmu_ops.read_cr2 = native_read_cr2,
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] x86/hvm/ioreq: MMIO range checking completely ignores direction flag
hvm_select_ioreq_server() is used to route an ioreq to the appropriate
ioreq server. For MMIO this is done by comparing the range of the ioreq
to the ranges registered by the device models of each ioreq server.
Unfortunately the calculation of the range if the ioreq completely ignores
the direction flag and thus may calculate the wrong range for comparison.
Thus the ioreq may either be routed to the wrong server or erroneously
terminated by null_ops.
NOTE: The patch also fixes whitespace in the switch statement to make it
style compliant.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 7c515b3ef7..940a2c9728 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1353,20 +1353,25 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct
domain *d,
switch ( type )
{
-unsigned long end;
+unsigned long start, end;
case XEN_DMOP_IO_RANGE_PORT:
-end = addr + p->size - 1;
-if ( rangeset_contains_range(r, addr, end) )
+start = addr;
+end = start + p->size - 1;
+if ( rangeset_contains_range(r, start, end) )
return s;
break;
+
case XEN_DMOP_IO_RANGE_MEMORY:
-end = addr + (p->size * p->count) - 1;
-if ( rangeset_contains_range(r, addr, end) )
+start = hvm_mmio_first_byte(p);
+end = hvm_mmio_last_byte(p);
+
+if ( rangeset_contains_range(r, start, end) )
return s;
break;
+
case XEN_DMOP_IO_RANGE_PCI:
if ( rangeset_contains_singleton(r, addr >> 32) )
{
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee that. This is something that should almost certainly be fixed,
but in the meantime this patch makes sure that MMIO is truncated at GFN
boundaries and hence the appropriate device model is re-evaluated for each
target GFN.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 8385c62145..d6a81ec4d1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -184,8 +184,23 @@ static int hvmemul_do_io(
hvmtrace_io_assist();
}
-vio->io_req = p;
+/*
+ * Make sure that we truncate rep MMIO at any GFN boundary. This is
+ * necessary to ensure that the correct device model is targetted
+ * or that we correctly handle a rep op spanning MMIO and RAM.
+ */
+if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
+{
+unsigned long off = p.addr & ~PAGE_MASK;
+p.count = min_t(unsigned long,
+p.count,
+p.df ?
+(off + p.size) / p.size :
+(PAGE_SIZE - off) / p.size);
+}
+
+vio->io_req = p;
rc = hvm_io_intercept();
/*
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 125817: trouble: blocked/broken/fail/pass
flight 125817 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/125817/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm broken build-arm64-pvopsbroken Regressions which are regarded as allowable (not blocking): build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125691 build-arm64-xsm 2 hosts-allocate broken REGR. vs. 125691 build-arm64 2 hosts-allocate broken REGR. vs. 125691 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 125691 build-arm64-pvops 3 capture-logs broken blocked in 125691 build-arm64-xsm 3 capture-logs broken blocked in 125691 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125691 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125691 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125691 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125691 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125691 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125691 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125691 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125691 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125691 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail 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 ed5f8d9ca47e69e30221c37ec812f2b38af19d83 baseline version: xen 1f7574763cbb2c85825b8cc4d81f386e767a476f Last test of basis 125691 2018-07-30 21:37:12 Z
Re: [Xen-devel] [PATCH 1/2] x86/hvm/ioreq: MMIO range checking completely ignores direction flag
On 10/08/18 11:37, Paul Durrant wrote: > hvm_select_ioreq_server() is used to route an ioreq to the appropriate > ioreq server. For MMIO this is done by comparing the range of the ioreq > to the ranges registered by the device models of each ioreq server. > Unfortunately the calculation of the range if the ioreq completely ignores > the direction flag and thus may calculate the wrong range for comparison. > Thus the ioreq may either be routed to the wrong server or erroneously > terminated by null_ops. > > NOTE: The patch also fixes whitespace in the switch statement to make it > style compliant. > > Signed-off-by: Paul Durrant Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/spec-ctrl: Yet more fixes for xpti= parsing
>>> On 10.08.18 at 11:49, wrote: > On 10/08/2018 09:08, Jan Beulich wrote: > On 09.08.18 at 18:38, wrote: >>> As it currently stands, 'xpti=dom0' is indistinguishable from the default >>> value, which means it will be overridden by ARCH_CAPABILITIES_RDCL_NO on > fixed >>> hardware. >>> >>> Switch opt_xpti to use -1 as a default like all our other related options, > and >>> clobber it as soon as we have a string to parse. >>> >>> In addition, 'xpti' alone should be interpreted in its positive boolean > form, >>> rather than resulting in a parse error. >> But e.g. "xpti=dom0," should not be. I.e. ... >> >>> @@ -439,6 +438,10 @@ static __init int parse_xpti(const char *s) >>> const char *ss; >>> int val, rc = 0; >>> >>> +/* Inhibit the defaults as an explicit choice has been given. */ >>> +if ( opt_xpti == -1 ) >>> +opt_xpti = 0; >> ... the check for an empty string pointed to by s needs to be put here, >> ahead of the loop. > > There are 3 options: > > 1) What is presented here. > 2) Unroll the start of the loop to be able to reach case 1: > 3) Double up the positive case. > > Given how you review code generally, options 2 and 3 are off the table. Hmm, 2 certainly is, but 3 seems reasonable to me. > If someone typo's the command like, nothing is going to work as they > intended in the first place. Therefore, "xpti=dom0," doing the wrong > thing is not a problem. But "xpti=dom0," meaning "xpti=dom0" is far more expectable than is meaning "xpti=dom0,true". The only viable option besides ignoring the trailing comma would seem to be to consider the entire option invalid in such a case, but ignoring is significantly easier to arrange for. > I don't see why we should go out of our way to cover that specific > corner case, or do you suggest we start putting a spellchecker into the > parsing and start guessing at what the user meant? This would be far > more useful if you want to start second guessing what the user wrote... I don't mean us to second guess anything. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
>>> On 10.08.18 at 12:04, wrote: > On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote: >> >>> On 08.08.18 at 12:07, wrote: >> > So it's done before the iommu is initialized. This is required in >> > order to be able to fetch the MMCFG regions from the domain struct. >> >> Is this a useful change to make? Regions not reported through the MCFG >> table will need punching holes anyway, so why not punch holes uniformly >> in all cases, allowing the hole punching code to be tested even on systems >> without non-boot-time-available regions? > > I can add this hole-punching code to register_vpci_mmcfg_handler so I > can remove this reordering. > > I'm however struggling to find a function that will set a p2m range to > p2m_invalid. All the functions that I find to deal with this assume > that you know the memory type you are trying to remove (for example > clear_identity_p2m_entry) and fail if the current type is different > than expected. > > In this case it's quite likely that the MMCFG region is not mapped to > anything, should I introduce a new helper that sets a p2m range to > p2m_invalid regardless of the current type? Well, if there is none - why not? But really that's more like something to get George to agree to. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/10] x86/paravirt: remove unused paravirt bits
The macros ENABLE_INTERRUPTS_SYSEXIT, GET_CR0_INTO_EAX and
PARAVIRT_ADJUST_EXCEPTION_FRAME are used nowhere. Remove their
definitions.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/irqflags.h | 4
arch/x86/include/asm/paravirt.h | 9 +
arch/x86/kernel/asm-offsets.c | 1 -
3 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index c4fc17220df9..b7a790d03229 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -132,8 +132,6 @@ static inline notrace unsigned long
arch_local_irq_save(void)
*/
#define SWAPGS_UNSAFE_STACKswapgs
-#define PARAVIRT_ADJUST_EXCEPTION_FRAME/* */
-
#define INTERRUPT_RETURN jmp native_iret
#define USERGS_SYSRET64\
swapgs; \
@@ -147,8 +145,6 @@ static inline notrace unsigned long
arch_local_irq_save(void)
#endif
#else
#define INTERRUPT_RETURN iret
-#define ENABLE_INTERRUPTS_SYSEXIT sti; sysexit
-#define GET_CR0_INTO_EAX movl %cr0, %eax
#endif
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 1b86bb319393..436d270e622b 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -904,14 +904,7 @@ extern void default_banner(void);
call PARA_INDIRECT(pv_ops+PV_IRQ_irq_enable); \
PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);)
-#ifdef CONFIG_X86_32
-#define GET_CR0_INTO_EAX \
- push %ecx; push %edx; \
- ANNOTATE_RETPOLINE_SAFE;\
- call PARA_INDIRECT(pv_ops+PV_CPU_read_cr0); \
- pop %edx; pop %ecx
-#else /* !CONFIG_X86_32 */
-
+#ifdef CONFIG_X86_64
/*
* If swapgs is used while the userspace stack is still current,
* there's no way to call a pvop. The PV replacement *must* be
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index bec9fc3498f8..d0f0348209cb 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -71,7 +71,6 @@ void common(void) {
OFFSET(PV_IRQ_irq_enable, paravirt_patch_template,
pv_irq_ops.irq_enable);
OFFSET(PV_CPU_iret, paravirt_patch_template, pv_cpu_ops.iret);
- OFFSET(PV_CPU_read_cr0, paravirt_patch_template, pv_cpu_ops.read_cr0);
OFFSET(PV_MMU_read_cr2, paravirt_patch_template, pv_mmu_ops.read_cr2);
#endif
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 10/10] x86/paravirt: move the Xen-only pv_mmu_ops under the PARAVIRT_XXL umbrella
Most of the paravirt ops defined in pv_mmu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/fixmap.h | 2 +-
arch/x86/include/asm/mmu_context.h| 4 +-
arch/x86/include/asm/paravirt.h | 115 +-
arch/x86/include/asm/paravirt_types.h | 29 -
arch/x86/include/asm/pgalloc.h| 2 +-
arch/x86/include/asm/pgtable.h| 7 +--
arch/x86/include/asm/special_insns.h | 11 +---
arch/x86/kernel/asm-offsets.c | 2 +-
arch/x86/kernel/head_64.S | 4 +-
arch/x86/kernel/paravirt.c| 15 +++--
arch/x86/kernel/paravirt_patch_32.c | 4 +-
arch/x86/kernel/paravirt_patch_64.c | 4 +-
12 files changed, 97 insertions(+), 102 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index e203169931c7..ac80e7eadc3a 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -152,7 +152,7 @@ void __native_set_fixmap(enum fixed_addresses idx, pte_t
pte);
void native_set_fixmap(enum fixed_addresses idx,
phys_addr_t phys, pgprot_t flags);
-#ifndef CONFIG_PARAVIRT
+#ifndef CONFIG_PARAVIRT_XXL
static inline void __set_fixmap(enum fixed_addresses idx,
phys_addr_t phys, pgprot_t flags)
{
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index bbc796eb0a3b..ffae17a8db36 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -16,12 +16,12 @@
extern atomic64_t last_mm_ctx_id;
-#ifndef CONFIG_PARAVIRT
+#ifndef CONFIG_PARAVIRT_XXL
static inline void paravirt_activate_mm(struct mm_struct *prev,
struct mm_struct *next)
{
}
-#endif /* !CONFIG_PARAVIRT */
+#endif /* !CONFIG_PARAVIRT_XXL */
#ifdef CONFIG_PERF_EVENTS
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 220c13d7e846..520c85b74c74 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -17,6 +17,57 @@
#include
#include
+static inline unsigned long long paravirt_sched_clock(void)
+{
+ return PVOP_CALL0(unsigned long long, pv_time_ops.sched_clock);
+}
+
+struct static_key;
+extern struct static_key paravirt_steal_enabled;
+extern struct static_key paravirt_steal_rq_enabled;
+
+static inline u64 paravirt_steal_clock(int cpu)
+{
+ return PVOP_CALL1(u64, pv_time_ops.steal_clock, cpu);
+}
+
+/* The paravirtualized I/O functions */
+static inline void slow_down_io(void)
+{
+ pv_ops.pv_cpu_ops.io_delay();
+#ifdef REALLY_SLOW_IO
+ pv_ops.pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
+ pv_ops.pv_cpu_ops.io_delay();
+#endif
+}
+
+static inline void __flush_tlb(void)
+{
+ PVOP_VCALL0(pv_mmu_ops.flush_tlb_user);
+}
+
+static inline void __flush_tlb_global(void)
+{
+ PVOP_VCALL0(pv_mmu_ops.flush_tlb_kernel);
+}
+
+static inline void __flush_tlb_one_user(unsigned long addr)
+{
+ PVOP_VCALL1(pv_mmu_ops.flush_tlb_one_user, addr);
+}
+
+static inline void flush_tlb_others(const struct cpumask *cpumask,
+ const struct flush_tlb_info *info)
+{
+ PVOP_VCALL2(pv_mmu_ops.flush_tlb_others, cpumask, info);
+}
+
+static inline void paravirt_arch_exit_mmap(struct mm_struct *mm)
+{
+ PVOP_VCALL1(pv_mmu_ops.exit_mmap, mm);
+}
+
#ifdef CONFIG_PARAVIRT_XXL
static inline void load_sp0(unsigned long sp0)
{
@@ -52,7 +103,6 @@ static inline void write_cr0(unsigned long x)
{
PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
}
-#endif
static inline unsigned long read_cr2(void)
{
@@ -74,7 +124,6 @@ static inline void write_cr3(unsigned long x)
PVOP_VCALL1(pv_mmu_ops.write_cr3, x);
}
-#ifdef CONFIG_PARAVIRT_XXL
static inline void __write_cr4(unsigned long x)
{
PVOP_VCALL1(pv_cpu_ops.write_cr4, x);
@@ -172,23 +221,7 @@ static inline int rdmsrl_safe(unsigned msr, unsigned long
long *p)
*p = paravirt_read_msr_safe(msr, );
return err;
}
-#endif
-static inline unsigned long long paravirt_sched_clock(void)
-{
- return PVOP_CALL0(unsigned long long, pv_time_ops.sched_clock);
-}
-
-struct static_key;
-extern struct static_key paravirt_steal_enabled;
-extern struct static_key paravirt_steal_rq_enabled;
-
-static inline u64 paravirt_steal_clock(int cpu)
-{
- return PVOP_CALL1(u64, pv_time_ops.steal_clock, cpu);
-}
-
-#ifdef CONFIG_PARAVIRT_XXL
static inline unsigned long long paravirt_read_pmc(int counter)
{
return PVOP_CALL1(u64, pv_cpu_ops.read_pmc, counter);
@@ -267,18 +300,6 @@ static inline void set_iopl_mask(unsigned mask)
{
PVOP_VCALL1(pv_cpu_ops.set_iopl_mask, mask);
}
-#endif
-
-/* The paravirtualized I/O functions */
-static inline void slow_down_io(void)
-{
- pv_ops.pv_cpu_ops.io_delay();
-#ifdef REALLY_SLOW_IO
-
[Xen-devel] [PATCH 00/10] x86/paravirt: several cleanups
This series removes some no longer needed stuff from paravirt
infrastructure and puts large quantities of paravirt ops under a new
config option PARAVIRT_XXL which is selected by XEN_PV only.
A pvops kernel without XEN_PV being configured is about 2.5% smaller
with this series applied.
tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt:
Fix spectre-v2 mitigations for paravirt guests") is a prerequisite
for this series.
The last 4 patches of this series require my Xen cleanup series
https://lore.kernel.org/lkml/20180717120113.12756-1-jgr...@suse.com/
which hides more Xen PV-only code behind CONFIG_XEN_PV.
Juergen Gross (10):
x86/paravirt: make paravirt_patch_call() and paravirt_patch_jmp()
static
x86/paravirt: remove clobbers parameter from paravirt patch functions
x86/paravirt: remove clobbers from struct paravirt_patch_site
x86/paravirt: use a single ops structure
x86/paravirt: remove unused paravirt bits
x86/paravirt: introduce new config option PARAVIRT_XXL
x86/paravirt: move items in pv_info under PARAVIRT_XXL umbrella
x86/paravirt: move the Xen-only pv_cpu_ops under the PARAVIRT_XXL
umbrella
x86/paravirt: move the Xen-only pv_irq_ops under the PARAVIRT_XXL
umbrella
x86/paravirt: move the Xen-only pv_mmu_ops under the PARAVIRT_XXL
umbrella
arch/x86/Kconfig| 3 +
arch/x86/hyperv/mmu.c | 4 +-
arch/x86/include/asm/debugreg.h | 2 +-
arch/x86/include/asm/desc.h | 4 +-
arch/x86/include/asm/fixmap.h | 2 +-
arch/x86/include/asm/irqflags.h | 56 +++---
arch/x86/include/asm/mmu_context.h | 4 +-
arch/x86/include/asm/msr.h | 4 +-
arch/x86/include/asm/paravirt.h | 183 +-
arch/x86/include/asm/paravirt_types.h | 65 +++
arch/x86/include/asm/pgalloc.h | 2 +-
arch/x86/include/asm/pgtable-3level_types.h | 2 +-
arch/x86/include/asm/pgtable.h | 7 +-
arch/x86/include/asm/processor.h| 4 +-
arch/x86/include/asm/ptrace.h | 3 +-
arch/x86/include/asm/segment.h | 2 +-
arch/x86/include/asm/special_insns.h| 4 +-
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/asm-offsets.c | 15 +-
arch/x86/kernel/asm-offsets_64.c| 9 +-
arch/x86/kernel/cpu/common.c| 4 +-
arch/x86/kernel/cpu/vmware.c| 4 +-
arch/x86/kernel/head_64.S | 2 +-
arch/x86/kernel/kvm.c | 18 +-
arch/x86/kernel/kvmclock.c | 4 +-
arch/x86/kernel/paravirt-spinlocks.c| 15 +-
arch/x86/kernel/paravirt.c | 290 ++--
arch/x86/kernel/paravirt_patch_32.c | 9 +-
arch/x86/kernel/paravirt_patch_64.c | 11 +-
arch/x86/kernel/tsc.c | 2 +-
arch/x86/kernel/vsmp_64.c | 17 +-
arch/x86/xen/Kconfig| 1 +
arch/x86/xen/enlighten_pv.c | 32 +--
arch/x86/xen/irq.c | 2 +-
arch/x86/xen/mmu_hvm.c | 2 +-
arch/x86/xen/mmu_pv.c | 28 +--
arch/x86/xen/spinlock.c | 12 +-
arch/x86/xen/time.c | 4 +-
drivers/xen/time.c | 2 +-
39 files changed, 430 insertions(+), 406 deletions(-)
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 08/10] x86/paravirt: move the Xen-only pv_cpu_ops under the PARAVIRT_XXL umbrella
Most of the paravirt ops defined in pv_cpu_ops are for Xen PV guests
only. Define them only if CONFIG_PARAVIRT_XXL is set.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/debugreg.h | 2 +-
arch/x86/include/asm/desc.h | 4 ++--
arch/x86/include/asm/irqflags.h | 16 +++-
arch/x86/include/asm/msr.h| 4 ++--
arch/x86/include/asm/paravirt.h | 15 +--
arch/x86/include/asm/paravirt_types.h | 5 -
arch/x86/include/asm/pgtable.h| 6 --
arch/x86/include/asm/processor.h | 4 ++--
arch/x86/include/asm/special_insns.h | 9 +++--
arch/x86/kernel/asm-offsets.c | 2 ++
arch/x86/kernel/asm-offsets_64.c | 2 ++
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/head_64.S | 2 ++
arch/x86/kernel/paravirt.c| 13 -
arch/x86/kernel/paravirt_patch_32.c | 4
arch/x86/kernel/paravirt_patch_64.c | 6 +-
16 files changed, 74 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
index 4505ac2735ad..9e5ca30738e5 100644
--- a/arch/x86/include/asm/debugreg.h
+++ b/arch/x86/include/asm/debugreg.h
@@ -8,7 +8,7 @@
DECLARE_PER_CPU(unsigned long, cpu_dr7);
-#ifndef CONFIG_PARAVIRT
+#ifndef CONFIG_PARAVIRT_XXL
/*
* These special macros can be used to get or set a debugging register
*/
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 13c5ee878a47..68a99d2a5f33 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -108,7 +108,7 @@ static inline int desc_empty(const void *ptr)
return !(desc[0] | desc[1]);
}
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
#include
#else
#define load_TR_desc() native_load_tr_desc()
@@ -134,7 +134,7 @@ static inline void paravirt_alloc_ldt(struct desc_struct
*ldt, unsigned entries)
static inline void paravirt_free_ldt(struct desc_struct *ldt, unsigned entries)
{
}
-#endif /* CONFIG_PARAVIRT */
+#endif /* CONFIG_PARAVIRT_XXL */
#define store_ldt(ldt) asm("sldt %0" : "=m"(ldt))
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index b7a790d03229..03bb451e4e6b 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -120,6 +120,16 @@ static inline notrace unsigned long
arch_local_irq_save(void)
#define DISABLE_INTERRUPTS(x) cli
#ifdef CONFIG_X86_64
+#ifdef CONFIG_DEBUG_ENTRY
+#define SAVE_FLAGS(x) pushfq; popq %rax
+#endif
+#endif
+#endif /* __ASSEMBLY__ */
+#endif /* CONFIG_PARAVIRT */
+
+#ifndef CONFIG_PARAVIRT_XXL
+#ifdef __ASSEMBLY__
+#ifdef CONFIG_X86_64
#define SWAPGS swapgs
/*
* Currently paravirt can't handle swapgs nicely when we
@@ -140,16 +150,12 @@ static inline notrace unsigned long
arch_local_irq_save(void)
swapgs; \
sysretl
-#ifdef CONFIG_DEBUG_ENTRY
-#define SAVE_FLAGS(x) pushfq; popq %rax
-#endif
#else
#define INTERRUPT_RETURN iret
#endif
-
#endif /* __ASSEMBLY__ */
-#endif /* CONFIG_PARAVIRT */
+#endif /* CONFIG_PARAVIRT_XXL */
#ifndef __ASSEMBLY__
static inline int arch_irqs_disabled_flags(unsigned long flags)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 04addd6e0a4a..91e4cf189914 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -242,7 +242,7 @@ static inline unsigned long long native_read_pmc(int
counter)
return EAX_EDX_VAL(val, low, high);
}
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
#include
#else
#include
@@ -305,7 +305,7 @@ do {
\
#define rdpmcl(counter, val) ((val) = native_read_pmc(counter))
-#endif /* !CONFIG_PARAVIRT */
+#endif /* !CONFIG_PARAVIRT_XXL */
/*
* 64-bit version of wrmsr_safe():
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index afc0469979f7..bc9a72a767c8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -17,6 +17,7 @@
#include
#include
+#ifdef CONFIG_PARAVIRT_XXL
static inline void load_sp0(unsigned long sp0)
{
PVOP_VCALL1(pv_cpu_ops.load_sp0, sp0);
@@ -51,6 +52,7 @@ static inline void write_cr0(unsigned long x)
{
PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
}
+#endif
static inline unsigned long read_cr2(void)
{
@@ -72,6 +74,7 @@ static inline void write_cr3(unsigned long x)
PVOP_VCALL1(pv_mmu_ops.write_cr3, x);
}
+#ifdef CONFIG_PARAVIRT_XXL
static inline void __write_cr4(unsigned long x)
{
PVOP_VCALL1(pv_cpu_ops.write_cr4, x);
@@ -88,6 +91,7 @@ static inline void write_cr8(unsigned long x)
PVOP_VCALL1(pv_cpu_ops.write_cr8, x);
}
#endif
+#endif
static inline void arch_safe_halt(void)
{
@@ -99,14 +103,13 @@ static inline void halt(void)
PVOP_VCALL0(pv_irq_ops.halt);
}
+#ifdef
[Xen-devel] [PATCH 03/10] x86/paravirt: remove clobbers from struct paravirt_patch_site
There is no need any longer to store the clobbers in struct paravirt_patch_site. Remove clobbers from the struct and from the related macros. While at it fix some lines longer than 80 characters. Signed-off-by: Juergen Gross --- arch/x86/include/asm/paravirt.h | 33 +++-- arch/x86/include/asm/paravirt_types.h | 1 - 2 files changed, 15 insertions(+), 19 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index d49bbf4bb5c8..76b4b5c056f3 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -822,7 +822,7 @@ extern void default_banner(void); #else /* __ASSEMBLY__ */ -#define _PVSITE(ptype, clobbers, ops, word, algn) \ +#define _PVSITE(ptype, ops, word, algn)\ 771:; \ ops;\ 772:; \ @@ -831,7 +831,6 @@ extern void default_banner(void); word 771b; \ .byte ptype; \ .byte 772b-771b; \ -.short clobbers; \ .popsection @@ -864,7 +863,7 @@ extern void default_banner(void); COND_POP(set, CLBR_RAX, rax) #define PARA_PATCH(struct, off)((PARAVIRT_PATCH_##struct + (off)) / 8) -#define PARA_SITE(ptype, clobbers, ops) _PVSITE(ptype, clobbers, ops, .quad, 8) +#define PARA_SITE(ptype, ops) _PVSITE(ptype, ops, .quad, 8) #define PARA_INDIRECT(addr)*addr(%rip) #else #define PV_SAVE_REGS(set) \ @@ -879,26 +878,26 @@ extern void default_banner(void); COND_POP(set, CLBR_EAX, eax) #define PARA_PATCH(struct, off)((PARAVIRT_PATCH_##struct + (off)) / 4) -#define PARA_SITE(ptype, clobbers, ops) _PVSITE(ptype, clobbers, ops, .long, 4) +#define PARA_SITE(ptype, ops) _PVSITE(ptype, ops, .long, 4) #define PARA_INDIRECT(addr)*%cs:addr #endif #define INTERRUPT_RETURN \ - PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_iret), CLBR_NONE, \ - ANNOTATE_RETPOLINE_SAFE; \ + PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_iret), \ + ANNOTATE_RETPOLINE_SAFE; \ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_iret);) #define DISABLE_INTERRUPTS(clobbers) \ - PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_disable), clobbers, \ + PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_disable), \ PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\ - ANNOTATE_RETPOLINE_SAFE; \ + ANNOTATE_RETPOLINE_SAFE; \ call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_disable);\ PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);) #define ENABLE_INTERRUPTS(clobbers)\ - PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_enable), clobbers, \ + PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_enable),\ PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\ - ANNOTATE_RETPOLINE_SAFE; \ + ANNOTATE_RETPOLINE_SAFE; \ call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_enable); \ PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);) @@ -916,8 +915,7 @@ extern void default_banner(void); * inlined, or the swapgs instruction must be trapped and emulated. */ #define SWAPGS_UNSAFE_STACK\ - PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \ - swapgs) + PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), swapgs) /* * Note: swapgs is very special, and in practise is either going to be @@ -926,8 +924,8 @@ extern void default_banner(void); * it. */ #define SWAPGS \ - PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \ - ANNOTATE_RETPOLINE_SAFE; \ + PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs),\ + ANNOTATE_RETPOLINE_SAFE; \ call PARA_INDIRECT(pv_cpu_ops+PV_CPU_swapgs); \ ) @@ -937,15 +935,14 @@ extern void default_banner(void); #define USERGS_SYSRET64 \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64), \ - CLBR_NONE,\ - ANNOTATE_RETPOLINE_SAFE;
[Xen-devel] [PATCH 07/10] x86/paravirt: move items in pv_info under PARAVIRT_XXL umbrella
All items but name in pv_info are needed by Xen PV only. Define them
with CONFIG_PARAVIRT_XXL set only.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 2 ++
arch/x86/include/asm/paravirt_types.h | 2 ++
arch/x86/include/asm/pgtable-3level_types.h | 2 +-
arch/x86/include/asm/ptrace.h | 3 ++-
arch/x86/include/asm/segment.h | 2 +-
arch/x86/kernel/paravirt.c | 2 ++
6 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 436d270e622b..afc0469979f7 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -104,7 +104,9 @@ static inline void wbinvd(void)
PVOP_VCALL0(pv_cpu_ops.wbinvd);
}
+#ifdef CONFIG_PARAVIRT_XXL
#define get_kernel_rpl() (pv_info.kernel_rpl)
+#endif
static inline u64 paravirt_read_msr(unsigned msr)
{
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index ed024e90b863..f1bdc4c9ff4c 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -65,12 +65,14 @@ struct paravirt_callee_save {
/* general info */
struct pv_info {
+#ifdef CONFIG_PARAVIRT_XXL
unsigned int kernel_rpl;
int shared_kernel_pmd;
#ifdef CONFIG_X86_64
u16 extra_user_64bit_cs; /* __USER_CS if none */
#endif
+#endif
const char *name;
};
diff --git a/arch/x86/include/asm/pgtable-3level_types.h
b/arch/x86/include/asm/pgtable-3level_types.h
index 6a59a6d0cc50..1aa68ca1907c 100644
--- a/arch/x86/include/asm/pgtable-3level_types.h
+++ b/arch/x86/include/asm/pgtable-3level_types.h
@@ -20,7 +20,7 @@ typedef union {
} pte_t;
#endif /* !__ASSEMBLY__ */
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
#define SHARED_KERNEL_PMD (pv_info.shared_kernel_pmd)
#else
#define SHARED_KERNEL_PMD 1
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 6de1fd3d0097..c9ac6ff5f7d2 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -144,7 +144,8 @@ static inline int v8086_mode(struct pt_regs *regs)
static inline bool user_64bit_mode(struct pt_regs *regs)
{
#ifdef CONFIG_X86_64
-#ifndef CONFIG_PARAVIRT
+/* Early boot code has CONFIG_PARAVIRT undefined! */
+#if !defined(CONFIG_PARAVIRT) || !defined(CONFIG_PARAVIRT_XXL)
/*
* On non-paravirt systems, this is the only long mode CPL 3
* selector. We do not allow long mode selectors in the LDT.
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index e293c122d0d5..0ffbe9519e68 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -211,7 +211,7 @@
#endif
-#ifndef CONFIG_PARAVIRT
+#ifndef CONFIG_PARAVIRT_XXL
# define get_kernel_rpl() 0
#endif
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 40ec68135f7a..168901f4dc09 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -292,12 +292,14 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
struct pv_info pv_info = {
.name = "bare hardware",
+#ifdef CONFIG_PARAVIRT_XXL
.kernel_rpl = 0,
.shared_kernel_pmd = 1, /* Only used when CONFIG_X86_PAE is set */
#ifdef CONFIG_X86_64
.extra_user_64bit_cs = __USER_CS,
#endif
+#endif
};
#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_PAE)
--
2.13.7
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/10] x86/paravirt: introduce new config option PARAVIRT_XXL
A large amount of paravirt ops is used by Xen PV guests only. Add a new config option PARAVIRT_XXL which is selected by XEN_PV. Later we can put the Xen PV only paravirt ops under the PARACVIRT_XXL umbrella. Signed-off-by: Juergen Gross --- arch/x86/Kconfig | 3 +++ arch/x86/xen/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 887d3a7bb646..3c967b803c21 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -754,6 +754,9 @@ config PARAVIRT over full virtualization. However, when run without a hypervisor the kernel is theoretically slower and slightly larger. +config PARAVIRT_XXL + bool + config PARAVIRT_DEBUG bool "paravirt-ops debugging" depends on PARAVIRT && DEBUG_KERNEL diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index c1f98f32c45f..dd92d7bd3613 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -18,6 +18,7 @@ config XEN_PV bool "Xen PV guest support" default y depends on XEN + select PARAVIRT_XXL select XEN_HAVE_PVMMU select XEN_HAVE_VPMU help -- 2.13.7 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
>>> On 10.08.18 at 12:37, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> hvmtrace_io_assist();
> }
>
> -vio->io_req = p;
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> + * necessary to ensure that the correct device model is targetted
> + * or that we correctly handle a rep op spanning MMIO and RAM.
> + */
> +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> +{
> +unsigned long off = p.addr & ~PAGE_MASK;
>
> +p.count = min_t(unsigned long,
> +p.count,
> +p.df ?
> +(off + p.size) / p.size :
> +(PAGE_SIZE - off) / p.size);
For misaligned requests you need to make sure p.count doesn't end
up as zero (which can now happen in the forwards case). Or do you
rely on callers (hvmemul_do_io_addr() in particular) splitting such
requests already? Yet in that case it's not clear to me whether
anything needs changing here in the first place. (Similarly in the
backwards case I think the first iteration risks crossing a page
boundary, and then the batch should be clipped to count 1.)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 125821: regressions - trouble: blocked/broken/fail/pass
flight 125821 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125821/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm broken build-arm64 broken build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken REGR. vs. 123814 build-arm64 2 hosts-allocate broken REGR. vs. 123814 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64 3 capture-logs broken blocked in 123814 build-arm64-xsm 3 capture-logs broken blocked in 123814 build-arm64-pvops 3 capture-logs broken blocked in 123814 version targeted for testing: libvirt b3d9b08ef797e569b14cfa42d3dceba23c2a5b14 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 66 days Failing since123840 2018-06-06 04:19:28 Z 65 days 50 attempts Testing same since 125821 2018-08-09 04:18:46 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-arm64-xsm broken build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt blocked build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked
