From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYXbN-0005TC-Ay for qemu-devel@nongnu.org; Wed, 24 Feb 2016 06:27:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYXbL-0005mU-SC for qemu-devel@nongnu.org; Wed, 24 Feb 2016 06:27:29 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:35308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYXbK-0005m9-Nm for qemu-devel@nongnu.org; Wed, 24 Feb 2016 06:27:27 -0500 Date: Wed, 24 Feb 2016 22:26:04 +1100 From: David Gibson Message-ID: <20160224112604.GO2808@voom.fritz.box> References: <1455556228-232720-1-git-send-email-imammedo@redhat.com> <878u2lhi8i.fsf@blackfin.pond.sub.org> <20160216054834.GM2269@voom.redhat.com> <20160216115242.79d8590d@nial.brq.redhat.com> <20160218040510.GI15224@voom.fritz.box> <20160218115516.5c66fee4@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XzwO5SPJOYU+7Pos" Content-Disposition: inline In-Reply-To: <20160218115516.5c66fee4@nial.brq.redhat.com> 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 Cc: lvivier@redhat.com, agraf@suse.de, thuth@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru, Markus Armbruster , qemu-devel@nongnu.org, abologna@redhat.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, afaerber@suse.de --XzwO5SPJOYU+7Pos Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2016 at 11:55:16AM +0100, Igor Mammedov wrote: > On Thu, 18 Feb 2016 15:05:10 +1100 > David Gibson wrote: >=20 > > On Tue, Feb 16, 2016 at 11:52:42AM +0100, Igor Mammedov wrote: > > > On Tue, 16 Feb 2016 16:48:34 +1100 > > > David Gibson wrote: > > > =20 > > > > On Mon, Feb 15, 2016 at 08:43:41PM +0100, Markus Armbruster wrote: = =20 > > > > > Igor Mammedov writes: > > > > > =20 > > > > > > 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. > > > > > > > > > > > > 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 > > > > > > > > > > > > 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. > > > > > > > > > > > > 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. > > > > > > > > > > > > For RFC purposes implements only for x86 target so far. =20 > > > > >=20 > > > > > Adding ad hoc queries as we go won't scale. Could this be solved= by a > > > > > generic introspection interface? =20 > > > >=20 > > > > That's my main concern as well. > > > >=20 > > > > Igor, did you see my post with a proposal for how to organize > > > > hotpluggable packages of CPUs? I believe that would also solve the > > > > problem at hand here, by having a standard QOM location with > > > > discoverable cpu objects. > > > >=20 > > > > The interface in your patch in particular would *not* solve the > > > > problem of advertising to management layers what the granularity of > > > > CPU hotplug is, which we absolutely need for Power. =20 > > > I've had in mind Power as well, as topology items are optional > > > a query can respond with what granularity board would like > > > to use and what type of object it could be hotplugged: > > > =20 > > > -> { "execute": "query-hotpluggable-cpus" } =20 > > > <- {"return": [ > > > {"core": 2, "socket": 2, "arch_id": 2, "type": "power-foo-core-c= pu"}, > > > {"core": 1, "socket": 1, "arch_id": 1, "type": "power-foo-core-c= pu"}, > > > {"core": 0, "socket": 0, "arch_id": 0, "type": "power-foo-core-c= pu", "cpu_link": "/machine/unattached/device[3]"} > > > ]} =20 > >=20 > > Hrm.. except your arch_id is supplied by a CPUClass hook, making it a > > per-thread property, whereas here it needs to be per-core. > That's only for demo purposes, it could be something else that is fixed > and stable. For example it could be QOM link path associated with it. > Like: { 'path': '/cpu[0]', ... }, or just something else to enumerate > a set of possible CPUs. Hm, ok. > > Other than that I guess this covers what we need for Power, however I > > dislike the idea of typing the hotplug granularity to be at any fixed > > level of the socket/core/thread heirarchy. As noted elsewhere, while > > all machines are likely to have some sort of similar heirarchy, giving > > it fixed levels of "socket", "core" and "thread" may be limiting. > That's an optional granularity, if target doesn't care, it could skip > that parameters or even extend command to provide a target specific > parameters to create a CPU object, socket/core/thread are provided here > as they would fit majority usecases. These optional parameters are > basically a set of mandatory CPU object properties with values > that mgmt should supply at -device/device_add time to create a CPU with > expected properties. It seems really weird to me to tell management a bunch of parameters which it then needs to echo back to device_add. If we're adding an interface, why not just add a "add/remove cpu unit" interface. --=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 --XzwO5SPJOYU+7Pos Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWzZNMAAoJEGw4ysog2bOSBjsP/jMpe9otA+ckgnrc1imiNW9H zT1ESAEfKRjBoU6jXY+5uzuDsRTKp81n9wojwtmrSutgUh5OzG3dm0NI223EF2ZI 5g8D3sePJdYqAmk3xDZ7EDeuumr9LWCMICsh/GgJAGVsJ7yG4jsujNNdCr7PQ1Nt hluBVwVC7VLjwJDRHyl3yIeo5YVdPWjOwGydXjWUIvFE3ImQJ1bySdHR3WVWoZWO 67kPf2HyWzGoM3mZVP9DWfTfWgQc8qj7iwb30M4zL8Oj66O7wpxB4NFCR9PmVpzq HkRvSNJGoHIOpg+u5Oi41Gkc+hUugtGWShHmebHwKWP/wr8xNibyOiDy0iw0Z/GZ keKgIS4n5UAQPq6PEilchgt1Llzfdg2MuJcW5xByfDj3znheZs+WtfsIrYfE8H3H TXJwwABbIZyy1T7hgUHzWEy0sDRwTmxZFNnB0Ihy7tKH28d68d4QFykz6LNTxwh2 OQo6tIJhi1UYfdqzw/VLl1tCi2PV3jJXUfP+cL/HNLr0MApR6Ryu/V9MDb2PnWRm MTQvIBLIV+svYjKg8PhNVVQaHCFG2724Qop7Ilh5WMQGhsR7JE0IaUunF8/2mnqt jCJUxcW2DwFGhNOF3c4n1O/3YCOmZ41YnCQqZP9VswNaprxGZbMwVq/bgFafyuv4 /FYweP58aEKVAL5doBw3 =ar/2 -----END PGP SIGNATURE----- --XzwO5SPJOYU+7Pos--