From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVNBw-0003AG-OB for qemu-devel@nongnu.org; Mon, 15 Feb 2016 12:44:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVNBt-0003sz-Gw for qemu-devel@nongnu.org; Mon, 15 Feb 2016 12:44:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVNBt-0003sv-9J for qemu-devel@nongnu.org; Mon, 15 Feb 2016 12:44:05 -0500 References: <1455556228-232720-1-git-send-email-imammedo@redhat.com> From: Eric Blake Message-ID: <56C20E60.8050504@redhat.com> Date: Mon, 15 Feb 2016 10:44:00 -0700 MIME-Version: 1.0 In-Reply-To: <1455556228-232720-1-git-send-email-imammedo@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uDrh6NXFXmM1rr3qr0jCIDl6jaQTHOnEL" Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , qemu-devel@nongnu.org Cc: lvivier@redhat.com, thuth@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, abologna@redhat.com, agraf@suse.de, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uDrh6NXFXmM1rr3qr0jCIDl6jaQTHOnEL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/15/2016 10:10 AM, Igor Mammedov wrote: > it will allow mgmt to query present and possible to hotplug CPUs > it is required from a target platform that wish to support > command to set board specific MachineClass.possible_cpus() hook, > which will return a list of possible CPUs with options > that would be needed for hotplugging possible CPUs. >=20 > For RFC there are: > 'arch_id': 'int' - mandatory unique CPU number, > for x86 it's APIC ID for ARM it's MPIDR > 'type': 'str' - CPU object type for usage with device_add >=20 > and a set of optional fields that would allows mgmt tools > to know at what granularity and where a new CPU could be > hotplugged; > [node],[socket],[core],[thread] > Hopefully that should cover needs for CPU hotplug porposes for > magor targets and we can extend structure in future adding > more fields if it will be needed. >=20 > also for present CPUs there is a 'cpu_link' field which > would allow mgmt inspect whatever object/abstraction > the target platform considers as CPU object. >=20 > For RFC purposes implements only for x86 target so far. >=20 > Signed-off-by: Igor Mammedov > --- Just an interface review for now: > +++ b/qapi-schema.json > @@ -4083,3 +4083,33 @@ > ## > { 'enum': 'ReplayMode', > 'data': [ 'none', 'record', 'play' ] } > + > +## > +# @HotpluggableCPU > +# > +# @type: CPU object tyep for usage with device_add command s/tyep/type/ > +# @arch_id: unique number designating the CPU within board Please use '-' rather than '_' in new interfaces (this should be 'arch-id= ') > +# @node: NUMA node ID the CPU belongs to, optional Most optional fields are marked with a prefix of '#optional', not an unmarked suffix. This will matter once we get to Marc-Andre's patches for automated documentation. > +# @socket: socket number within node/board the CPU belongs to, optiona= l > +# @core: core number within socket the CPU belongs to, optional > +# @thread: thread number within core the CPU belongs to, optional > +# @cpu_link: link to existing CPU object is CPU is present or Again, 'cpu-link'. > +# omitted if CPU is not present. > +# > +# Since: 2.6 Missing '##' marker line. > +{ 'struct': 'HotpluggableCPU', > + 'data': { 'type': 'str', > + 'arch_id': 'int', > + '*node': 'int', > + '*socket': 'int', > + '*core': 'int', > + '*thread': 'int', > + '*cpu_link': 'str' > + } > +} > + > +## > +# @query-hotpluggable-cpus > +# > +# Since: 2.6 Missing '##' terminator, and also lacking on details. > +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU']= } Why do we need a new command? Why can't the existing 'CpuInfo' be expanded to provide the new information as part of the existing 'query-cpus'? > diff --git a/qmp-commands.hx b/qmp-commands.hx > index 020e5ee..cbe0ba4 100644 > --- a/qmp-commands.hx > +++ b/qmp-commands.hx > @@ -4818,3 +4818,29 @@ Example: > {"type": 0, "out-pport": 0, "pport": 0, "vlan-id": 38= 40, > "pop-vlan": 1, "id": 251658240} > ]} > + > +EQMP > + > + { > + .name =3D "query-hotpluggable-cpus", > + .args_type =3D "", > + .mhandler.cmd_new =3D qmp_marshal_query_hotpluggable_cpus, > + }, > + > +SQMP > +Show existing/possible CPUs > +------------------------------- Why two spaces? --- separator line should be same length as the line abov= e. > + > +Arguments: None. > + > +Example for x86 target started with -smp 2,sockets=3D2,cores=3D1,threa= ds=3D3,maxcpus=3D6: > + > +-> { "execute": "query-hotpluggable-cpus" } > +<- {"return": [ > + {"core": 0, "socket": 1, "thread": 2, "arch_id": 6, "type": "qemu= 64-x86_64-cpu"}, > + {"core": 0, "socket": 1, "thread": 1, "arch_id": 5, "type": "qemu= 64-x86_64-cpu"}, > + {"core": 0, "socket": 1, "thread": 0, "arch_id": 4, "type": "qemu= 64-x86_64-cpu"}, > + {"core": 0, "socket": 0, "thread": 2, "arch_id": 2, "type": "qemu= 64-x86_64-cpu"}, > + {"core": 0, "arch_id": 1, "socket": 0, "thread": 1, "type": "qemu= 64-x86_64-cpu", "cpu_link": "/machine/unattached/device[3]"}, > + {"core": 0, "arch_id": 0, "socket": 0, "thread": 0, "type": "qemu= 64-x86_64-cpu", "cpu_link": "/machine/unattached/device[0]"} Long line. Please wrap the example to fit in 80 columns (we've already added stylistic whitespace beyond the single-line JSON output that we really get from QMP). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --uDrh6NXFXmM1rr3qr0jCIDl6jaQTHOnEL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWwg5gAAoJEKeha0olJ0Nq8IUIAKiM1bO6W0TOL2zMzZyOaCz2 EHB64kyuA+PfURWqk/OAjmE88bqLMRexWI8rvzvQ5PcXILZVgkCyc13e86MlANmH OGwofx4KRUBdIHQdlRVTuKfUjBYXlBOG4Diva0K3L8Z42iunJbCH3yOJFx/xIBlU iBtBJyTZVb9rCC7EXN8zMUsXJuA7RRP+DDvHIPGuV/jLzHXVDx74nWyKc5Y96meb W85otA/wNoJf8hT3aZq2DLVu58AJAAXKAyBufadQpTV+SZz6dpnN+XxO9zeqSjA2 PLGgF/nyr+mDZnJAeNqI7kv1sPEHXVhqKiZCXWoFz3LcVZzM77H/k9MOQKnTrZI= =BEAz -----END PGP SIGNATURE----- --uDrh6NXFXmM1rr3qr0jCIDl6jaQTHOnEL--