Re: [Qemu-devel] POLL: Why do you use kqemu?

[Avi Kivity <avi@redhat.com>]

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