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

[Peter Krempa]

On Tue, Jul 19, 2016 at 09:51:00 +0200, Igor Mammedov wrote:
> On Tue, 19 Jul 2016 09:32:08 +0530
> Bharata B Rao <address@hidden> wrote:
> > On Mon, Jul 18, 2016 at 04:01:18PM +0200, Peter Krempa wrote:
> > > On Mon, Jul 18, 2016 at 19:19:20 +1000, David Gibson wrote:  

[...]

> > Is this compatability handling any different from how libvirt already
> > handles memory specified by -m and by -device pc-dimm ? Isn't cpus specified
> > by -smp and by -device kind of comparable to the memory case ?
> it is not,
> when one hotplugs pc-dimm, then on target side -m keeps the same values as
> on source, the only change to target CLI is added -device for hotplugged 
> memory.
> Behavior is basically the same as with any other device that could be 
> hotplugged
> and migrated.
> 
> In cpu-add case, semantics are different. CLI option -smp X on source becomes
> -smp (x+#hotplugge_cpus) since there were not means to create CPUs using 
> -device
> and code that is creating initial CPUs would create additional CPUs that were 
> added
> on source. Hence inability to add any random CPU (only the next free) so that 
> target
> could reproduce setup.
> 
> After enabling -device/device_add for cpus we can ditch cpu-add in favor of
> usual -device semantics where -smp X on target stays the same as on source
> and we manipulate only with -device for hotplugged cpus.
> 
> 
> I'm not sure that enabling cpu-add for spapr would bring simplify life of
> libvirt.

Agreed. As the device_add interface looks very alike this one it makes
little sense to add this interface (given that qemu will be able to
provide enough information to allow selecting the correct entry of
query-hotpluggable-cpus to add in sequence).