Re: [Qemu-devel] Re: KQEMU code organization

[Anthony Liguori]

Jamie Lokier wrote:
> Paul Brook wrote:
>   
> > > I.e. kvm has two sub-modules for Intel VT and AMD SVM extensions (I
> > > think that's their names).  It would be great if it hard a third KQEMU
> > > sub-module (which would of course be the most complicated ;-)
> > >       
> > I believe this is also a prerequisite for getting kqemu merged into
> > maintream kernels, which IMHO is the only sane goal to have. Out of
> > tree kernel modules simply aren't worth the effort.
> >     
>
> I think there's utility in crossover between both of them too.
>   

There are some architectural incompatibilities.  For instance, KVM 
support guest SMP but the code TCG generates does not ensure atomic 
operations are truly atomic.  In general, it may not be possible to do 
this across architectures without employing the use of a big lock.

Also, when you mix dynamic translation in userspace with direct 
execution, it implies you have to completely flush the shadow page table 
cache.  This is going to severely impact performance so I don't know 
that there are a lot of circumstances where using TCG would improve 
performance.

KVM already does some instruction patching FWIW.  For instance, TPR 
accesses are modified in Windows guests to prevent a vmexit from 
occurring since Windows accesses the TPR so frequently.

Regards,

Anthony Liguori

> Sometimes it would be nice to have the speed and directness of kvm,
> with the code scanning and replacement abilities of kqemu to block
> particular instructions, pretend to be a specific CPU model, or
> replace some hardware-accessing instruction sequences instead of
> trapping and emulating them - without the guest seeing the replacement.
>
> -- Jamie
>
>
>