[Qemu-devel] Re: KQEMU code organization

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

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

I guess you mean real-mode code with 16-bit here. /me always wondered
why it takes an in-kernel code interpreter for kvm to achieve this - at
least as long as it runs via qemu.

Jan

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