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

[Igor Mammedov]

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:  
> > > 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.  
> 
> 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.

> 
> Regards,
> Bharata.
> 
>