[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH] remove pieces of source code
Date: Fri, 29 May 2009 04:12:52 -0500
User-agent: Thunderbird (X11/20090409)

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


Anthony Liguori

> Jan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]