From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LVqJ4-0002JB-RE for qemu-devel@nongnu.org; Sat, 07 Feb 2009 11:45:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LVqJ4-0002Ij-18 for qemu-devel@nongnu.org; Sat, 07 Feb 2009 11:45:26 -0500 Received: from [199.232.76.173] (port=56688 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LVqJ3-0002Ia-QK for qemu-devel@nongnu.org; Sat, 07 Feb 2009 11:45:25 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:39977) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LVqJ3-0007gH-2P for qemu-devel@nongnu.org; Sat, 07 Feb 2009 11:45:25 -0500 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id A0BCBFA1ABC2 for ; Sat, 7 Feb 2009 17:45:19 +0100 (CET) Received: from [88.65.43.151] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LVqIx-0004jt-00 for qemu-devel@nongnu.org; Sat, 07 Feb 2009 17:45:19 +0100 Message-ID: <498DBA9B.3070203@web.de> Date: Sat, 07 Feb 2009 17:45:15 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1233825194.6637.4.camel@ecrins.fosdick.home.net> <498AF6FC.90803@codemonkey.ws> <498D7837.1090803@mail.berlios.de> <20090207153612.GA4768@shareable.org> In-Reply-To: <20090207153612.GA4768@shareable.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC895CA5FB3F540101A8E4EA" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: Cutting a new QEMU release 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC895CA5FB3F540101A8E4EA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > Stefan Weil wrote: >> The kvm kernel module could be a good replacement for kqemu >> for those running linux on new cpus. >=20 > It's not yet, though. kvm doesn't run 16-bit code properly. You mean real mode, I guess. I think there are still a few holes in the emulator that may bite you on certain DOSes or with some fancy boot loaders. But 16-bit protected mode runs as fine as 32 or 64 bit for quite a while now. > I use kqemu to run older OSes, and kvm to run current ones. I haven't found much code that caused troubles to kvm, but a lot that broke kqemu - YMMV. >=20 > 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. >=20 > 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. >=20 > 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. Most of kqemu's code base deals with / works around unvirtualizable x86 cruft. Memory management, page table handling is only a small subset. And that part is focused on running guest code under the control of the monitor, not in the TCG user space environment. So even if there is something a kernel part could contribute to accelerate TCG execution, I'm not sure that there will be a high re-use of kqemu's infrastructure - or even kvm's. You also should be aware of the fact the kqemu's x86 virtualization is fairly fragile, only working for OSes like Linux and Windows, and even there not always reliably (I've seen Linux kernels crashing). We are evaluating alternative workarounds for these issues, but they will come with their own limitations. Either they are too costly to implement (binary translation) given the remaining lifetime of kqemu, or they cause problems with self-checking guests (patch in traps & emulate). And both will need special user space support beyond current kqemu's or kvm's need. Depending on the outcome (for the picky customer OS), we may be able to contribute to a properly maintained kqemu tree (or better: kvm-soft). But this is yet open. Jan --------------enigBC895CA5FB3F540101A8E4EA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkmNuqAACgkQniDOoMHTA+ml7ACff+2Q0KhJk4KJ3Mt7ZdXtvJQD /JMAn2ZRLEyrl70M+qzmEzXTcBLedkGg =W4az -----END PGP SIGNATURE----- --------------enigBC895CA5FB3F540101A8E4EA--