On Mon, 11 Apr 2016 11:14:27 -0500
Michael Roth <mdr...@linux.vnet.ibm.com> wrote:
> Quoting Igor Mammedov (2016-04-08 06:29:55)
> > it will allow mgmt to query present and hotpluggable
> > CPU objects, it is required from a target platform that
> > wish to support command to implement and set
> > MachineClass.query_hotpluggable_cpus
> > callback, which will return a list of possible CPU objects
> > with options that would be needed for hotplugging possible
> > CPU objects.
> >
> > There are:
> > 'type': 'str' - QOM CPU object type for usage with device_add
> > 'vcpus-count': 'int' - number of logical VCPU threads per
> > CPU object (mgmt needs to know)
> >
> > and a set of optional fields that are to used for hotplugging
> > a CPU objects and would allows mgmt tools to know what/where
> > it could be hotplugged;
> > [node],[socket],[core],[thread]
> >
> > For present CPUs there is a 'qom-path' field which
> > would allow mgmt to inspect whatever object/abstraction
> > the target platform considers as CPU object.
> >
> > Signed-off-by: Igor Mammedov <imamm...@redhat.com>
> > ---
> > v6:
> > - fix style issues in qapi-schema and qmp-commands,
> > Eric Blake <ebl...@redhat.com>
> > - rebase on top current master (query-gic-capabilities conflict)
> > v5:
> > - fix s390 build failure:
> > undefined reference to `qmp_query_hotpluggable_cpus'
> > v4:
> > - add MachineClass method to get CPU object list
> > v3:
> > - add 'vcpus-count' field, pkre...@redhat.com
> > - s/CpuInstanceProps/CpuInstanceProperties/
> > - use '#optional' marker
> > - make "props" as always present even if it's empty
> > - fix JSON examples
> > - fix minor typos
> >
> > query_fixup
> > ---
> > include/hw/boards.h | 5 +++++
> > monitor.c | 13 +++++++++++++
> > qapi-schema.json | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> > qmp-commands.hx | 41 +++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 105 insertions(+)
> >
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index aad5f2a..c122a70 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -81,6 +81,10 @@ typedef struct {
> > * Returns an array of @CPUArchId architecture-dependent CPU IDs
> > * which includes CPU IDs for present and possible to hotplug CPUs.
> > * Caller is responsible for freeing returned list.
> > + * @query_hotpluggable_cpus:
> > + * Returns a @HotpluggableCPUList, which describes CPUs objects which
> > + * could be added with -device/device_add.
> > + * Caller is responsible for freeing returned list.
> > */
> > struct MachineClass {
> > /*< private >*/
> > @@ -123,6 +127,7 @@ struct MachineClass {
> > DeviceState *dev);
> > unsigned (*cpu_index_to_socket_id)(unsigned cpu_index);
> > CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
> > + HotpluggableCPUList *(*query_hotpluggable_cpus)(MachineState *machine);
> > };
> >
> > /**
> > diff --git a/monitor.c b/monitor.c
> > index d1c1930..b469225 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -4267,3 +4267,16 @@ GICCapabilityList *qmp_query_gic_capabilities(Error
> > **errp)
> > return NULL;
> > }
> > #endif
> > +
> > +HotpluggableCPUList *qmp_query_hotpluggable_cpus(Error **errp)
> > +{
> > + MachineState *ms = MACHINE(qdev_get_machine());
> > + MachineClass *mc = MACHINE_GET_CLASS(ms);
> > +
> > + if (!mc->query_hotpluggable_cpus) {
> > + error_setg(errp, QERR_FEATURE_DISABLED, "query-hotpluggable-cpus");
> > + return NULL;
> > + }
> > +
> > + return mc->query_hotpluggable_cpus(ms);
> > +}
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 54634c4..4d1d71d 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -4178,3 +4178,49 @@
> > # Since: 2.6
> > ##
> > { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
> > +
> > +##
> > +# CpuInstanceProperties
> > +#
> > +# @node: #optional NUMA node ID the CPU belongs to
> > +# @socket: #optional socket number within node/board the CPU belongs to
> > +# @core: #optional core number within socket the CPU belongs to
> > +# @thread: #optional thread number within core the CPU belongs to
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'struct': 'CpuInstanceProperties',
> > + 'data': { '*node': 'int',
> > + '*socket': 'int',
> > + '*core': 'int',
> > + '*thread': 'int'
> > + }
> > +}
> > +
> > +##
> > +# @HotpluggableCPU
> > +#
> > +# @type: CPU object type for usage with device_add command
> > +# @props: list of properties to be used for hotplugging CPU
> > +# @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides
> > +# @qom-path: #optional link to existing CPU object if CPU is present or
> > +# omitted if CPU is not present.
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'struct': 'HotpluggableCPU',
> > + 'data': { 'type': 'str',
> > + 'vcpus-count': 'int',
> > + 'props': 'CpuInstanceProperties',
> > + '*qom-path': 'str'
> > + }
> > +}
> > +
> > +##
> > +# @query-hotpluggable-cpus
> > +#
> > +# Returns: a list of HotpluggableCPU objects.
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> > index de896a5..96f4454 100644
> > --- a/qmp-commands.hx
> > +++ b/qmp-commands.hx
> > @@ -4880,3 +4880,44 @@ Example:
> > { "version": 3, "emulated": false, "kernel": true } ] }
> >
> > EQMP
> > +
> > + {
> > + .name = "query-hotpluggable-cpus",
> > + .args_type = "",
> > + .mhandler.cmd_new = qmp_marshal_query_hotpluggable_cpus,
> > + },
> > +
> > +SQMP
> > +Show existing/possible CPUs
> > +---------------------------
> > +
> > +Arguments: None.
> > +
> > +Example for x86 target started with -smp
> > 2,sockets=2,cores=1,threads=3,maxcpus=6:
> > +
> > +-> { "execute": "query-hotpluggable-cpus" }
> > +<- {"return": [
> > + { "props": { "core": 0, "socket": 1, "thread": 2},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > + { "props": { "core": 0, "socket": 1, "thread": 1},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > + { "props": { "core": 0, "socket": 1, "thread": 0},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > + { "props": { "core": 0, "socket": 0, "thread": 2},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > + { "props": { "core": 0, "socket": 0, "thread": 1},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
> > + "qom-path": "/machine/unattached/device[3]"},
> > + { "props": { "core": 0, "socket": 0, "thread": 0},
> > + "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
> > + "qom-path": "/machine/unattached/device[0]"}
> > + ]}'
>
> These examples kind of imply the granularity of "props" field has some
> relation to the granularity afforded by -smp. But IIUC what really
> matters is the granularity of the object type specified by "type".
props doesn't imply granularity, it's just a list properties for
instantiating a particular instance of CPU object.
However mgmt could be taught to understand some props elements
for pining purposes.
> If so, it's also confusing in the sense that the output above likely
> would look different if x86 implements device_add functionality in
> the form of socket-level objects, which AFAIK is stil the plan
> there?
For x86 I'm planning to submit patches with thread level cpu hotplug as
it matches the old one and allows to replace old hotplug with a new
without breaking anything migration wise, we won't even have to keep
compat code to make it work.
> Perhaps we should stick with pseries as the one concrete example,
> then for other examples provide 'theoretical' examples that touch
> on the granularity of the hotpluggable object and how that factors
> into what management would expect in the returned output. Sort of
> as a reference for future implementers.
>
> Then we can add a concrete x86 example when that's in.
Ok, I'll drop x86 example from this patch and add it when x86
patches are posted.
> > +
> > +Example for SPAPR target started with -smp 2,cores=2,maxcpus=4:
> > +
> > +-> { "execute": "query-hotpluggable-cpus" }
> > +<- {"return": [
> > + { "props": { "core": 1 }, "type": "spapr-cpu-core", "vcpus-count": 1
> > },
> > + { "props": { "core": 0 }, "type": "spapr-cpu-core", "vcpus-count": 1,
> > + "qom-path": "/machine/unattached/device[0]"}
> > + ]}'
> > --
> > 1.8.3.1
> >
>
