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

[Jamie Lokier <jamie@shareable.org>]

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.

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.

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