From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPVrs-0001dg-Oo for qemu-devel@nongnu.org; Wed, 21 Jan 2009 00:43:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPVrq-0001dU-Ut for qemu-devel@nongnu.org; Wed, 21 Jan 2009 00:43:11 -0500 Received: from [199.232.76.173] (port=48201 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPVrq-0001dR-PW for qemu-devel@nongnu.org; Wed, 21 Jan 2009 00:43:10 -0500 Received: from mx20.gnu.org ([199.232.41.8]:4857) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPVrq-00023a-Hb for qemu-devel@nongnu.org; Wed, 21 Jan 2009 00:43:10 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPVrp-0002o3-Ny for qemu-devel@nongnu.org; Wed, 21 Jan 2009 00:43:10 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 Date: Wed, 21 Jan 2009 05:43:06 +0000 References: <1232477465-32386-1-git-send-email-glommer@redhat.com> In-Reply-To: <1232477465-32386-1-git-send-email-glommer@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <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: qemu-devel@nongnu.org Cc: Glauber Costa , aliguori@us.ibm.com 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. Paul