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.