From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RygvA-0001S1-HM for qemu-devel@nongnu.org; Sat, 18 Feb 2012 04:49:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rygv9-0002Hv-KP for qemu-devel@nongnu.org; Sat, 18 Feb 2012 04:49:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rygv9-0002HI-Ci for qemu-devel@nongnu.org; Sat, 18 Feb 2012 04:49:35 -0500 Message-ID: <4F3F7427.6020705@redhat.com> Date: Sat, 18 Feb 2012 11:49:27 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F2AB552.2070909@redhat.com> <4F2B41D6.8020603@codemonkey.ws> <51470503-DEE0-478D-8D01-020834AF6E8C@suse.de> <4F3117E5.6000105@redhat.com> <4F31241C.70404@redhat.com> <4F313354.4080401@redhat.com> <4B03190C-1B6B-48EC-92C7-C27F6982018A@suse.de> <4F3B9497.4020700@redhat.com> <4F3BB33C.1000908@redhat.com> <1FE08D00-49E8-4371-9F23-C5D2EE568FA8@suse.de> <4F3BB9DC.6040102@redhat.com> <3DC824A5-5D5A-4BCC-A0FB-1B459B7E362D@suse.de> <4F3D57E3.7020503@redhat.com> <810F6879-64A9-4FCF-9C22-00BCC945D6B0@suse.de> <4F3D5B35.4000606@redhat.com> <4F3D6A0E.4080705@freescale.com> In-Reply-To: <4F3D6A0E.4080705@freescale.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Next gen kvm api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Alexander Graf , KVM list , qemu-devel , kvm-ppc , linux-kernel On 02/16/2012 10:41 PM, Scott Wood wrote: > >>> Sharing the data structures is not need. Simply synchronize them before > >>> lookup, like we do for ordinary registers. > >> > >> Ordinary registers are a few bytes. We're talking of dozens of kbytes here. > > > > A TLB way is a few dozen bytes, no? > > I think you mean a TLB set... Yes, thanks. > but the TLB (or part of it) may be fully > associative. A fully associative TLB has to be very small. > On e500mc, it's 24 bytes for one TLB entry, and you'd need 4 entries for > a set of TLB0, and all 64 entries in TLB1. So 1632 bytes total. Syncing this every time you need a translation (for gdb or the monitor) is trivial in terms of performance. > Then we'd need to deal with tracking whether we synchronized one or more > specific sets, or everything (for migration or debug TLB dump). The > request to synchronize would have to come from within the QEMU MMU code, > since that's the point where we know what to ask for (unless we > duplicate the logic elsewhere). I'm not sure that reusing the standard > QEMU MMU code for individual debug address translation is really > simplifying things... > > And yes, we do have fancier hardware coming fairly soon for which this > breaks (TLB0 entries can be loaded without host involvement, as long as > there's a translation from guest physical to physical in a separate > hardware table). It'd be reasonable to ignore TLB0 for migration (treat > it as invalidated), but not for debug since that may be where the > translation we're interested in resides. > So with this new hardware, the always-sync API breaks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.