Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c

[Anthony Liguori]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
> > Unlike kqemu, KVM does not use TCG at all when accelerating QEMU.  Having TCG
> > present is not a problem when using KVM on x86.  x86 already has TCG host and
> > target support and it's quite convenient to be able to disable/enable KVM and
> > compare it to TCG when debugging.
> >     
>
> I agree with removing/isolating the dependency on TCG, and there are good
> reasons for it.
>
> But does the fact KVM doesn't use TCG prevent KVM from running some
> x86 modes correctly?  E.g. I gather 16-bit code is run by KVM using
> VM86 mode, which is not exactly correct.  It would be nice to have KVM
> acceleration but also complete and correct emulation, by switching to
> TCG for those modes.
>   

That's just a limitation of Intel VT.  AMD SVM runs 16-bit code 
natively.  We're slowly improving our in-kernel emulator so eventually 
we'll be able to emulate 16-bit mode in the kernel.

Running 16-bit code in TCG is something that has been considered.

> Also, an earlier thread pointed out that loops doing a lot of MMIO are
> _slower_ with KVM than without - this manifested as very slow VGA
> output for some guests.  Having KVM pass control to TCG for short runs
> of guest instructions which do MMIO, or other instructions which need
> to be emulated, would accelerate KVM in this respect.
>   

It falls apart for SMP guests.  TCG does not preserve atomicity of 
memory instructions so you could never have an SMP VCPU running on bare 
metal while TCG is running.  There is a rather large initial cost for 
building the TBs too so in practice, there are few areas that benefit 
from this sort of hand off.

The VGA optimization actually addresses this problem in a much nicer 
way.  KVM also supports MMIO batching which we'll eventually merge that 
covers the remaining cases pretty well.

Regards,

Anthony Liguori

> -- Jamie
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>