From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apnID-0001vn-Mf for qemu-devel@nongnu.org; Mon, 11 Apr 2016 21:39:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apnIA-0000xo-E5 for qemu-devel@nongnu.org; Mon, 11 Apr 2016 21:39:01 -0400 Date: Tue, 12 Apr 2016 11:40:04 +1000 From: David Gibson Message-ID: <20160412114004.461b89b2@voom.fritz.box> In-Reply-To: <20160411113512.1504a2a7@nial.brq.redhat.com> References: <1460114996-236486-1-git-send-email-imammedo@redhat.com> <1460114996-236486-2-git-send-email-imammedo@redhat.com> <20160411142027.5c9a2ecf@voom.fritz.box> <20160411113512.1504a2a7@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/A8WivTOPmdJxdvNKkGSW1SE"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH for-2.7 v6 1/2] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, mjrosato@linux.vnet.ibm.com, thuth@redhat.com, pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, armbru@redhat.com, agraf@suse.de, borntraeger@de.ibm.com, qemu-ppc@nongnu.org, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, mdroth@linux.vnet.ibm.com, afaerber@suse.de --Sig_/A8WivTOPmdJxdvNKkGSW1SE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 11 Apr 2016 11:35:12 +0200 Igor Mammedov wrote: > On Mon, 11 Apr 2016 14:20:27 +1000 > David Gibson wrote: >=20 > > On Fri, 8 Apr 2016 13:29:55 +0200 > > Igor Mammedov wrote: > > =20 > > > 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. > > >=20 > > > 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) > > >=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 to inspect whatever object/abstraction > > > the target platform considers as CPU object. > > >=20 > > > Signed-off-by: Igor Mammedov > > > --- > > > v6: > > > - fix style issues in qapi-schema and qmp-commands, > > > Eric Blake > > > - 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, 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 > > >=20 > > > query_fixup > > > --- > > > include/hw/boards.h | 5 +++++ > > > monitor.c | 13 +++++++++++++ > > > qapi-schema.json | 46 +++++++++++++++++++++++++++++++++++++++++++= +++ > > > qmp-commands.hx | 41 +++++++++++++++++++++++++++++++++++++++++ > > > 4 files changed, 105 insertions(+) > > >=20 > > > 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 CPU= s. > > > * Caller is responsible for freeing returned list. > > > + * @query_hotpluggable_cpus: > > > + * Returns a @HotpluggableCPUList, which describes CPUs objects w= hich > > > + * 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 *ma= chine); > > > }; > > > =20 > > > /** > > > 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 =3D MACHINE(qdev_get_machine()); > > > + MachineClass *mc =3D 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' > > > + } > > > +} =20 > >=20 > > Is there somewhere we should document the fact that these particular > > properties are common ones, but there could be more. The point is that > > management should not assume these are the only fields here, but should > > be prepared to accept anything, and echo it back to the device_add. =20 >=20 > Something along these lines? Something like that, yes. > +## > +# CpuInstanceProperties > +# > +# List of properties to be used for hotplugging a CPU instance, > +# it should be passed by management with device_add command when > +# a CPU is being hotplugged. > +# > +# Note: currently there are 4 properties that could be present > +# but management should be prepared to pass through other > +# properties with device_add command to allow for future > +# interface extension. > =20 > > > + > > > +## > > > +# @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 prov= ides > > > +# @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 } = ] } > > > =20 > > > EQMP > > > + > > > + { > > > + .name =3D "query-hotpluggable-cpus", > > > + .args_type =3D "", > > > + .mhandler.cmd_new =3D qmp_marshal_query_hotpluggable_cpus, > > > + }, > > > + > > > +SQMP > > > +Show existing/possible CPUs > > > +--------------------------- > > > + > > > +Arguments: None. > > > + > > > +Example for x86 target started with -smp 2,sockets=3D2,cores=3D1,thr= eads=3D3,maxcpus=3D6: > > > + > > > +-> { "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]"} > > > + ]}' > > > + > > > +Example for SPAPR target started with -smp 2,cores=3D2,maxcpus=3D4: = =20 > >=20 > > Might be best to say "pseries" here, since that's the exposed machine > > type name, even though we use sPAPR a lot internally. =20 > Di you mean something like this? >=20 > +Example for 'pseries' target started with -smp 2,cores=3D2,maxcpus=3D4:= =20 Perhaps "'pseries' machine type" explicitly, since "target" tends to refer to ISA rather than board in qemu. >=20 > > =20 > > > + > > > +-> { "execute": "query-hotpluggable-cpus" } > > > +<- {"return": [ > > > + { "props": { "core": 1 }, "type": "spapr-cpu-core", "vcpus-coun= t": 1 }, > > > + { "props": { "core": 0 }, "type": "spapr-cpu-core", "vcpus-coun= t": 1, > > > + "qom-path": "/machine/unattached/device[0]"} > > > + ]}' > > > --=20 > > > 1.8.3.1 > > > =20 > >=20 > > =20 >=20 --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/A8WivTOPmdJxdvNKkGSW1SE Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXDFH0AAoJEGw4ysog2bOSvrUQAJ0gfYUsxAxPoVZLCO0VTiJN izyK1+Hcnf7ccUHfCotYYvHUO6ISMFVCqs0dzlWh4WMdM/T69fpgY8goDPFZHaDn AYfRYmwp1WSws7KkAIm6Esxr6S0dMDpRFsyE9LzjUrRspMRkr/PVPXfOXUSVAnUM K1LqagfrGNKsUr8gpvf+XyQnO26iyj8atjOo4U6WKXqYoAWWHbRGygExpw7x29eZ ynkxKBFAzBv+cp0LAlWX9jNSHrdMAvlFi4MLrWhEFjMyx86a6HzwCgZSGlwVcjob 2BQ4OqxE8xxzLZa78/ShjMu3wyUbno6viTAwCPHgSPSw6f8Uvj0NjdIwFzuGdXo/ /sH3mJc0KyV+pV2OKwlhKP9QdoeCF6QKD9jIbOdGGJKQ8zkgGIeK2AxnoyPfUScf epNCXFv2RVDK6KEzKfMBfjEhu1xpbxmZwNiNrSEa2Mn4/R2tTX+Iw/iKIUCn0s6c vEV0akYOrJxCYbZw8Wey/kEFChS6b2KGgERfi2ZEUfdfFIF3MUwQ6NJaZWr+7DL9 B3thzEVqa8Awdgh7rlrbJGGIclx2hxOFu/UYvka3z/7W9l1PR6+u/jtTufWg4Sex 5z8hFrlK3R0epypvjD2P6ZBWRuNN3PDOKUxQzVAsCLSkNKB0RyzH9J2k/Fliclnj MT8yioAPfvQP2T047NsV =cqDp -----END PGP SIGNATURE----- --Sig_/A8WivTOPmdJxdvNKkGSW1SE--