[Qemu-ppc] [RFC 0/2] cpu-add compatibility for query-hotpluggable-cpus implementations

[David Gibson]

I'm not entirely sure if this is a good idea, and if it is whether
this is a good approach to it.  But I'd like to discuss it and see if
anyone has better ideas.

As you may know we've hit a bunch of complications with cpu_index
which will impose some limitations with what we can do with the new
query-hotpluggable-cpus interface, and we've run out of time to
address these in qemu-2.7.

At the same time we're hitting complications with the fact that the
new qemu interface requires a new libvirt interface to use properly,
and that has follow on effects further up the stack.

Together this means a bunch more delays to having usable CPU hotplug
on Power for downstream users, which is unfortunate.

This is an attempt to get something limited working in a shorter time
frame, by implementing the old cpu-add interface in terms of the new
interface.  Obviously this can't fully exploit the new interface's
capabilities, but you can do basic in-order cpu hotplug without removal.

To make this work, I need to broaden the semantics of cpu-add: it will
a single entry from query-hotpluggable-cpus, which means it may add
multiple vcpus, which the x86 implementation did not previously do.
I'm not sure if the intended semantics of cpu-add were ever defined
well enough to say if this is "wrong" or not.

Because of this, I suspect libvirt will still need some work, but I'm
hoping it might be less that the full new API implementation.

David Gibson (2):
  spapr: Reverse order of hotpluggable cpus list
  qmp: Implement cpu-add in terms of query-hotpluggable-cpus when
    available

 hw/ppc/spapr.c |  2 +-
 qmp.c          | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 1 deletion(-)

-- 
2.7.4