From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9y55-0002vE-Gx for qemu-devel@nongnu.org; Fri, 29 May 2009 05:08:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9y50-0002tG-Be for qemu-devel@nongnu.org; Fri, 29 May 2009 05:08:51 -0400 Received: from [199.232.76.173] (port=52348 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9y4y-0002sJ-Vc for qemu-devel@nongnu.org; Fri, 29 May 2009 05:08:46 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:18657) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M9y4w-0000bk-Q3 for qemu-devel@nongnu.org; Fri, 29 May 2009 05:08:43 -0400 Message-ID: <4A1FA616.7040402@siemens.com> Date: Fri, 29 May 2009 11:08:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> In-Reply-To: <4A1F77C0.9050407@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] remove pieces of source code List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org 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 > 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