On Tue, Mar 08, 2016 at 09:46:58AM -0700, Eric Blake wrote:
> 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.
I think it should be always present, even if it can be empty.
> > +#
> > +# 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.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
