Re: [Qemu-devel] [PATCH v2 1/5] QMP: add query-hotpluggable-cpus

[Eric Blake <eblake@redhat.com>]

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

On 03/08/2016 06:18 AM, Igor Mammedov wrote:
> it will allow mgmt to query present and possible to hotplug

maybe s/possible to hotplug/hotpluggable/

> CPU objects, it is required from a target platform that
> wish to support command to implement
>  qmp_query_hotpluggable_cpus()
> functioni, which will return a list of possible CPU objects

s/functioni/function/

> with options that would be needed for hotplugging possible
> CPU objects.
> 
> For RFC there are:
> 'type': 'str' - OQOM CPU object type for usage with device_add

s/OQOM/QOM/ ?

> 
> 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 inspect whatever object/abstraction

s/inspect/to inspect/

> the target platform considers as CPU object.
> 
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
>  qapi-schema.json                    | 39 +++++++++++++++++++++++++++++++++++++
>  qmp-commands.hx                     | 34 ++++++++++++++++++++++++++++++++
>  stubs/Makefile.objs                 |  1 +
>  stubs/qmp_query_hotpluggable_cpus.c |  9 +++++++++
>  4 files changed, 83 insertions(+)
>  create mode 100644 stubs/qmp_query_hotpluggable_cpus.c
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 362c9d8..c59840d 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -4122,3 +4122,42 @@
>  ##
>  { 'enum': 'ReplayMode',
>    'data': [ 'none', 'record', 'play' ] }
> +
> +##
> +# CpuInstanceProps

Worth spelling this as Properties instead of abbreviating?  But the type
names aren't ABI (they don't affect introspection), so I'm not insisting.

> +#
> +# @node: NUMA node ID the CPU belongs to, optional

Elsewhere, we use the tag '#optional', not 'optional, so that when we
finally get Marc-Andre's patches for auto-generating docs, they will
have a sane string to search for.

> +# @socket: socket number within node/board the CPU belongs to, optional
> +# @core: core number within socket the CPU belongs to, optional
> +# @thread: thread number within core the CPU belongs to, optional
> +#
> +# Since: 2.7

Ah, so you've already conceded that this is too much of a feature too
late past 2.6 soft freeze.

> +{ 'struct': 'CpuInstanceProps',
> +  'data': { '*node': 'int',
> +            '*socket': 'int',
> +            '*core': 'int',
> +            '*thread': 'int'
> +  }
> +}
> +
> +##
> +# @HotpluggableCPU
> +#
> +# @type: CPU object type for usage with device_add command
> +# @qom-path: link to existing CPU object if CPU is present or
> +#            omitted if CPU is not present.

Missing '#optional' marker.

> +# @props: list of properties to be used for hotplugging CPU

Is this always going to be present, or should it have an '#optional'
marker?  Right now, it could be present but content-free, as in
"props":{}, if that would help users realize that the particular CPU has
no further tuning available for hotplug purposes.

> +#
> +# Since: 2.7
> +{ 'struct': 'HotpluggableCPU',
> +  'data': { 'type': 'str',
> +            '*qom-path': 'str',
> +            '*props': 'CpuInstanceProps'
> +          }
> +}
> +
> +##
> +# @query-hotpluggable-cpus
> +#
> +# Since: 2.6

Inconsistent - how can the command be 2.6 if the structures it uses are 2.7?

> +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }

> +Example for x86 target started with -smp 2,sockets=2,cores=1,threads=3,maxcpus=6:
> +
> +-> { "execute": "query-hotpluggable-cpus" }
> +<- {"return": [
> +     {"core": 0, "socket": 1, "thread": 2}, "type": "qemu64-x86_64-cpu"},

Not valid JSON.  You probably meant:

{"return": [
  { "props": {"core"...2}, "type"...},

> +     {"core": 0, "socket": 0, "thread": 1}, "type": "qemu64-x86_64-cpu", "qom-path": "/machine/unattached/device[3]"},

It's okay to line-wrap, to keep 80-column lines.

> +     {"core": 0, "socket": 0, "thread": 0}, "type": "qemu64-x86_64-cpu", "qom-path": "/machine/unattached/device[0]"}
> +   ]}'
> +
> +Example for SPAPR target started with -smp 2,cores=2,maxcpus=4:
> +
> +-> { "execute": "query-hotpluggable-cpus" }
> +<- {"return": [
> +     {"core": 1 }, "type": "spapr-cpu-core"},

Again, not valid JSON.

But useful examples.

-- 
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: 604 bytes --]