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

[David Gibson <david@gibson.dropbear.id.au>]

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

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]