From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0p6P-0000Ll-M1 for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:12:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0p6N-0000LY-9C for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:12:08 -0500 Received: from [199.232.76.173] (port=39616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0p6N-0000LV-3l for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:12:07 -0500 Received: from rv-out-0708.google.com ([209.85.198.241]:45414) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L0p6M-0003rT-Lb for qemu-devel@nongnu.org; Thu, 13 Nov 2008 22:12:06 -0500 Received: by rv-out-0708.google.com with SMTP id f25so1120685rvb.22 for ; Thu, 13 Nov 2008 19:12:04 -0800 (PST) Message-ID: Date: Fri, 14 Nov 2008 04:12:04 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c In-Reply-To: <491C5363.6010000@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226527840-14183-1-git-send-email-aliguori@us.ibm.com> <491C5363.6010000@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Carsten Otte , Anthony Liguori , Hollis Blanchard , kvm-devel , qemu-devel@nongnu.org, Paul Brook 2008/11/13 Anthony Liguori : > andrzej zaborowski wrote: >> Is this going a bit in the opposite direction to where QEMUAccel is >> going? What Fabrice suggests seems to be like QEMUAccel, with TCG >> treated as another accelerator. >> > > QEMUAccel is a bit orthogonal to what I'm talking about. There is already > KVM support in QEMU today and I'm merely looking to restructure existing > code so that I can build a version of QEMU that has no TCG support, only KVM > support. TCG is too intimately woven into QEMU right now. You could think > of this perhaps as a precursor to making TCG more of an "accelerator" than > it is today. Ah, I agree with your patch, I was only commenting on the idea of *-kvm/ targets. I see something like QEMUAccel as a way to turn on and off the cpu emulators (TCG, kvm, kqemu). Ofcourse, kqemu depends on a fallback emulator - currently TCG - I guess it could be possible to run kqemu with kvm as the fall back and not compile in TCG (even if not a very useful configuration). > > But wrt QEMUAccel and KVM, there are 5 places in QEMU where there is KVM > specific code. > > One is cpu-exec.c to invoke the kvm exec routine instead of TCG. kqemu has > something similar. Unfortunately, kqemu relies on some state that's only > available in cpu-exec.c so we can't make this a single function pointer > invocation without major surgery on cpu-exec. > > One is vl.c to initialize KVM support. kqemu doesn't need this. > > One is exec.c, to hook cpu_register_physical_memory. kqemu does this too so > it could conceivably be a hook. > > Another one is monitor.c to implement 'info kvm'. Not really a place for a > hook. Ideally we could register the monitor callback from kvm-all.c when we > initialize KVM. > > Finally, there is a hook in hw/acpi.c to disable SMM support when using KVM. > This is KVM specific because KVM doesn't support SMM. kqemu uses TCG to > run SMM code. > > Since there is only one shared hook ATM, I don't think something like > QEMUAccel is all that useful for KVM. On the other hand, there are 42 > places that are kqemu specific. I think kqemu could be refactored to > eliminate most of these. > > kqemu relies on TCG so you can't really decouple them from each other. > >> BTW It would be great if before merging a change like this you >> review/merge the patches submitted to the list that might touch the >> same area so as not to break them (such as Jan Kiszka's >> single-stepping/watchpoint fixes). >> > > Yeah, I will make sure to. Many thanks for that. Regards