Re: [Qemu-devel] [PATCH 16/16] add cpu-add qmp command and implement CPU hot-add for target-i386

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On 04/16/2013 02:04 PM, Igor Mammedov wrote:

>>> +#
>>> +# Returns: Nothing on success
>>> +##
>>> +{ 'command': 'cpu-add', 'data': {'id': 'int'} }
>>> +
>>
>> Should be usable from libvirt's perspective, even if hot-plugging more
>> than one cpu requires more than one QMP call.  Do we have a counterpart
>> QMP call to easily determine which cpu ids can still be hotplugged?  If
>> so, should we mention that in the documentation of this command?
> We do not have it yet. Despite interface allowing to plug arbitrary CPU,
> libvirt shouldn't do it in order not to break migration support. Since
> migration target should be started with all CPU from source (including
> hot-plugged ones). And current command line doesn't have means for this.
> 
> I'd propose do implement in libvirt something like:
> 
> hotplug_id = current_cpu_count
> { "execute": "cpu-add", "arguments": { "id": hotplug_id } }
> current_cpu_count += 1
> 
> until arbitrary CPU hotplug and interface for enumerating possible CPUs
> settle down.

Yes, that's pretty much how libvirt already handles hotplug for xen:
libvirt currently maintains its own count of plugged cpus, and
hot[un]plugs the next id so that the online cpus are always contiguous
ids starting from 0.  We are discussing on the libvirt lists ways of
improving libvirt API to expose hotplug of arbitrary ids (after all, a
4-cpu bare metal machine can hotunplug cpu 1 while still leaving 2 and 3
online) - but that can come later, perhaps as qemu 1.6 gains better
support for NUMA layout with better control of what ids should be used.

> 
> There was a proposal for enumerating possible CPUs in previous version,
> but it was target specific, and I was convinced to drop it for 1.5 and
> aim for generic way to expose this information later.
> http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg02286.html
> Opinion from libvirt POV would be nice to have though.

Agreed that deferring more powerful id enumeration for a later patch
series is fine, and shouldn't hold up getting basic hotplug into 1.5.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]