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

[Markus Armbruster]

Eric Blake <address@hidden> 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?

Would it suffice if libvirt could introspect the names of all available
buses?  And perhaps control the names of all buses it creates itself?

[...]