From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFxH-0005FA-Rh for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:12:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWFxG-0007W9-35 for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:12:39 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:50146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWFxF-0007UH-FH for qemu-devel@nongnu.org; Wed, 17 Feb 2016 23:12:38 -0500 Date: Thu, 18 Feb 2016 14:39:52 +1100 From: David Gibson Message-ID: <20160218033952.GG15224@voom.fritz.box> References: <1455556228-232720-1-git-send-email-imammedo@redhat.com> <878u2lhi8i.fsf@blackfin.pond.sub.org> <20160216113655.2bbb9988@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qxfKREH7IwbezJ+T" Content-Disposition: inline In-Reply-To: <20160216113655.2bbb9988@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 --qxfKREH7IwbezJ+T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 16, 2016 at 11:36:55AM +0100, Igor Mammedov wrote: > On Mon, 15 Feb 2016 20:43:41 +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? > Do you mean generic QOM introspection? >=20 > Using QOM we could have '/cpus' container and create QOM links > for exiting (populated links) and possible (empty links) CPUs. > However in that case link's name will need have a special format > that will convey an information necessary for mgmt to hotplug > a CPU object, at least: > - where: [node],[socket],[core],[thread] options > - optionally what CPU object to use with device_add command Hmm.. is it not enough to follow the link and get the topology information by examining the target? In the design Eduardo and I have been discussing we're actually not planning to allow device_add to construct CPU packages - at least, not for the time being. The idea is that the machine type will construct enough packages for maxcpus, and management just toggles them on and off. We can eventually allow construction of new packages with device_add, but for now that gets hidden inside the platform until we've worked out more details. > Another approach to do QOM introspection would be to model hierarchy=20 > of objects like node/socket/core..., That's what Andreas > worked on. Only it still suffers the same issue as above > wrt introspection and hotplug, One can pre-create empty > [nodes][sockets[cores]] containers at startup but then > leaf nodes that could be hotplugged would be a links anyway > and then again we need to give them special formatted names > (not well documented at that mgmt could make sense of). > That hierarchy would need to become stable ABI once > mgmt will start using it and QOM tree is quite unstable > now for that. For some targets it involves creating dummy > containers like node/socket/core for x86 where just modeling > a thread is sufficient. I'd prefer to avoid exposing the node/socket/core heirarchy through the QOM interfaces as much as possible. Although all systems I know of have a heirarchy something like that, exactly what the levels may vary, so I think it's better not to bake that into our interface. Properties giving core/socket/node id values isn't too bad, but building a whole tree mirroring that heirarchy seems like asking for trouble. > The similar but a bit more abstract approach was suggested > by David https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg00000.html >=20 > Benefit of dedicated CPU hotplug focused QMP command is that > it can be quite abstract to suite most targets and not depend > on how a target models CPUs internally and still provide > information needed for hotplugging a CPU object. > That way we can split efforts on how we model/refactor CPUs > internally and how mgmt would work with them using > -device/device_add. >=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 --qxfKREH7IwbezJ+T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWxT0IAAoJEGw4ysog2bOS72AP/25/4xo5v1t2j0dQyGYRUmSm d3vSANZaPSYDA9WaHZcu/IsrOAvzJ2wepsOWFjQMEvI5GHjZ94tlnjCaEDwQBrMA w4+pVXiB7jT+6QVcOz4OaE2rP3U/BdXsV6aNWTs4/CUq0ESQ9vsTVxbjRlyLag3E 09BA4D8vUxN+RMziPhDO5ktsppSio7F46PKcK44MV3JH29wPpg58TwdbciWkhN2Y MrCmkV1r67ZONEw9fvomcTrh/N82SDquYWnIV6sCUsgMSDCDSz0kCt9jIV18aT05 KcgSVYr6whB8i263qTJkvrjL3qwF1cocfJam0aGF16SC25qqBxvId3ctbj0SxwRQ acsE2KwmpE6Hp0EN5JElQg7ba9fXhDe9mqd8ZzP4ADi+12UNra5hzHO51h7ShZeI Ey/iNaWcHECfk7qfX9g/VKSUmJTbjk/BK8c60KKGUqp+8BMbJ/FiQ54b1kb6NuWU are+puP3SAcTm276SUI5pirHd2n0OrW/VQt/WnH72PGAtOX5nsyGXKDYJySb/yM/ xqXkH+pQbl0Pt5x1D8Jbarcmi8MzMmuvoS4X48giyqFl5xXMgHwsqx5AybnwQtvE 3syYRKc3PexwtW6+IY1J/a+lXLGOC3isCLK99pzPn4wShWOg2mkFtAwMqmqc+e0J UUMR0u1AzRmG6g8nhQsW =itw8 -----END PGP SIGNATURE----- --qxfKREH7IwbezJ+T--