From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAnCM-00055c-It for qemu-devel@nongnu.org; Sun, 31 May 2009 11:43:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAnCH-0004vC-NY for qemu-devel@nongnu.org; Sun, 31 May 2009 11:43:46 -0400 Received: from [199.232.76.173] (port=50808 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAnCH-0004us-G0 for qemu-devel@nongnu.org; Sun, 31 May 2009 11:43:41 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:33759) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAnCG-0005dC-KX for qemu-devel@nongnu.org; Sun, 31 May 2009 11:43:41 -0400 Message-ID: <4A22A5A7.9060504@web.de> Date: Sun, 31 May 2009 17:43:35 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1243551838-1980-1-git-send-email-glommer@redhat.com> <4A1F77C0.9050407@codemonkey.ws> <4A1FA616.7040402@siemens.com> <20090531145358.GA25422@shareable.org> In-Reply-To: <20090531145358.GA25422@shareable.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3579CC2CD5776FFE5DF67A68" Sender: jan.kiszka@web.de 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: Jamie Lokier Cc: Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3579CC2CD5776FFE5DF67A68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > 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. >=20 > Only if your looking at the virtualisation market. > As far as I know >=20 > - 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 VIA will soon (or already started to?) deliver working VT-x support with their CPUs. As HVM also became a marketing tag, probably only very resource-restricted systems will soon be sold without it, and on those kqemu is no fun anyway (at best only for very very resource-restricted guests). >=20 > 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. >=20 > That's only 2 out 7 PC types I have ready access to which have HVM. >=20 > 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. >=20 > But it will make QEMU a less useful tool for some. >=20 > 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 develope= rs. That wouldn't change any of the technical problems it has. If we had no broadly available HVM support today, /then/ you could bet that a kqemu rewrite would be on the way, either driven by hobbyists or commercial use= =2E >=20 > 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. >=20 > Or ideally, to replace it with something KVM-compatible, as that would > reduce the maintenance burden. >=20 > For replacing KQEMU on Linux, that's realistic I think. Either it's > done, or there's no maintainer anyway. >=20 > But for non-Linux hosts I see a non-technical problem: >=20 > - Without API documentation you have to read the KVM source code. >=20 > - Those goes doubly so for the fiddly bits like kernel APIC > emulation and virtio. >=20 > - 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= =2E > (It might be seen as a form of translation). For that case (and Avi still haven written the API docs): Take (at least) two people, one reading the source and writing that docs and the others reading the docs and re-implementing a backend under whatever license they want. >=20 > (We've already seen someone implementing a virtio driver on the list > who was worried about GPL implications). >=20 > So how can anyone implement a KVM-compatible replacement for KQEMU on > other host platforms? It's not that easy. The major design challenge is that kqemu is running in cooperative mode with TCG, using the latter to handle cases the in-kernel monitor cannot (or doesn't want to due to performance/latency impact). Kvm does not need this as its guest-host switches are less frequent and less heavy. We played with an approach to drive kqemu into the same direction (patch and trap those un-virtualizable instructions) and reduced the exists. The next step would have been to adopt kvm's I/O handling philosophy (or even code), but problems of our approach on heavily segmented guests stopped the effort. There might have been another issue of the patch&trap approach: self-checking guests (you can't easily hide the binary changes from the guest). Then the only option would have been to translate the guest code like TCG already does, but optimized for host =3D guest =3D x86. But that= effort would have been enormous and simply no longer worth it. That said, I think the best one can do for kqemu remaining a qemu citizen is to move it out of the way the latter wants to take, e.g. eliminating the reason for /* address in the RAM (different from a physical address) */ #ifdef CONFIG_KQEMU /* FIXME: This is wrong. */ typedef uint32_t ram_addr_t; #else typedef unsigned long ram_addr_t; #endif or reducing the impact of its hooks. One could, as another example, push the hooks in cpu_in/out to helpers injected into the TCG output. Jan --------------enig3579CC2CD5776FFE5DF67A68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkoipaoACgkQniDOoMHTA+klqACfbQnemAQaFhfameQNKjBB7VMM JnIAnj+OH8CJPDcVT1wOxQ+BcgBubfKt =7vJf -----END PGP SIGNATURE----- --------------enig3579CC2CD5776FFE5DF67A68--