From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPbWV-0000Bt-Qx for qemu-devel@nongnu.org; Wed, 21 Jan 2009 06:45:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPbWU-0000Be-AB for qemu-devel@nongnu.org; Wed, 21 Jan 2009 06:45:30 -0500 Received: from [199.232.76.173] (port=51657 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPbWU-0000Bb-4f for qemu-devel@nongnu.org; Wed, 21 Jan 2009 06:45:30 -0500 Received: from mx2.redhat.com ([66.187.237.31]:34248) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPbWT-00071F-NH for qemu-devel@nongnu.org; Wed, 21 Jan 2009 06:45:29 -0500 Date: Wed, 21 Jan 2009 09:46:26 -0200 From: Glauber Costa Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 Message-ID: <20090121114626.GA628@poweredge.glommer> References: <1232477465-32386-1-git-send-email-glommer@redhat.com> <200901210543.07538.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901210543.07538.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: Paul Brook Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Wed, Jan 21, 2009 at 05:43:06AM +0000, Paul Brook wrote: > On Tuesday 20 January 2009, Glauber Costa wrote: > > This series is not very different from the last one that did it. > > Just bringing it back from my vacations. Idea is to replace tcg > > memory functions with kvm's, selectable at runtime. Right now > > we use a conditional selection. In the future, we might use > > function pointers to allow for easy coupling of any hypervisor. > > 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". tcg has a lot of stuff that hypervisors won't need, such as keeping track of a tlb, invalidating memory for the code generator, etc. It is all heavily coupled, and attempts to make it less like it, just led to a bigger number of hooks, most of them which were empty hooks. (you might remember the old QEMUAccel approach we took). Before this patchset, memory registration for KVM is: * kvm_set_phys_mem * tcg stuff. After this patchset, it is: * kvm_set_phys_mem * end of story. So right now, tcg memory handling is pure overhead for us. Keeping things separated gives opportunity for better specific optimization when possible, not to mention the fact that the possibility that we break tcg while inoccently hacking KVM drops significantly in this area. 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)