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
