| Message ID | 1457443095-213125-2-git-send-email-imammedo@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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. >
On Tue, 8 Mar 2016 09:46:58 -0700 Eric Blake <eblake@redhat.com> 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. Ok, I'll redo it as CpuInstanceProperties if no one objects. > > > +# > > +# @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. yep' it would be better if we commit command early in 2.7 dev cycle, so individual targets could push target specific patches on top. > > > +{ '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. Ok, I'll make it as always present. > > > +# > > +# 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. Thanks for review, the rest of comments I'll fix as you've suggested.
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 +# +# @node: NUMA node ID the CPU belongs to, optional +# @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 +{ '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. +# @props: list of properties to be used for hotplugging CPU +# +# Since: 2.7 +{ 'struct': 'HotpluggableCPU', + 'data': { 'type': 'str', + '*qom-path': 'str', + '*props': 'CpuInstanceProps' + } +} + +## +# @query-hotpluggable-cpus +# +# Since: 2.6 +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] } diff --git a/qmp-commands.hx b/qmp-commands.hx index b629673..39687ad 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -4853,3 +4853,37 @@ Example: {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 3840, "pop-vlan": 1, "id": 251658240} ]} + +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": [ + {"core": 0, "socket": 1, "thread": 2}, "type": "qemu64-x86_64-cpu"}, + {"core": 0, "socket": 1, "thread": 1}, "type": "qemu64-x86_64-cpu"}, + {"core": 0, "socket": 1, "thread": 0}, "type": "qemu64-x86_64-cpu"}, + {"core": 0, "socket": 0, "thread": 2}, "type": "qemu64-x86_64-cpu"}, + {"core": 0, "socket": 0, "thread": 1}, "type": "qemu64-x86_64-cpu", "qom-path": "/machine/unattached/device[3]"}, + {"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"}, + {"core": 0 }, "type": "spapr-cpu-core", "qom-path": "/machine/unattached/device[0]"} + ]}' diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs index e922de9..0011173 100644 --- a/stubs/Makefile.objs +++ b/stubs/Makefile.objs @@ -39,3 +39,4 @@ stub-obj-y += qmp_pc_dimm_device_list.o stub-obj-y += target-monitor-defs.o stub-obj-y += target-get-monitor-def.o stub-obj-y += vhost.o +stub-obj-y += qmp_query_hotpluggable_cpus.o diff --git a/stubs/qmp_query_hotpluggable_cpus.c b/stubs/qmp_query_hotpluggable_cpus.c new file mode 100644 index 0000000..21a75a3 --- /dev/null +++ b/stubs/qmp_query_hotpluggable_cpus.c @@ -0,0 +1,9 @@ +#include "qemu/osdep.h" +#include "qapi/qmp/qerror.h" +#include "qmp-commands.h" + +HotpluggableCPUList *qmp_query_hotpluggable_cpus(Error **errp) +{ + error_setg(errp, QERR_FEATURE_DISABLED, "query-hotpluggable-cpus"); + return NULL; +}
it will allow mgmt to query present and possible to hotplug 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 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 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 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