From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L17xd-0006Rd-Uz for qemu-devel@nongnu.org; Fri, 14 Nov 2008 18:20:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L17xb-0006PJ-HR for qemu-devel@nongnu.org; Fri, 14 Nov 2008 18:20:20 -0500 Received: from [199.232.76.173] (port=54142 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L17xb-0006PD-E5 for qemu-devel@nongnu.org; Fri, 14 Nov 2008 18:20:19 -0500 Received: from ag-out-0708.google.com ([72.14.246.245]:49640) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L17xb-0005JP-33 for qemu-devel@nongnu.org; Fri, 14 Nov 2008 18:20:19 -0500 Received: by ag-out-0708.google.com with SMTP id 31so1526680agc.5 for ; Fri, 14 Nov 2008 15:20:18 -0800 (PST) Message-ID: <491E07AD.8030108@codemonkey.ws> Date: Fri, 14 Nov 2008 17:20:13 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c References: <1226527840-14183-1-git-send-email-aliguori@us.ibm.com> <20081114040311.GN2055@shareable.org> <491D8624.50800@codemonkey.ws> <20081114231309.GD19384@shareable.org> In-Reply-To: <20081114231309.GD19384@shareable.org> 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: Jamie Lokier Cc: Carsten Otte , Paul Brook , qemu-devel@nongnu.org, kvm-devel , Hollis Blanchard Jamie Lokier wrote: > Firstly: > > That doesn't make sense: why would you do an expensive TCG translation > every time you hit the same code? After the first encounter, if the > code page hasn't been modified, it should be a TB cache lookup to > already translated code. > Except that once you run under KVM again, you lose all dirty information and you have to invalidate all TBs. FWIW, a few years ago, we implemented this concept with QEMU and Xen. That's where my data is coming from. > I'm guessing the cost of TB cache lookup is much closer to 3k than > 300k cycles, maybe even lower... > You're guessing and it doesn't matter anyway because the TB cache has to be invalidated. > Secondly: > > In these cases, you can use a special fast translation (when it's not > cached) which just copies the instructions 1:1 from the guest, simply > converting the special instructions (MMIO, anything else needing it) > to helper calls. That's possible because you know the host is ture > architeccompatible with the guest, as it's running KVM. > You can't copy 1:1 because the instructions aren't 1:1. Only trivial instructions that manipulate registers remain the same but even then, you have to do register renaming and on the x86 this probably means you'll have to spill some registers because you have so few. Any memory reference (mov, push, pop, etc.) must be translated to a different instruction because you don't have a virtual address that can be accessed directly so you need a hook to simulate a tlb miss. You can preserve atomicity if you try hard enough, but it certainly isn't a 1:1 translation in softmmu mode. >> If you also consider all the potential locking issues with SMP guests, I >> think it's pretty likely that there are few cases where dropping to TCG >> is going to be a net performance win. >> > > VMware claimed otherwise when Intel first brought out CPU support for > virtualisation. > That's just not true. The paper that you're most likely referencing was much more nuanced than that and the hardware has improved dramatically since then. > SMP works fine if you map guest instructions 1:1 to host instructions > with helper calls for special cases. Even atomics, load-locked > sequences and complex weak memory ordering things would behave > correctly. > You can't translate 1:1 so your argument falls apart. Regards, Anthony Liguori > Oops, I believe I just argued for keeping the TB cache and code > translation but not using TCG :-) > > -- Jamie >