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 <imamm...@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
signature.asc
Description: OpenPGP digital signature
