[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.