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

Re: [Xen-devel] [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.

Jan


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


 


Rackspace

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