From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDCvJ-0003iT-Tt for qemu-devel@nongnu.org; Sun, 07 Jun 2009 03:36:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDCvE-0003fj-U7 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 03:36:09 -0400 Received: from [199.232.76.173] (port=42278 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDCvE-0003fO-MM for qemu-devel@nongnu.org; Sun, 07 Jun 2009 03:36:04 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:58851) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDCvE-00076k-1v for qemu-devel@nongnu.org; Sun, 07 Jun 2009 03:36:04 -0400 Message-ID: <4A2B6DD8.3090104@web.de> Date: Sun, 07 Jun 2009 09:35:52 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4A26F1E3.1040509@codemonkey.ws> <4A2A92FE.2010700@redhat.com> <4A2AA10B.6060401@web.de> <4A2B49C0.8020703@redhat.com> In-Reply-To: <4A2B49C0.8020703@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E27A1A5CBDF7505FDC80DEB" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: POLL: Why do you use kqemu? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E27A1A5CBDF7505FDC80DEB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >>> Maybe the backwards compatibility features should be ported to QEMU? >>> For example, is there a workaround for >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS >>> ? >>> =20 >> >> Given that we have always-up-to-date kvm-kmod packages with support do= wn >> to reasonable kernel versions, I would prefer to keep upstream clean >> from old workarounds. They should only be needed for issues found very= >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in= >> the future. >> =20 >=20 > Requiring the latest up-to-date modules is pushing the problem to the > users. Sometimes there is no choice, but when there is, the > implementation that cares about its uses prefer unclean code and > functionality over perfection and brokenness. Let's make it more concrete: By the time upstream is as well tested, feature-rich and with comparable performance as qemu-kvm, its current baseline requirement (2.6.29 due to KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most normal users. Until then they are better off with qemu-kvm anyway. So all I wanted to express is that I see no point in merging workarounds upstream that hardly anyone will need but that restrict non-kvm code in upstream. Basically I have the current line along KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in mind. Anything older should be skipped when merging upstream. And unless something more problematic comes along (rather unlikely), 2.6.29 or compatible kvm-kmod is a reasonable minimum requirement for the long term= =2E Jan --------------enig6E27A1A5CBDF7505FDC80DEB 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 iEYEARECAAYFAkorbdwACgkQniDOoMHTA+nCJgCfQahnDubzF6Rl5KdGuRCBzYHE IEUAn00hkSvKZEfcZMj9tL1Q6LlzhGZO =SXMu -----END PGP SIGNATURE----- --------------enig6E27A1A5CBDF7505FDC80DEB--