Re: [Qemu-devel] Should we have a 2.0-rc3 ?

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Apr 11, 2014 at 10:01:37AM +0200, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> 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 :|