From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45443 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnbkI-0000kn-Rs for qemu-devel@nongnu.org; Thu, 10 Feb 2011 14:00:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pnbc8-0007kg-HN for qemu-devel@nongnu.org; Thu, 10 Feb 2011 13:51:37 -0500 Received: from am1ehsobe001.messaging.microsoft.com ([213.199.154.204]:29550 helo=AM1EHSOBE001.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pnbc8-0007kU-5K for qemu-devel@nongnu.org; Thu, 10 Feb 2011 13:51:36 -0500 Date: Thu, 10 Feb 2011 12:51:12 -0600 From: Scott Wood Message-ID: <20110210125112.6d1f0380@udp111988uds> In-Reply-To: <4D53CFE2.6080008@suse.de> References: <9F6FE96B71CF29479FF1CDC8046E15030BCD40@039-SN1MPN1-002.039d.mgd.msft.net> <20110202160821.5a223366@udp111988uds> <20110204163338.54690220@udp111988uds> <30BEE027-929B-43E5-A638-A58389F90B6F@suse.de> <20110207141547.58e49caa@udp111988uds> <220F22AA-31E5-4ACB-B0D5-557010096B91@suse.de> <20110209170928.6c629514@udp111988uds> <4D53CFE2.6080008@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Yoder Stuart-B08248 , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , "qemu-devel@nongnu.org" On Thu, 10 Feb 2011 12:45:38 +0100 Alexander Graf wrote: > Ok, thinking about this a bit more. You're basically proposing a list of > tlb set calls, with each array field identifying one tlb set call. What > I was thinking of was a full TLB sync, so we could keep qemu's internal > TLB representation identical to the ioctl layout and then just call that > one ioctl to completely overwrite all of qemu's internal data (and vice > versa). No, this is a full sync -- the list replaces any existing TLB entries (need to make that explicit in the doc). Basically it's an invalidate plus a list of tlb set operations. Qemu's internal representation will want to be ordered with no missing entries. If we require that of the transfer representation we can't do early termination. It would also limit Qemu's flexibility in choosing its internal representation, and make it more awkward to support multiple MMU types. Let's see if the format conversion imposes significant overhead before imposing a less flexible/larger transfer format. :-) > > MMU type ID also controls this, but could add some padding to make > > extensions simpler (esp. since we're not making an array of it). How much > > would you recommend? > > > > How about making it 64 bytes? That should leave us plenty of room. OK. > > The fields inside the struct should be __u32, of course. :-P > > > > Ugh, yes :). But since we're dopping this anyways, it doesn't matter, > right? :) Right. > > I assumed most MMU types would have some straightforward way of marking an > > entry invalid (if not, it can add a software field in the struct), and that > > it would be MMU-specific code that is processing the list. > > > > See above :). Which part? -Scott