From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRYIO-000423-Do for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:43:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRYIM-0003zu-Fv for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:42:59 -0500 Received: from [199.232.76.173] (port=56842 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRYIM-0003zZ-7r for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:42:58 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:58047) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRYIL-0000jh-RR for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:42:58 -0500 Received: by qyk13 with SMTP id 13so9792809qyk.10 for ; Mon, 26 Jan 2009 12:42:54 -0800 (PST) Message-ID: <497E203F.7090909@codemonkey.ws> Date: Mon, 26 Jan 2009 14:42:39 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/6] Bypass tcg memory functions -v1.0-2009 References: <1232477465-32386-1-git-send-email-glommer@redhat.com> <20090121114626.GA628@poweredge.glommer> <18807.22653.889113.401463@mariner.uk.xensource.com> <200901220011.18142.paul@codesourcery.com> In-Reply-To: <200901220011.18142.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Ian Jackson , Paul Brook Paul Brook wrote: > On Wednesday 21 January 2009, Ian Jackson wrote: > >>> 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. > That's a bit of a simplification. TCG needs a fair bit more than what KVM and Xen needs. TCG needs to keep track of any write operations to memory that could possibly be translated to flush the translation caches. TCG also maintains a software TLB and therefore is going to have a different set of sensitivities to the performance characteristics of RAM lookup since the performance overhead occurs on every software TLB miss. Conversely, KVM needs to only keep track of MMIO regions since the kernel tracks RAM regions. There is no software TLB so the cost of a TLB miss is neglible. There is no concern about icache flushing because the hardware will take care of this. That said, it may be possible to develop a unified implementation. However, it has been expressed previously (by Fabrice, among others) that there is a desire to decouple the CPU execution code (be it TCG or KVM) from the rest of QEMU so that you could even plug-in new CPU emulators rather easily. That is what this patch series is doing primarily, establishing that interface. > 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. > Laziness is distinctly different from incremental development. We know this code will do well for KVM, so let's use it for KVM and iron out any problems. After someone has done the work of doing performance measurement on the TCG code and adjusting the slot code so that it can be hooked appropriate for TCG, we can convert TCG to using it, if appropriate. At the end of the day, we're talking about 200-300 lines of code. I'm not hugely concerned that we're duplicating code within QEMU. Regards, Anthony Liguori > Paul > > >