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

[Fabrice Bellard <fabrice@bellard.org>]

Anthony Liguori wrote:
> 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.

But for the x86 on x86 case, it seems possible to make QEMU/TCG SMP safe
(it would consist in using x86 lock instructions on the host when the
guest uses them).

> 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.

Code patching seems interesting. Although I did not look in detail, it
seems that VirtualBox use it extensively and gets very good performance
without using hardware virtualization. The "beauty" of it is that the
code patching hacks can stay outside the kernel module. I wonder what
are their plan for their kernel module !

Anyway, I don't think it is worth trying to get kqemu into the Linux
kernel. Moreover, I have no plan to change the kqemu interface to match
the one of KVM. It seems simpler just to have a wrapper for both inside
the user space QEMU. However, my upcoming changes for kqemu and QEMU
will get the interface closer because kqemu will no longer peek into the
QEMU physical to ram translation table.

Fabrice.