[Qemu-devel] Re: KQEMU code organization

[Jan Kiszka <jan.kiszka@siemens.com>]

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?

I had the same idea while initially looking closer at kqemu, but I
didn't felt familiar enough with the code and its design requirements to
suggest this. :)

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

Well, already the same driver interface to userspace would be great. :->

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

The most important thing, IMHO, this /could/ open the door from mainline
integration of a software-based QEMU accelerator - surely the ultimate
goal /wrt to maintainability and distribution (on Linux).

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

Virtio on x86 requires no special host-kernel support, IIRC. But, yeah,
in-kernel irqchip (including APIC) is a further incentive to motivate
such step.

But - this is all nice on the drawing board. It just requires a
reasonable balance between required effort (wouldn't be small, I guess)
and future relevance. For x86, by AMD and Intel at least (not sure about
VIA right now), you see hardware virtualization in every new processor.
So kqemu becomes less and less relevant over the time. The thrilling
question is: Is that period long enough to justify a kqemu / soft-kvm,
and to push the result mainline?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux