From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH v4 07/17] x86/hvm: add length to mmio check op Date: Thu, 25 Jun 2015 14:57:58 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02597146F@AMSPEX01CL02.citrite.net> References: <1435145089-21999-1-git-send-email-paul.durrant@citrix.com> <1435145089-21999-8-git-send-email-paul.durrant@citrix.com> <558BF247.9000208@citrix.com> <558C14370200007800089A1F@mail.emea.novell.com> <558C0349.6030808@citrix.com> <9AAE0902D5BC7E449B7C8E4E778ABCD025971274@AMSPEX01CL02.citrite.net> <558C22970200007800089B12@mail.emea.novell.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02597131E@AMSPEX01CL02.citrite.net> <558C30500200007800089BAE@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z88bJ-0002ub-PM for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 14:58:01 +0000 In-Reply-To: <558C30500200007800089BAE@mail.emea.novell.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , "Keir (Xen.org)" , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: 25 June 2015 15:46 > To: Paul Durrant > Cc: Andrew Cooper; xen-devel@lists.xenproject.org; Keir (Xen.org) > Subject: RE: [PATCH v4 07/17] x86/hvm: add length to mmio check op > > >>> On 25.06.15 at 15:52, wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: 25 June 2015 14:48 > >> To: Paul Durrant > >> Cc: Andrew Cooper; xen-devel@lists.xenproject.org; Keir (Xen.org) > >> Subject: RE: [PATCH v4 07/17] x86/hvm: add length to mmio check op > >> > >> >>> On 25.06.15 at 15:36, 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