From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v4 17/17] x86/hvm: track large memory mapped accesses by buffer offset Date: Thu, 25 Jun 2015 12:05:51 +0100 Message-ID: <558BFCAF0200007800089840@mail.emea.novell.com> References: <1435145089-21999-1-git-send-email-paul.durrant@citrix.com> <1435145089-21999-18-git-send-email-paul.durrant@citrix.com> <558BF83A02000078000897E7@mail.emea.novell.com> <9AAE0902D5BC7E449B7C8E4E778ABCD025970C99@AMSPEX01CL02.citrite.net> 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 1Z84yi-0007lM-7X for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 11:05:56 +0000 In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025970C99@AMSPEX01CL02.citrite.net> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: Andrew Cooper , "Keir(Xen.org)" , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org >>> On 25.06.15 at 12:51, wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: 25 June 2015 11:47 >> To: Paul Durrant >> Cc: Andrew Cooper; xen-devel@lists.xenproject.org; Keir (Xen.org) >> Subject: Re: [PATCH v4 17/17] x86/hvm: track large memory mapped >> accesses by buffer offset >> >> >>> On 24.06.15 at 13:24, wrote: >> > @@ -621,14 +574,41 @@ static int hvmemul_phys_mmio_access( >> > >> > for ( ;; ) >> > { >> > - rc = hvmemul_do_mmio_buffer(gpa, &one_rep, chunk, dir, 0, >> > - *buffer); >> > - if ( rc != X86EMUL_OKAY ) >> > - break; >> > + /* Have we already done this chunk? */ >> > + if ( (*off + chunk) <= vio->mmio_cache[dir].size ) >> >> I can see why you would like to get rid of the address check, but >> I'm afraid you can't: You have to avoid getting mixed up multiple >> same kind (reads or writes) memory accesses that a single >> instruction can do. While generally I would assume that >> secondary accesses (like the I/O bitmap read associated with an >> OUTS) wouldn't go to MMIO, CMPS with both operands being >> in MMIO would break even if neither crosses a page boundary >> (not to think of when the emulator starts supporting the >> scatter/gather instructions, albeit supporting them will require >> further changes, or we could choose to do them one element at >> a time). > > Ok. Can I assume at most two distinct set of addresses for read or write? If > so then I can just keep two sets of caches in the hvm_io struct. If we can leave out implicit accesses (like the one mentioned) as well as stack ones, then there shouldn't be more than two (disjoint) reads and one write per instruction, but each possibly crossing a page boundary. If we want to support stacks in MMIO, enter and leave would extend that set, as would said implicit accesses. Of course we should take into consideration what currently works, and I think both stack and implicit accesses would currently work as long as they're aligned (as misalignment would be the only reason for them to get split up - they're never wider than a long). I.e. you may want to consider avoiding any ASSERT()s or other conditionals potentially breaking these special cases. Jan