> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 August 2018 08:34
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH v2 2/2] x86/hvm/emulate: make sure rep I/O emulation
> does not cross GFN boundaries
>
> >
>>> On 10.08.18 at 16:48, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,6 +184,25 @@ static int hvmemul_do_io(
> hvmtrace_io_assist(&p);
> }
>
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> + * nec
On 15/08/18 13:41, Jan Beulich wrote:
On 10.08.18 at 16:48, 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
>>> On 10.08.18 at 16:48, 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 leve
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
