Re: [PATCH 0/2] MMIO emulation fixes

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 10/08/18 13:43, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 10 August 2018 13:37
>> To: Paul Durrant <Paul.Durrant@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.Durrant@citrix.com> wrote:
>>>>  -----Original Message-----
>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>> Sent: 10 August 2018 13:13
>>>> To: Paul Durrant <Paul.Durrant@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.Durrant@citrix.com> wrote:
>>>>>>  -----Original Message-----
>>>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>>>> Sent: 10 August 2018 13:02
>>>>>> To: Paul Durrant <Paul.Durrant@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.durrant@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.

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