From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAmQV-0000p1-Fh for qemu-devel@nongnu.org; Sun, 31 May 2009 10:54:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAmQQ-0000mm-Vu for qemu-devel@nongnu.org; Sun, 31 May 2009 10:54:19 -0400 Received: from [199.232.76.173] (port=59281 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAmQQ-0000mi-PQ for qemu-devel@nongnu.org; Sun, 31 May 2009 10:54:14 -0400 Received: from mail2.shareable.org ([80.68.89.115]:40764) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MAmQQ-0007Gc-CW for qemu-devel@nongnu.org; Sun, 31 May 2009 10:54:14 -0400 Date: Sun, 31 May 2009 15:53:58 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH] remove pieces of source code Message-ID: <20090531145358.GA25422@shareable.org> References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1FA616.7040402@siemens.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org Jan Kiszka wrote: > > 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. Only if your looking at the virtualisation market. As far as I know - There are no non-Intel, non-AMD CPUs which support HVM - Laptops are outselling desktops these days - Little low-power PCs are gaining in popularity at home Personally I have HVM on one of my laptops but not the other. I have several "media player" nano-ITX PCs, and I don't think any of them support HVM, even the Intel ones. I have one dual-AMD desktop machine which does not have HVM. I have access to two big Intel Xeon servers. Only one has HVM, and annoyingly the faster one does not have HVM, even though it's 64-bit. That's only 2 out 7 PC types I have ready access to which have HVM. I do understand the wish to drop KQEMU, and I understand the wish of the staff developers to not want to spend time supporting platforms they aren't using themselves, and aren't their customers. Especially when it complicates the code base. But it will make QEMU a less useful tool for some. I suspect if QEMU development was still a "hobby" project, the "coolness factor" of being able to do things like KQEMU would win over "target market" rule which I guess is more motivating for paid developers. Anyway, we had this discussion before and the obvious conclusion was that the only viable way to keep KQEMU is if there are volunteers stepping up to maintain it, both the userspace and kernel portions. Or ideally, to replace it with something KVM-compatible, as that would reduce the maintenance burden. For replacing KQEMU on Linux, that's realistic I think. Either it's done, or there's no maintainer anyway. But for non-Linux hosts I see a non-technical problem: - Without API documentation you have to read the KVM source code. - Those goes doubly so for the fiddly bits like kernel APIC emulation and virtio. - But it may not be legally safe to read the KVM source code and reimplement it in such detail for a GPL-incompatible target kernel. (It might be seen as a form of translation). (We've already seen someone implementing a virtio driver on the list who was worried about GPL implications). So how can anyone implement a KVM-compatible replacement for KQEMU on other host platforms? -- Jamie