Re: [PATCH 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries

["Jan Beulich" <JBeulich@suse.com>]

>>> On 10.08.18 at 12:37, <paul.durrant@citrix.com> 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 boundary. This is
> +     * necessary to ensure that the correct device model is targetted
> +     * or that we correctly handle a rep op spanning MMIO and RAM.
> +     */
> +    if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> +    {
> +        unsigned long off = p.addr & ~PAGE_MASK;
>  
> +        p.count = min_t(unsigned long,
> +                        p.count,
> +                        p.df ?
> +                        (off + p.size) / p.size :
> +                        (PAGE_SIZE - off) / p.size);

For misaligned requests you need to make sure p.count doesn't end
up as zero (which can now happen in the forwards case). Or do you
rely on callers (hvmemul_do_io_addr() in particular) splitting such
requests already? Yet in that case it's not clear to me whether
anything needs changing here in the first place. (Similarly in the
backwards case I think the first iteration risks crossing a page
boundary, and then the batch should be clipped to count 1.)

Jan



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