Re: [Qemu-devel] [PATCH for-2.7 v6 1/2] QMP: add query-hotpluggable-cpus

[Michael Roth]

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 <address@hidden>
> ---
> v6:
>  - fix style issues in qapi-schema and qmp-commands,
>    Eric Blake <address@hidden>
>  - 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, address@hidden
>  - 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".

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?

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.

> +
> +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
>