> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 10 August 2018 13:37 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: xen-devel <xen-devel@lists.xenproject.org> > Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > > >>> On 10.08.18 at 14:22, <paul.durr...@citrix.com> wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 10 August 2018 13:13 > >> To: Paul Durrant <paul.durr...@citrix.com> > >> Cc: xen-devel <xen-devel@lists.xenproject.org> > >> Subject: RE: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> > >> >>> On 10.08.18 at 14:08, <paul.durr...@citrix.com> wrote: > >> >> -----Original Message----- > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 10 August 2018 13:02 > >> >> To: Paul Durrant <paul.durr...@citrix.com> > >> >> Cc: xen-devel <xen-devel@lists.xenproject.org> > >> >> Subject: Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes > >> >> > >> >> >>> On 10.08.18 at 12:37, <paul.durr...@citrix.com> 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
