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

[Anthony Liguori]

Jan Kiszka wrote:
> 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 <address@hidden
>>>       
>> 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?"
>   

Yes.  Note that -no-kqemu doesn't fix the above complaint but it fixes
the following one.  So unless there are major objections, I'd like to
make -no-kqemu the default for 0.11.  We can then discuss whether to
make kqemu deprecated and scheduled for removal in 0.12.

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

If we disable in configure, then we should remove it from the tree.  The
feeling is that code that's disabled by default is too likely to bitrot.

I think you've made a reasonable suggestion though.  So unless there are
strong feelings otherwise, I think we should do -no-kqemu by default for
0.11, see what the reaction is, then figure out whether we want to
deprecate/remove.

Regards,

Anthony Liguori

> Jan
>
>