From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPnAI-0008O8-81 for qemu-devel@nongnu.org; Wed, 21 Jan 2009 19:11:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPnAH-0008NP-Md for qemu-devel@nongnu.org; Wed, 21 Jan 2009 19:11:21 -0500 Received: from [199.232.76.173] (port=43928 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPnAH-0008N7-Gk for qemu-devel@nongnu.org; Wed, 21 Jan 2009 19:11:21 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51062) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPnAH-0002v4-58 for qemu-devel@nongnu.org; Wed, 21 Jan 2009 19:11:21 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPnAG-0003WY-Ab for qemu-devel@nongnu.org; Wed, 21 Jan 2009 19:11:20 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 Date: Thu, 22 Jan 2009 00:11:17 +0000 References: <1232477465-32386-1-git-send-email-glommer@redhat.com> <20090121114626.GA628@poweredge.glommer> <18807.22653.889113.401463@mariner.uk.xensource.com> In-Reply-To: <18807.22653.889113.401463@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901220011.18142.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com, Ian Jackson On Wednesday 21 January 2009, Ian Jackson wrote: > Glauber Costa writes ("Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009"): > > On Wed, Jan 21, 2009 at 05:43:06AM +0000, Paul Brook wrote: > > > I dislike that you're introducing two different ways or doing the > > > same thing. Duplicating all the memory region tracking code seems > > > like a bad way to solve this problem. > > > > That's because I think I'm introducing two different ways of doing > > two different things that just happens to fall under the same name > > of "memory tracking". > > For what it's worth I can definitely see where Glauber is coming from. > The Xen tree also has a replacement implementations of things like > cpu_register_io_memory, for very similar reasons. > > > In all my laziness I agree that we should not be duplicating > > things. Hence why, for example, I tried to commonize the I/O > > functions: which are the same. (and I see no benefit in changing the > > way KVM keeps track of I/O regions in the near future) > > I think the KVM and Xen approaches are probably similar enough that we > can share this code. I'll have to look at it in detail at some point, > which I don't have time to do right now or necessarily even soon. I don't see a reason why these need to be different. They're all doing basically the same thing. The low level implementation details ara a bit different, but in principle kvm, xen and tcg all need to to exactly the same thing: Figure out what a particular physical address is mapped to. As discussed previously, l1_phys_map is not a good solution, and needs to go away. Anypatch that involves independent code paths for kvm and tcg because "the tcg code doesn't work for kvm" sounds a lot like lazyness. The real solution is to fix the current implementation rather than adding a new one. Paul