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 13:52:35 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD02597131E@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z87a2-000521-Ms for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 13:52:38 +0000 In-Reply-To: <558C22970200007800089B12@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 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. Paul > Jan