From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1pyK-0007i2-I0 for qemu-devel@nongnu.org; Thu, 29 May 2008 17:47:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1pyI-0007gp-1g for qemu-devel@nongnu.org; Thu, 29 May 2008 17:47:43 -0400 Received: from [199.232.76.173] (port=54238 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1pyH-0007gk-PA for qemu-devel@nongnu.org; Thu, 29 May 2008 17:47:41 -0400 Received: from relay2-v.mail.gandi.net ([217.70.178.76]:33822) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K1pyF-0001vT-Hp for qemu-devel@nongnu.org; Thu, 29 May 2008 17:47:40 -0400 Message-ID: <483F2437.1090606@bellard.org> Date: Thu, 29 May 2008 23:46:31 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KQEMU code organization References: <483C3D55.2000508@siemens.com> <483EA1AD.1010901@bellard.org> <20080529161322.GB21610@shareable.org> <200805291726.05398.paul@codesourcery.com> <20080529163536.GD21610@shareable.org> <483EEB5D.1030004@codemonkey.ws> In-Reply-To: <483EEB5D.1030004@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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 Anthony Liguori wrote: > Jamie Lokier wrote: >> Paul Brook wrote: >> >>>> I.e. kvm has two sub-modules for Intel VT and AMD SVM extensions (I >>>> think that's their names). It would be great if it hard a third KQEMU >>>> sub-module (which would of course be the most complicated ;-) >>>> >>> I believe this is also a prerequisite for getting kqemu merged into >>> maintream kernels, which IMHO is the only sane goal to have. Out of >>> tree kernel modules simply aren't worth the effort. >>> >> >> I think there's utility in crossover between both of them too. >> > > There are some architectural incompatibilities. For instance, KVM > support guest SMP but the code TCG generates does not ensure atomic > operations are truly atomic. In general, it may not be possible to do > this across architectures without employing the use of a big lock. But for the x86 on x86 case, it seems possible to make QEMU/TCG SMP safe (it would consist in using x86 lock instructions on the host when the guest uses them). > Also, when you mix dynamic translation in userspace with direct > execution, it implies you have to completely flush the shadow page table > cache. This is going to severely impact performance so I don't know > that there are a lot of circumstances where using TCG would improve > performance. > > KVM already does some instruction patching FWIW. For instance, TPR > accesses are modified in Windows guests to prevent a vmexit from > occurring since Windows accesses the TPR so frequently. Code patching seems interesting. Although I did not look in detail, it seems that VirtualBox use it extensively and gets very good performance without using hardware virtualization. The "beauty" of it is that the code patching hacks can stay outside the kernel module. I wonder what are their plan for their kernel module ! Anyway, I don't think it is worth trying to get kqemu into the Linux kernel. Moreover, I have no plan to change the kqemu interface to match the one of KVM. It seems simpler just to have a wrapper for both inside the user space QEMU. However, my upcoming changes for kqemu and QEMU will get the interface closer because kqemu will no longer peek into the QEMU physical to ram translation table. Fabrice.