From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGsn-0005Hg-9K for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:27:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYGsf-0003PZ-PQ for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:27:17 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43532 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYGsf-0003PS-E1 for qemu-devel@nongnu.org; Thu, 10 Apr 2014 11:27:09 -0400 Message-ID: <5346B84B.4030506@suse.de> Date: Thu, 10 Apr 2014 17:27:07 +0200 From: Alexander Graf MIME-Version: 1.0 References: <5346921A.2050705@redhat.com> <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de> <53469F8D.2040808@redhat.com> <5346A07B.9070608@suse.de> <5346B2A3.1080900@redhat.com> In-Reply-To: <5346B2A3.1080900@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , =?UTF-8?B?SsOhbiBUb21rbw==?= Cc: Peter Maydell , "Michael S. Tsirkin" , QEMU Developers , Michael Roth , Anthony Liguori , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 10.04.14 17:02, Eric Blake wrote: > On 04/10/2014 07:45 AM, Alexander Graf wrote: > >>>>> Is this something that can be quickly fixed (perhaps by reverting the >>>>> 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: >> The main difference is that the g3beige and mac99 targets are not >> supported by libvirt FWIW :). >> >> 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. Hrm, so what if we just ditch pre-2.0 support for PPC in libvirt? Then it'd become if (machine_type == pc || machine_type == pseries || machine_type == ppce500) assume QEMU_CAPS_PCI_MULTIBUS else ... and everyone is happy, no? :) (note that I prefer to base machine specific bits on machine types, but if you like to commonalize all PPC machines I'm fine with that too) Alex