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

[Anthony Liguori <anthony@codemonkey.ws>]

Jamie Lokier wrote:
> Fabrice Bellard wrote:
>   
>> Regarding the kqemu evolution, I am doing small API changes to make it 
>> more independent from the QEMU internal data structures and to allow 
>> usage from a 32 bit user QEMU application with a 64 bit host. There is 
>> also another small change I did some time ago but never published to 
>> allow paravirtualization of the Linux kernel.
>>     
>
> Do you see integrating it with KVM at some point, developing a merged
> API which supports both hardware-assisted (kvm) or software-assisted
> (kqemu) depending on the host's CPU?
>
> Right now, although it's come from a different background, from a
> user's perspective kvm seems to do essentially the same as kqemu,
> except kvm is faster and kqemu runs on more x86 CPUs.
>
> 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 ;-) to make
> running vMs even more independent of the host CPU.
>   

It wouldn't be too bad if you focused on kqemu-user and limited yourself 
to UP guests.  The first step would be getting the existing KVM support 
code to function with TCG.  For instance, use TCG to run 16-bit code, 
and then KVM to run 32/64-bit code.  Once that was all worked out, the 
rest would be pretty straight-forward porting and code cleanup.

> That would require adding kqemu's software translation/scanning
> callbacks to kvm's API, or vice versa.  But it would have the bonus of
> adding kvm's in-kernel fast APIC emulation to kqemu, possibly the
> paravirt and virtio stuff too, and further unifying kvm-using and
> kqemu-using systems, and combining developer attention from these
> different projects, which all seem to be in the same direction.
>   

There's nothing stopping virtio from being used by QEMU + kqemu except 
for my slowness in improving the code such that it performs well and is 
acceptable to QEMU.

FWIW, the l1_phys_map table is a current hurdle in getting performance.  
When we use proper accessors to access the virtio_ring, we end up taking 
a significant performance hit (around 20% on iperf).  I have some simple 
patches that implement a page_desc cache that cache the RAM regions in a 
linear array.  That helps get most of it back.

I'd really like to remove the l1_phys_map entirely and replace it with a 
sorted list of regions.  I think this would have an overall performance 
improvement since its much more cache friendly.  One thing keeping this 
from happening is the fact that the data structure is passed up to the 
kernel for kqemu.  Eliminating that dependency would be a very good thing!

Regards,

Anthony Liguori

> As someone interested in emulator development I understand the
> different histories of kqemu and kvm.  As a user, however, it seems
> logical at this point to begin seeing them as different ways of
> achieving the same thing, depending on the host CPU capabilities, and
> those things which should not depend on the host CPU - such as virtio,
> APIC emulation etc. - ought to share the same kernel code.
>
> -- Jamie
>
>
>