> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2018 12:59
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> >>>
>>> On 10.08.18 at 12:37, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,8 +184,23 @@ static int hvmemul_do_io(
> hvmtrace_io_assist(&p);
> }
>
> -vio->io_req = p;
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundar
On 10/08/18 12:50, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 10 August 2018 12:14
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich
>> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
>> does not cross GFN boundarie
> -Original Message-
> From: Andrew Cooper
> Sent: 10 August 2018 12:14
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich
> Subject: Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> On 10/08/18 11:37, Paul Durrant wrote:
On 10/08/18 11:37, Paul Durrant wrote:
> When emulating a rep I/O operation it is possible that the ioreq will
> describe a single operation that spans multiple GFNs. This is fine as long
> as all those GFNs fall within an MMIO region covered by a single device
> model, but unfortunately the higher
When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee
