From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVpEF-0003yO-Gn for qemu-devel@nongnu.org; Sat, 07 Feb 2009 10:36:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVpED-0003xu-4d for qemu-devel@nongnu.org; Sat, 07 Feb 2009 10:36:22 -0500 Received: from [199.232.76.173] (port=60036 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVpEC-0003xr-VW for qemu-devel@nongnu.org; Sat, 07 Feb 2009 10:36:20 -0500 Received: from mail2.shareable.org ([80.68.89.115]:43153) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LVpEC-00055T-KC for qemu-devel@nongnu.org; Sat, 07 Feb 2009 10:36:20 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LVpE4-0001I8-VO for qemu-devel@nongnu.org; Sat, 07 Feb 2009 15:36:13 +0000 Date: Sat, 7 Feb 2009 15:36:12 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: Cutting a new QEMU release Message-ID: <20090207153612.GA4768@shareable.org> References: <1233825194.6637.4.camel@ecrins.fosdick.home.net> <498AF6FC.90803@codemonkey.ws> <498D7837.1090803@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498D7837.1090803@mail.berlios.de> 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 Stefan Weil wrote: > The kvm kernel module could be a good replacement for kqemu > for those running linux on new cpus. It's not yet, though. kvm doesn't run 16-bit code properly. I use kqemu to run older OSes, and kvm to run current ones. I like the idea of a "kvm-soft", which is basically kqemu with a kvm interface. It would need a few extensions on the kvm interface, of course. Another potential use for _part_ of kqemu, or kvm-soft, is emulating other CPUs with host kernel support for the memory map, instead of full software TLB. That might be a performance accelerator for emulation, for some combinations of host and target CPUs where it's feasible to map the memory in that way. If kqemu were evolved into an accelerator for cross-CPU emulation in that way, then its current use as an x86-on-x86 accelerator would just be a special case of that. -- Jamie