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

[Alexander Graf <agraf@suse.de>]

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