From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adV7h-00046z-4h for qemu-devel@nongnu.org; Tue, 08 Mar 2016 22:49:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adV7f-0002J2-Ii for qemu-devel@nongnu.org; Tue, 08 Mar 2016 22:49:20 -0500 Date: Wed, 9 Mar 2016 14:15:30 +1100 From: David Gibson Message-ID: <20160309031530.GK22546@voom.fritz.box> References: <1457443095-213125-1-git-send-email-imammedo@redhat.com> <1457443095-213125-2-git-send-email-imammedo@redhat.com> <56DF0202.8050101@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ef8eQmdvO1j1gFMO" Content-Disposition: inline In-Reply-To: <56DF0202.8050101@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 1/5] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com, pbonzini@redhat.com, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, Igor Mammedov , mdroth@linux.vnet.ibm.com, afaerber@suse.de --ef8eQmdvO1j1gFMO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > maybe s/possible to hotplug/hotpluggable/ >=20 > > 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 >=20 > s/functioni/function/ >=20 > > with options that would be needed for hotplugging possible > > CPU objects. > >=20 > > For RFC there are: > > 'type': 'str' - OQOM CPU object type for usage with device_add >=20 > s/OQOM/QOM/ ? >=20 > >=20 > > 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] > >=20 > > For present CPUs there is a 'qom-path' field which > > would allow mgmt inspect whatever object/abstraction >=20 > s/inspect/to inspect/ >=20 > > the target platform considers as CPU object. > >=20 > > Signed-off-by: Igor Mammedov > > --- > > 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 > >=20 > > 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 >=20 > 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. >=20 > > +# > > +# @node: NUMA node ID the CPU belongs to, optional >=20 > 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. >=20 > > +# @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 >=20 > Ah, so you've already conceded that this is too much of a feature too > late past 2.6 soft freeze. >=20 > > +{ '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. >=20 > Missing '#optional' marker. >=20 > > +# @props: list of properties to be used for hotplugging CPU >=20 > 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 >=20 > Inconsistent - how can the command be 2.6 if the structures it uses are 2= =2E7? >=20 > > +{ 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU']= } >=20 > > +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}, "type": "qemu64-x86_64-cpu= "}, >=20 > Not valid JSON. You probably meant: >=20 > {"return": [ > { "props": {"core"...2}, "type"...}, >=20 > > + {"core": 0, "socket": 0, "thread": 1}, "type": "qemu64-x86_64-cpu= ", "qom-path": "/machine/unattached/device[3]"}, >=20 > It's okay to line-wrap, to keep 80-column lines. >=20 > > + {"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=3D2,maxcpus=3D4: > > + > > +-> { "execute": "query-hotpluggable-cpus" } > > +<- {"return": [ > > + {"core": 1 }, "type": "spapr-cpu-core"}, >=20 > Again, not valid JSON. >=20 > But useful examples. >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --ef8eQmdvO1j1gFMO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW35VSAAoJEGw4ysog2bOSi3EQALn5ILBHyq7zHYwfVZP6CE9w ao50SERzKgqT1ctCcOwfekeexVC0WhsCKdZA4tU2DQfYjFe6KxpntwPpdBUehs0V ZMESNNrosYw9eKBS91skQopWHzYpFkfY0VRmBPhGxU5Qilua5/zIBEdU1y6gEMsq CnEQYFje1i0yjFmgqPm9CFgDyGvcwiyQFh8w+monfevVR7orMo9qqcqVM+Q4vryF Vct9V8Ywf7sd9d4tZhshigprpnerVHpbLO3Slvod/0lfJoCXr7wLGE7I2a3b94YC S9aKfSHoH4Yy8xatsnvTKXklq3GR6UuYUU5hh/Q3UGBsojqX3v4JGcKqDoAmJgz7 qJ/2ybtIdYNBk0JHxiUMYC5TMrMgHIaDufe5kNjMf0asSktciRXtA/lAJtBSYHEo 0lsdg679f/RB3U8CSj2oudg2aLQTc+qcZvX5Cu441wHIBScBdYKEs2l2pQj38NR8 SRCHERffr20gnRV9Ot3Gqd8Va7vvUll5VQhVyq0VcsHOrfMwvpjZXe0KkG2r2tgc 0vpCK9yt6Q9cFenRVTAoeVKEP3xUXQbH0zIow3kQFjRrGhBxw9pewoBR48xeGayc tXmrvSpYwGLmFDVBPP54pr9A+4Q91x7w47lqZY4pEK15aaWizL0PLBxid0ahroYA qoZk0pskO06D9kQoAeGa =D73t -----END PGP SIGNATURE----- --ef8eQmdvO1j1gFMO--