[Qemu-devel] Re: [PATCH] remove pieces of source code

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

Anthony Liguori wrote:
> Glauber Costa wrote:
>> Have you ever seen a girl so beautiful that you, geeky,
>> think: "I'll never stand a chance"?
>>
>> But sometimes, you decide to make your move anyway. There's
>> always the chance that in that very day she'll be specially
>> in good mood, and you'll get what you want.
>>
>> With the exception of the fact that qemu is not a girl,
>> that's more or less what I'm trying to do here: Hopefully,
>> nobody will notice what I'm trying to do, and will commmit it.
>> Later, when realizing, it will be too late. Victory will be mine.
>>
>> Or maybe people will even agree. For that, I'll try briefly
>> to arguee my point, without disclosing to much, avoiding
>> jeopardizing the strategy I explained above:
>>
>>   This patch removes a piece of code that is unmaintaned,
>>   that does not receive an update for years,
>>   that get bug reports on the list that nobody fixes, because
>>   nobody really understands,
>>   that places some artificial constraints on other subsystems
>>
>> Signed-off-by: Glauber Costa <glommer@redhat.com
> 
> Let's actually build a proper case instead of closing our eyes and
> hitting enter.  Here are the downsides of kqemu I know of:
> 
>  o Since it's enabled by default, it forces the default build to support
> < 4GB of guest memory

Making -no-kqemu the default appears as a reasonable first step then -
to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
collect complains like: "What the heck happened to kqemu?"

>  o It attempts to use /dev/shm for guest memory which means a special
> option is needed in the default build to use more than 1/2 of host ram size
>  o It touches an awful lot of places in QEMU
>  o Some of the BIOS changes are particularly nasty and will prevent
> having a unified BIOS between QEMU and Bochs
>  o The kernel bits will never go upstream for Linux
>  o No one actively supports kqemu in upstream QEMU

We did some work on it a few months ago, trying to enhance its support
for segmented guests. It turned out to require unreasonable effort and
would still perform not significantly better than plain qemu in this
context (and our customer dropped the idea to support legacy systems
anyway). The results are a few low-level fixes and enhancements (that I
still want to post once cleaned up) and the confirmation of what is
likely already clear to people who had a look at the kernel bits: They
are almost unmaintainable and can cause severe headache when trying to
understand them.

> 
> That said, here are the arguments for keeping kqemu
> 
>  o Even though it's unmaintained, it seems to work for people

At some point, I bet, at least the Linux bindings will break, and no one
will be interested or able to fix that anymore. Same may happen to other
platforms (doesn't Windows 7 come with a new driver model?).

>  o There is no alternative for non-Linux users and folks with non-VT/SVM
> hardware

The non-HVM argument will become widely irrelevant (for desktops) very
soon. The non-Linux issue will likely persist - unless someone feels so
much pain to write some KVM for those platforms. But as long as there is
a kqemu version that builds and works for them, I think we should keep
QEMU's support. But it should no longer be a first-class citizen: off by
default, factored out into more hooks, maybe even de-optimized where it
blocks development or increases the maintenance effort of QEMU.

Jan

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