Re: [Qemu-ppc] [RFC 2/2] qmp: Implement cpu-add in terms of query-hotpluggable-cpus when available

[Peter Krempa]

On Mon, Jul 18, 2016 at 19:19:20 +1000, David Gibson wrote:
> We've recently added a new device_add based cpu hotplug
> implementation, with the spapr machine type being the first user.  In
> order to overcome the limitations of the old cpu_add interface, it
> works very differently.  That's going to require a new interface in
> libvirt to properly use the new interface in qemu, which will in turn
> require work further up the stack to make use of it.
> 
> While that's certainly necessary in the long run, it would be nice if
> we could have at least something working with the old cpu_add
> interface.  This patch is an attempt to do so.
> 
> This patch implements cpu-add on machines which don't support it
> directly but which do support the query-hotpluggable-cpus interface.
> Essentially,
>       cpu-add <n>
> will be treated as a device_add of the n-th entry in the list provided
> by query-hotpluggable-cpus.

Does this have the same implications when libvirt will need to re-create
a matching qemu process for migration target? (Will we need to specify
-device cpu,... for every CPU 'entity' added this way on the command
line?)

When using cpu_add libvirt recreates the process by just increasing the
number of active cpus specified via '-smp'.

In case where libvirt would need to add the -device entries this would
create just problems with compatibility. Libvirt needs to add XML
specification of the cpus in order to allow tracking which cpus need to
be added on the commandline.

> This means that on spapr cpu-add will add a whole core, not a single
> vcpu as on x86. That's arguably cheating on the cpu-add semantics, but
> AFAICT those were never terribly well defined anyway.

Peter