From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0euF-0005d3-7D for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:18:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0euB-0005cn-TQ for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:18:54 -0500 Received: from [199.232.76.173] (port=46558 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0euB-0005ck-MV for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:18:51 -0500 Received: from rn-out-0910.google.com ([64.233.170.184]:34970) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L0euB-0004dU-Su for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:18:52 -0500 Received: by rn-out-0910.google.com with SMTP id m61so850558rnd.8 for ; Thu, 13 Nov 2008 08:18:50 -0800 (PST) Message-ID: <491C5363.6010000@codemonkey.ws> Date: Thu, 13 Nov 2008 10:18:43 -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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: andrzej zaborowski Cc: Carsten Otte , Anthony Liguori , Hollis Blanchard , kvm-devel , qemu-devel@nongnu.org, Paul Brook 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. 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. Regards, Anthony Liguori > Cheers > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >