Re: [Qemu-devel] [PATCH for-2.7 v6 1/2] QMP: add query-hotpluggable-cpus

[Igor Mammedov]

On Mon, 11 Apr 2016 11:14:27 -0500
Michael Roth <address@hidden> wrote:

> Quoting Igor Mammedov (2016-04-08 06:29:55)
> > it will allow mgmt to query present and hotpluggable
> > CPU objects, it is required from a target platform that
> > wish to support command to implement and set
> >  MachineClass.query_hotpluggable_cpus
> > callback, which will return a list of possible CPU objects
> > with options that would be needed for hotplugging possible
> > CPU objects.
> > 
> > There are:
> > 'type': 'str' - QOM CPU object type for usage with device_add
> > 'vcpus-count': 'int' - number of logical VCPU threads per
> >                         CPU object (mgmt needs to know)
> > 
> > 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 to inspect whatever object/abstraction
> > the target platform considers as CPU object.
> > 
> > Signed-off-by: Igor Mammedov <address@hidden>
> > ---
> > v6:
> >  - fix style issues in qapi-schema and qmp-commands,
> >    Eric Blake <address@hidden>
> >  - rebase on top current master (query-gic-capabilities conflict)
> > v5:
> >  - fix s390 build failure:
> >     undefined reference to `qmp_query_hotpluggable_cpus'
> > v4:
> >  - add MachineClass method to get CPU object list
> > v3:
> >  - add 'vcpus-count' field, address@hidden
> >  - s/CpuInstanceProps/CpuInstanceProperties/
> >  - use '#optional' marker
> >  - make "props" as always present even if it's empty
> >  - fix JSON examples
> >  - fix minor typos
> > 
> > query_fixup
> > ---
> >  include/hw/boards.h |  5 +++++
> >  monitor.c           | 13 +++++++++++++
> >  qapi-schema.json    | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> >  qmp-commands.hx     | 41 +++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 105 insertions(+)
> > 
> > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > index aad5f2a..c122a70 100644
> > --- a/include/hw/boards.h
> > +++ b/include/hw/boards.h
> > @@ -81,6 +81,10 @@ typedef struct {
> >   *    Returns an array of @CPUArchId architecture-dependent CPU IDs
> >   *    which includes CPU IDs for present and possible to hotplug CPUs.
> >   *    Caller is responsible for freeing returned list.
> > + * @query_hotpluggable_cpus:
> > + *    Returns a @HotpluggableCPUList, which describes CPUs objects which
> > + *    could be added with -device/device_add.
> > + *    Caller is responsible for freeing returned list.
> >   */
> >  struct MachineClass {
> >      /*< private >*/
> > @@ -123,6 +127,7 @@ struct MachineClass {
> >                                             DeviceState *dev);
> >      unsigned (*cpu_index_to_socket_id)(unsigned cpu_index);
> >      CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
> > +    HotpluggableCPUList *(*query_hotpluggable_cpus)(MachineState *machine);
> >  };
> > 
> >  /**
> > diff --git a/monitor.c b/monitor.c
> > index d1c1930..b469225 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -4267,3 +4267,16 @@ GICCapabilityList *qmp_query_gic_capabilities(Error 
> > **errp)
> >      return NULL;
> >  }
> >  #endif
> > +
> > +HotpluggableCPUList *qmp_query_hotpluggable_cpus(Error **errp)
> > +{
> > +    MachineState *ms = MACHINE(qdev_get_machine());
> > +    MachineClass *mc = MACHINE_GET_CLASS(ms);
> > +
> > +    if (!mc->query_hotpluggable_cpus) {
> > +        error_setg(errp, QERR_FEATURE_DISABLED, "query-hotpluggable-cpus");
> > +        return NULL;
> > +    }
> > +
> > +    return mc->query_hotpluggable_cpus(ms);
> > +}
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 54634c4..4d1d71d 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -4178,3 +4178,49 @@
> >  # Since: 2.6
> >  ##
> >  { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
> > +
> > +##
> > +# CpuInstanceProperties
> > +#
> > +# @node: #optional NUMA node ID the CPU belongs to
> > +# @socket: #optional socket number within node/board the CPU belongs to
> > +# @core: #optional core number within socket the CPU belongs to
> > +# @thread: #optional thread number within core the CPU belongs to
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'struct': 'CpuInstanceProperties',
> > +  'data': { '*node': 'int',
> > +            '*socket': 'int',
> > +            '*core': 'int',
> > +            '*thread': 'int'
> > +  }
> > +}
> > +
> > +##
> > +# @HotpluggableCPU
> > +#
> > +# @type: CPU object type for usage with device_add command
> > +# @props: list of properties to be used for hotplugging CPU
> > +# @vcpus-count: number of logical VCPU threads @HotpluggableCPU provides
> > +# @qom-path: #optional link to existing CPU object if CPU is present or
> > +#            omitted if CPU is not present.
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'struct': 'HotpluggableCPU',
> > +  'data': { 'type': 'str',
> > +            'vcpus-count': 'int',
> > +            'props': 'CpuInstanceProperties',
> > +            '*qom-path': 'str'
> > +          }
> > +}
> > +
> > +##
> > +# @query-hotpluggable-cpus
> > +#
> > +# Returns: a list of HotpluggableCPU objects.
> > +#
> > +# Since: 2.7
> > +##
> > +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'] }
> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> > index de896a5..96f4454 100644
> > --- a/qmp-commands.hx
> > +++ b/qmp-commands.hx
> > @@ -4880,3 +4880,44 @@ Example:
> >                  { "version": 3, "emulated": false, "kernel": true } ] }
> > 
> >  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": [
> > +     { "props": { "core": 0, "socket": 1, "thread": 2},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > +     { "props": { "core": 0, "socket": 1, "thread": 1},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > +     { "props": { "core": 0, "socket": 1, "thread": 0},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > +     { "props": { "core": 0, "socket": 0, "thread": 2},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1 },
> > +     { "props": { "core": 0, "socket": 0, "thread": 1},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
> > +       "qom-path": "/machine/unattached/device[3]"},
> > +     { "props": { "core": 0, "socket": 0, "thread": 0},
> > +       "type": "qemu64-x86_64-cpu", "vcpus-count": 1,
> > +       "qom-path": "/machine/unattached/device[0]"}
> > +   ]}'  
> 
> These examples kind of imply the granularity of "props" field has some
> relation to the granularity afforded by -smp. But IIUC what really
> matters is the granularity of the object type specified by "type".
props doesn't imply granularity, it's just a list properties for
instantiating a particular instance of CPU object.
However mgmt could be taught to understand some props elements
for pining purposes.
 
> If so, it's also confusing in the sense that the output above likely
> would look different if x86 implements device_add functionality in
> the form of socket-level objects, which AFAIK is stil the plan
> there?
For x86 I'm planning to submit patches with thread level cpu hotplug as
it matches the old one and allows to replace old hotplug with a new
without breaking anything migration wise, we won't even have to keep
compat code to make it work.
 
> Perhaps we should stick with pseries as the one concrete example,
> then for other examples provide 'theoretical' examples that touch
> on the granularity of the hotpluggable object and how that factors
> into what management would expect in the returned output. Sort of
> as a reference for future implementers.
> 
> Then we can add a concrete x86 example when that's in.
Ok, I'll drop x86 example from this patch and add it when x86
patches are posted.
 
> > +
> > +Example for SPAPR target started with -smp 2,cores=2,maxcpus=4:
> > +
> > +-> { "execute": "query-hotpluggable-cpus" }
> > +<- {"return": [
> > +     { "props": { "core": 1 }, "type": "spapr-cpu-core", "vcpus-count": 1 
> > },
> > +     { "props": { "core": 0 }, "type": "spapr-cpu-core", "vcpus-count": 1,
> > +       "qom-path": "/machine/unattached/device[0]"}
> > +   ]}'
> > -- 
> > 1.8.3.1
> >   
>