From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1lNU-0002V0-Dz for qemu-devel@nongnu.org; Thu, 29 May 2008 12:53:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1lNS-0002Uo-Vd for qemu-devel@nongnu.org; Thu, 29 May 2008 12:53:23 -0400 Received: from [199.232.76.173] (port=39265 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1lNS-0002Ul-PH for qemu-devel@nongnu.org; Thu, 29 May 2008 12:53:22 -0400 Received: from gecko.sbs.de ([194.138.37.40]:20161) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1lNS-0003xo-DW for qemu-devel@nongnu.org; Thu, 29 May 2008 12:53:22 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4TGrKmj009214 for ; Thu, 29 May 2008 18:53:20 +0200 Received: from [139.25.109.167] (mchn012c.ww002.siemens.net [139.25.109.167] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4TGrK1N025148 for ; Thu, 29 May 2008 18:53:20 +0200 Message-ID: <483EDF80.3060003@siemens.com> Date: Thu, 29 May 2008 18:53:20 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <483C3D55.2000508@siemens.com> <483C8705.307@bellard.org> <483D81FA.5070202@siemens.com> <483D8A2E.5070907@bellard.org> <483D8E9A.40509@siemens.com> <483EA1AD.1010901@bellard.org> <20080529161322.GB21610@shareable.org> <483ED935.2060802@codemonkey.ws> In-Reply-To: <483ED935.2060802@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KQEMU code organization 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: >> Fabrice Bellard wrote: >> >>> Regarding the kqemu evolution, I am doing small API changes to make >>> it more independent from the QEMU internal data structures and to >>> allow usage from a 32 bit user QEMU application with a 64 bit host. >>> There is also another small change I did some time ago but never >>> published to allow paravirtualization of the Linux kernel. >>> >> >> Do you see integrating it with KVM at some point, developing a merged >> API which supports both hardware-assisted (kvm) or software-assisted >> (kqemu) depending on the host's CPU? >> >> Right now, although it's come from a different background, from a >> user's perspective kvm seems to do essentially the same as kqemu, >> except kvm is faster and kqemu runs on more x86 CPUs. >> >> 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 ;-) to make >> running vMs even more independent of the host CPU. >> > > It wouldn't be too bad if you focused on kqemu-user and limited yourself > to UP guests. The first step would be getting the existing KVM support > code to function with TCG. For instance, use TCG to run 16-bit code, > and then KVM to run 32/64-bit code. Once that was all worked out, the > rest would be pretty straight-forward porting and code cleanup. I guess you mean real-mode code with 16-bit here. /me always wondered why it takes an in-kernel code interpreter for kvm to achieve this - at least as long as it runs via qemu. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux