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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]