Re: [Xen-devel] [PATCH v4 07/17] x86/hvm: add length to mmio check op

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 25 June 2015 15:46
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
> Subject: RE: [PATCH v4 07/17] x86/hvm: add length to mmio check op
> 
> >>> On 25.06.15 at 15:52, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 25 June 2015 14:48
> >> To: Paul Durrant
> >> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
> >> Subject: RE: [PATCH v4 07/17] x86/hvm: add length to mmio check op
> >>
> >> >>> On 25.06.15 at 15:36, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> > I think that also allows me to simplfy the patch since I don't have to
> >> > modify the mmio_check op any more. I simply call it once for the first
> byte
> >> > of the access and, if it accepts, verify that it also accepts the last 
> >> > byte
> >> > of the access.
> >>
> >> That's actually not (generally) okay: There could be a hole in the
> >> middle. But as long as instructions don't do accesses wider than
> >> a page, we're fine with that in practice I think. Or wait, no, in the
> >> MSI-X this could not be okay: A 64-byte read to the 16 bytes
> >> 32 bytes away from a page boundary (and being the last entry
> >> on one device's MSI-X table) would extend into another device's
> >> MSI-X table on the next page. I.e. first and last bytes would be
> >> okay to be accessed, but bytes 16...31 of the access wouldn't.
> >> Of course the MSI-X read/write handlers don't currently permit
> >> such wide accesses, but anyway...
> >
> > We could also verify that, for a rep op, all reads/writes come back with
> > OKAY. I think that would be ok.
> 
> I wasn't thinking of a rep op, but of an AVX-512 memory access.
> 

That's ok because it would be chunked at the higher level and accept() would be 
called for each (up to) 8 byte chunk.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel