From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDdmH-0005o6-9Y for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:16:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDdmC-0005nV-Ds for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:16:36 -0400 Received: from [199.232.76.173] (port=37899 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDdmC-0005nS-Be for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:16:32 -0400 Received: from mail2.shareable.org ([80.68.89.115]:45888) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MDdmB-0006gL-S5 for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:16:32 -0400 Date: Mon, 8 Jun 2009 13:16:26 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] POLL: Why do you use kqemu? Message-ID: <20090608121626.GF25684@shareable.org> References: <4A26F1E3.1040509@codemonkey.ws> <4A27FC69.9070501@mayc.ru> <20090605201415.GA22847@csclub.uwaterloo.ca> <20090608001312.GE15426@shareable.org> <4A2CA8C2.2080004@redhat.com> <20090608115755.GD25684@shareable.org> <4A2CFE07.90700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2CFE07.90700@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Lennart Sorensen , "qemu-devel@nongnu.org" , Anton D Kachalov Avi Kivity wrote: > Jamie Lokier wrote: > >So the "Guest Support Status" prominently on the front page of > >linux-kvm.org is wrong for current versions? It specifically mentions > >AMD hosts. > > > >(I notice AMD KVM != Intel KVM hasn't factored into this discussion yet...) > > > >Guest KVM tested Host CPU/bits Result > >---------------------------------------------------------------- > >Windows 98SE kvm-63 Intel 32 Fails > >Windows 98SE kvm-80, 2.6.27.7 AMD 64 no way > >Windows 95 kvm-44, 2.6.23-rc8 AMD 64, 32 no way > > > > Well, maybe there's some other bug in there. But kvm-amd 16 bit support > is as good as the native cpu's. kvm-intel with the new 'unrestricted > guest' should be the same. I'm happy to test older guests on latest KVMs, and QEMU upstream with KVM support if that works. But the AMD and VIA hardware I have does not support KVM; all my KVM-capable machines are Intels. I could test using the nested-SVM support, I suppose, but I'm not that masochistic yet. :-) (I wonder if nested-SVM supports 16 bit nested guests). Can you say a bit more about what 'unrestricted guest' means? Does it mean that some protection is disabled (like in vm86 mode on x86_32)? > >>>It has come up before that kvm will eventually support 16-bit code > >>>better, although I got the impression that it would never support full > >>>16-bit virtualisation accurately, so e.g. Windows 95 will not run on > >>>it, nor some other partially 16-bit OSes. Possibly not even very old > >>>versions of Linux, I'm not sure. > >>> > >>>Don't ask me _why_ I want to run them. :-) > >>> > >>>Just a data point that it's not just about the host hardware, and as > >>>far as I know kqemu can accelerate them. > >>> > >>> > >>It falls back to qemu for 16-bit code. > >> > > > >I was under the impression it was planned to remove TCG support when > >using KVM. If not, fine, it's ok for 16-bit code to run in TCG and > >probably better than vm86 or the in-kernel interpreter. > > vm86 doesn't work on x86_64. I don't have any personal x86_64 machines, and nearly all my KVM usage is done on x86_32 so it didn't cross my mind. > kvm will run most 16-bit code natively, > just have to complete task switch support and fix any bugs. Ah, the old "fix any bugs" caveat, combined with "most" :-) I looked at KVM's 16-bit interpreter a few months ago, and it wasn't clear (to me) if it covered the complete 16-bit opcode space. Is there a reason to duplicate QEMU's task switch emulation, instead of trapping out to QEMU? Modern OSes don't use x86 task switching (because it's slow on real CPUs) except for ring stack switches, so it's hardly a performance requirement. Accurate task switch support is fiddly to get right. Think of all the exceptions including paging/segment exceptions in the middle of reading the TSS block. -- Jamie