On Tue, 22 Mar 2016 15:22:59 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Igor Mammedov <imamm...@redhat.com> writes: > > > Changes since v2: > > - rebase on top of hte lates spapr cpu hotpug series > > - add 'vcpus-count' field, pkre...@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.