From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LEoQf-00008C-P4 for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:18:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LEoQf-00007u-BZ for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:18:53 -0500 Received: from [199.232.76.173] (port=40711 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEoQf-00007r-8J for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:18:53 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:45221) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LEoQe-0005B7-Vj for qemu-devel@nongnu.org; Mon, 22 Dec 2008 12:18:53 -0500 Received: by qw-out-1920.google.com with SMTP id 5so932824qwc.4 for ; Mon, 22 Dec 2008 09:18:49 -0800 (PST) Message-ID: <5d6222a80812220918w19325bc0p4a755582aede5f80@mail.gmail.com> Date: Mon, 22 Dec 2008 15:18:49 -0200 From: "Glauber Costa" Subject: Re: [Qemu-devel] [PATCH 0/5] Replace tcg memory functions In-Reply-To: <18767.51690.17022.636379@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1229546822-11972-1-git-send-email-glommer@redhat.com> <18767.51690.17022.636379@mariner.uk.xensource.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: stefano.stabellini@eu.citrix.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com > I don't have an objection to this patch series even it may mean I have > to do some additional fixups. > > But I did want to point out a misapprehension in Glauber Costa's > comments. The qemu-xen tree does not use the TCG parts of qemu at > all; we don't even compile them in. We provide our own implementation > of cpu_physical_memory_rw and so on. > I never stated that you depend on that. We (kvm) don't depend on that either, but nevertheless, have to live with it. An alternative, of course, is to heavily patch your qemu tree, providing your own implementation of this, and everything else. The aim of this patch series is _exactly_ to provide a way for us (kvm, xen, etc) to do that in a clean way, without deviating from upstream, preferably merging your code back. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."