Re: [Qemu-devel] Re: Killing KQEMU

[Avi Kivity <avi@redhat.com>]

Chris Frey wrote:
> On Tue, Jun 02, 2009 at 01:54:30PM +0100, Paul Brook wrote:
>   
>> osdep.c:/* FIXME: This file should be target independent. However it has kqemu
>> vl.c:    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
>> cpu-common.h: #ifdef CONFIG_KQEMU /* FIXME: This is wrong.  */
>> exec.c: #elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)
>>     
>
> These are fairly small annoyances, no?  

Not supporting >2GB guests is a large annoyance (very large if you have 
128GB of RAM).  Don't know about the others.  I think kqemu also blocks 
memory hotplug.

>> Or let me put it another way: At some point I'll get fed up of the
>> limitations that kqemu currently imposes, and deliberately break it.
>>     
>
> I would hope that anyone who deliberately breaks kqemu support would be
> kind enough to post that fact to the mailing list, with a description of
> what's broken and why, so that others may step up to the plate and fix it.
>
> Breaking something deliberately and quietly, only to use it later as an
> excuse to remove the feature could be seen as anti-social.
>   

If you're stepping up I can point out the problems I'm aware of.

>> If it remains broken then it will be removed. You get to decide whether
>> you want to fix kqemu, start again from scratch (probably enhancing KVM),
>> or keep using old versions of qemu.
>>     
>
> The KVM website (http://www.linux-kvm.org/) states very clearly that its
> goal is for systems that support virtualization extensions.  Is it possible
> to write a pluggable KQEMU backend to KVM, for old systems, that QEMU could
> use blindly as a native KVM system?  

It is possible, however it is a very difficult undertaking.

> How open are the KVM developers to API
> changes imposed by KQEMU-like functionality?
>   

Clean, unintrusive patches will be accepted, if there is a commitment to 
maintain them.

>> As I've said before, if you're serious about maintaining kqemu you probably 
>> need to get it integrated into mainstream kernels. Without this a large 
>> portion of the relevant communities simply aren't going to care.
>>     
>
> According to other threads on this list, it would appear that getting
> KQEMU into the kernel is often thought of as impossible, or "would never
> happen."  So this isn't really a solution either.

kqemu as is is probably unmergable.  Your best bet is though kvm since 
that already has the interfaces defined and accepted (as well as large 
chunks of code like the mmu and x86 emulator that can be reused.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.