From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGVV-0001cv-HG for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:03:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYGVP-0003Pn-N7 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:03:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGVP-0003P6-Eg for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:03:07 -0400 Message-ID: <5346B2A3.1080900@redhat.com> Date: Thu, 10 Apr 2014 09:02:59 -0600 From: Eric Blake MIME-Version: 1.0 References: <5346921A.2050705@redhat.com> <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de> <53469F8D.2040808@redhat.com> <5346A07B.9070608@suse.de> In-Reply-To: <5346A07B.9070608@suse.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R59FarBf7pvW0QvSkfpfHQgrmOHi3oNVU" Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , =?UTF-8?B?SsOhbiBUb21rbw==?= Cc: Peter Maydell , "Michael S. Tsirkin" , QEMU Developers , Michael Roth , Anthony Liguori , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R59FarBf7pvW0QvSkfpfHQgrmOHi3oNVU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2014 07:45 AM, Alexander Graf wrote: >>>> >>>> Is this something that can be quickly fixed (perhaps by reverting th= e >>>> PPC patch until a more complete solution is ready), and if so, is it= >>>> worth doing for 2.0 proper, rather than waiting for 2.0.1? >>> Which way works better for you? I'd be perfectly fine with reverting >>> the patch. Libvirt is the only reason that path is there in the first= >>> place. >>> >> If I read the git history correctly, there were two patches changing >> pci bus >> names for ppc in this release, not just one: >=20 > The main difference is that the g3beige and mac99 targets are not > supported by libvirt FWIW :). >=20 > But I agree that this is messy. And a pretty intrusive change pretty > late in the game. Eric, how hard would a special case for this be in > libvirt code? Are we talking about a 2 line patch? Here's the current libvirt patch proposal: https://www.redhat.com/archives/libvir-list/2014-April/msg00444.html a bit more than a 2-line patch: src/qemu/qemu_capabilities.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) We already have to special case on machine type for all qemu older than the point where we introduce sane names; but it would be nicer if that were the ONLY special casing (rather than having the _additional_ special casing that for 2.0, ppc, but not other machines, behave differently). The IDEAL situation is to have a QMP command that can query which naming convention is in use for a given machine; even if such command is not introduced until 2.1, the logic will look something like: if (probe exists) use results of probe to set QEMU_CAPS_PCI_MULTIBUS else if (machine with sane handling) assume QEMU_CAPS_PCI_MULTIBUS else assume no QEMU_CAPS_PCI_MULTIBUS and is completely independent of version checks, which means it is portable even to downstream backports where the version number is not as large as upstream, without any modification when backporting this hunk. Without a QMP command to probe it, but with all machines switched to sane naming in the same version of qemu, the logic looks more like: if (x86 or 686) assume QEMU_CAPS_PCI_MULTIBUS else if (version check) // evil for downstream backports set QEMU_CAPS_PCI_MULTIBUS if new enough which looks shorter, but plays havoc with downstream ports, which now have to patch the version check to play nicely with downstream. Furthermore, if qemu 2.0 is released with PPC being a special case, the logic expands: if (x86 or 686) assume QEMU_CAPS_PCI_MULTIBUS else if (PPC) if (version check for 2.0) // evil for downstream set QEMU_CAPS_PCI_MULTIBUS else if (version check for 2.1) // evil for downstream set QEMU_CAPS_PCI_MULTIBUS and now there are two version checks instead of one that downstream has to worry about. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --R59FarBf7pvW0QvSkfpfHQgrmOHi3oNVU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTRrKjAAoJEKeha0olJ0NqLbUIAJbURuMayWexyP8oCjoiE4XQ jNHsa/RiTg4gYpFkbGQ+MrwoDub6qkKEkJEuDCEuN+wNC6nTFiSEG1rcQulXoQHc tQm4UczBnZiMX+O6Z9QHrVCGmgKdlovNxnn1MrqEWALiVjTB1nXLhA2vMtLIAy2M uNR2OzTxE3TWGIirL/7GfM3FVBoyhW7HCPnl/dE4PZ2+DofIDash66TpMaXHj41c +SX2rwGcA8CgaW6tLtGLEsjdSmqAaQ8mkd4p4XyaMMDP97R4+PFjwtjPBXNf3nG5 fj47sUg34zvtwFoJhFndzd7SgRHvzEbhuOJXa8KAhWbIBG9KfXWgvHcm9nP7xyU= =OcsH -----END PGP SIGNATURE----- --R59FarBf7pvW0QvSkfpfHQgrmOHi3oNVU--