Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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