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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel