From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYWzH-0004jK-Dp for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:39:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYWzC-0001yc-Bu for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:39:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYWzC-0001yR-3k for qemu-devel@nongnu.org; Fri, 11 Apr 2014 04:38:58 -0400 Date: Fri, 11 Apr 2014 09:37:48 +0100 From: "Daniel P. Berrange" Message-ID: <20140411083748.GA30229@redhat.com> References: <5346921A.2050705@redhat.com> <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de> <53469F8D.2040808@redhat.com> <5346A07B.9070608@suse.de> <5346B2A3.1080900@redhat.com> <87k3awqopq.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k3awqopq.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , =?utf-8?Q?J=C3=A1n?= Tomko , "Michael S. Tsirkin" , Michael Roth , QEMU Developers , Alexander Graf , Anthony Liguori , Paolo Bonzini , Andreas =?utf-8?Q?F=C3=A4rber?= On Fri, Apr 11, 2014 at 10:01:37AM +0200, Markus Armbruster wrote: > Eric Blake writes: > > > 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. > > I understand why libvirt needs to know how PCI buses a named. I'm not > sure a "multibus?" flag can cover more than the present problem, though. > > Doesn't libvirt need to know how *any* kind of bus is named? Yes, you are right - in theory libvirt needs to know the name of any default bus which is pre-created due to the machine type. For ones we create ourselvs, obviously we already have ability to choose the name. Now in practice, I believe the default PCI bus is the only one that actually causes us trouble today. USB buses are all fully created by libvirt self. The default SCSI/IDE/etc disk buses are not a problem since we just refer to them by bus number. While there are other buses on non-x86 our support for those in libvirt pretty much doesn't exist so we don't currently hit that. > Would it suffice if libvirt could introspect the names of all available > buses? And perhaps control the names of all buses it creates itself? 'info qtree' provides a way to introspect that, but of course we probe capabilities using '-M none' so we case use that, and we don't particularly want to have to invoke QEMU many more times to probe the machine types. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|