From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1kxh-0006g7-2n for qemu-devel@nongnu.org; Thu, 29 May 2008 12:26:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1kxf-0006f9-AD for qemu-devel@nongnu.org; Thu, 29 May 2008 12:26:44 -0400 Received: from [199.232.76.173] (port=41534 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1kxe-0006f0-Vw for qemu-devel@nongnu.org; Thu, 29 May 2008 12:26:43 -0400 Received: from yx-out-1718.google.com ([74.125.44.158]:39738) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K1kxe-00060d-QC for qemu-devel@nongnu.org; Thu, 29 May 2008 12:26:43 -0400 Received: by yx-out-1718.google.com with SMTP id 3so347643yxi.82 for ; Thu, 29 May 2008 09:26:40 -0700 (PDT) Message-ID: <483ED935.2060802@codemonkey.ws> Date: Thu, 29 May 2008 11:26:29 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KQEMU code organization 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> In-Reply-To: <20080529161322.GB21610@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: qemu-devel@nongnu.org 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. > That would require adding kqemu's software translation/scanning > callbacks to kvm's API, or vice versa. But it would have the bonus of > adding kvm's in-kernel fast APIC emulation to kqemu, possibly the > paravirt and virtio stuff too, and further unifying kvm-using and > kqemu-using systems, and combining developer attention from these > different projects, which all seem to be in the same direction. > There's nothing stopping virtio from being used by QEMU + kqemu except for my slowness in improving the code such that it performs well and is acceptable to QEMU. FWIW, the l1_phys_map table is a current hurdle in getting performance. When we use proper accessors to access the virtio_ring, we end up taking a significant performance hit (around 20% on iperf). I have some simple patches that implement a page_desc cache that cache the RAM regions in a linear array. That helps get most of it back. I'd really like to remove the l1_phys_map entirely and replace it with a sorted list of regions. I think this would have an overall performance improvement since its much more cache friendly. One thing keeping this from happening is the fact that the data structure is passed up to the kernel for kqemu. Eliminating that dependency would be a very good thing! Regards, Anthony Liguori > As someone interested in emulator development I understand the > different histories of kqemu and kvm. As a user, however, it seems > logical at this point to begin seeing them as different ways of > achieving the same thing, depending on the host CPU capabilities, and > those things which should not depend on the host CPU - such as virtio, > APIC emulation etc. - ought to share the same kernel code. > > -- Jamie > > >