From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDEdI-0000ON-Eb for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:25:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDEdD-0000HS-7T for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:25:39 -0400 Received: from [199.232.76.173] (port=58795 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDEdC-0000H4-Sy for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:25:35 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:38040) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDEdC-0000m7-Ak for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:25:34 -0400 Message-ID: <4A2B8787.5080603@web.de> Date: Sun, 07 Jun 2009 11:25:27 +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> <4A2B6DD8.3090104@web.de> <4A2B7F5E.8050807@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88398C44A61DCCF322593DF0" 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: Blue Swirl Cc: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Avi Kivity , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88398C44A61DCCF322593DF0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: > On 6/7/09, Jan Kiszka wrote: >> Blue Swirl wrote: >> > On 6/7/09, Jan Kiszka wrote: >> >> Avi Kivity wrote: >> >> > Jan Kiszka wrote: >> >> >>> Maybe the backwards compatibility features should be ported t= o QEMU? >> >> >>> For example, is there a workaround for >> >> >>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_W= ORKS >> >> >>> ? >> >> >>> >> >> >> >> >> >> Given that we have always-up-to-date kvm-kmod packages with su= pport down >> >> >> to reasonable kernel versions, I would prefer to keep upstream= clean >> >> >> from old workarounds. They should only be needed for issues fo= und very >> >> >> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be = found in >> >> >> the future. >> >> >> >> >> > >> >> > 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 an= d >> >> > functionality over perfection and brokenness. >> >> >> >> >> >> Let's make it more concrete: >> >> >> >> By the time upstream is as well tested, feature-rich and with com= parable >> >> 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= =2E >> >> >> >> So all I wanted to express is that I see no point in merging work= arounds >> >> upstream that hardly anyone will need but that restrict non-kvm c= ode in >> >> upstream. Basically I have the current line along >> >> KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot managemen= t 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 l= ong term. >> > >> > I pulled qemu-kvm and it looks to me that >> > KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions >> > kvm_destroy_memory_region_works() and must_use_aliases_*() are only= >> > used in very few places. Do I miss something, how can this be of an= y >> > restriction? >> >> >> Check e.g the diff of hw/vga.c against upstream: All the magic dances >> there are required as qemu-kvm tracking cpu_register_physical_memory = and >> kvm_log_start cannot cope with all the patterns normal qemu code come= s >> up with. Upstream slot management now provides the same features >> (including migration) like qemu-kvm, it just does not deal with legac= y, >> thus it does not have to patch qemu code (rather, we were able to rem= ove >> some already merged hooks - vga_dirty_log_stop). >=20 > Still not very restrictive, all this could be encapsulated with for > example macro COMPAT_NO_DMRW which could be removed when we don't care > anymore. Next? Really, it's not worth the maintenance pain: Every new device emulation code that wants to be KVM-legacy-compatible would need to be written like that. And unless you are familiar with the slot management internals, the "correct" pattern will not be obvious. I've just finished a patch for configure and for the runtime code to tell the user what the maturer alternatives are. Will send it out in a minute. Jan --------------enig88398C44A61DCCF322593DF0 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 iEYEARECAAYFAkorh4oACgkQniDOoMHTA+mgBACdEKk6Zi91PviwiIcjKOv+MbUN yn4AnjJzeBn+l7HW8RhpkaabjJHQJuPk =kcn3 -----END PGP SIGNATURE----- --------------enig88398C44A61DCCF322593DF0--