Re: [Qemu-devel] [PATCH v3 0/2] spapr: QMP: add query-hotpluggable-cpus

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 22 Mar 2016 15:22:59 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Igor Mammedov <imammedo@redhat.com> writes:
> 
> > Changes since v2:
> >  - rebase on top of hte lates spapr cpu hotpug series
> >  - add 'vcpus-count' field, pkrempa@redhat.com
> >  - s/CpuInstanceProps/CpuInstanceProperties/
> >  - use '#optional' marker
> >  - make "props" as always present even if it's empty
> >  - fix JSON examples
> >  - fix minor typos
> >  - drop pre_plug spapr impl out of series as not related to QMP command
> >  - drop generic pre hotplug callback as not related to QMP command
> >
> > Changes since RFC:
> >  - drop arch_id
> >  - move CPU properties into separate structure
> >  - target implements its own qmp callback version
> >  - rebased on top of [RFC PATCH v1 00/10] Core based CPU hotplug for PowerPC sPAPR
> >                       https://www.mail-archive.com/qemu-devel@nongnu.org/msg357567.html
> >     - convert slot name to core id hack
> >     - drop links
> >     - add generic pre hotplug callback
> >     - implement query-hotpluggable-cpus
> >
> > The first patch (QMP API) in this series could go in first
> > allowing individual targets to post their hotplug
> > implementation independently on top of it.  
> 
> We discussed the need for a yet another ad hoc query command.  Can you
> please summarize the discussion and its conclusion?  Explaining *why* a
> feature is needed is always a good idea.  Cover letter and commit
> messages are good places for it.
Summary would be:

that yet another ad hoc query QMP command is
 1. a single / atomic command 
 2. well documented
 3. fixed at compile time/staic so it's easy for mgmt to discover it.

while a considered alternative QOM interface via qom-get(path) is
 1. not atomic, i.e. requires a lot of qom-get commands over the wire
    to traverse QOM tree and fetch information
 2. not documented
 3. dynamically generated and would require more complicated coding
    even to create a simplistic interface similar to proposed QMP command
    (for example: possible_cpu QOM objects with a related properties)

I hope, I haven't missed anything.