From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDdxv-0003cT-UW for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:28:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDdxr-0003Ss-BC for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:28:39 -0400 Received: from [199.232.76.173] (port=36085 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDdxr-0003Sh-2j for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:28:35 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35161) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDdxq-0000sB-Hg for qemu-devel@nongnu.org; Mon, 08 Jun 2009 08:28:34 -0400 Message-ID: <4A2D03E7.8070702@redhat.com> Date: Mon, 08 Jun 2009 15:28:23 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] POLL: Why do you use kqemu? 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> <20090608121626.GF25684@shareable.org> In-Reply-To: <20090608121626.GF25684@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Lennart Sorensen , "qemu-devel@nongnu.org" , Anton D Kachalov Jamie Lokier wrote: > 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). > I think you mean tcg-svm, not nested svm. If the guest's guest boots, then 16 bit mode works. Of course, this area is heavily experimental. > 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's Intel-speak for "we fixed the bug where you couldn't virtualize real mode". >> 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. > It isn't complete, and things like interrupt injection aren't implemented at all. > 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. > kvm is designed to be useful without full emulation in userspace. -- error compiling committee.c: too many arguments to function