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

[Jamie Lokier <jamie@shareable.org>]

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