From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQqUB-0001AL-Nw for qemu-devel@nongnu.org; Wed, 03 Feb 2016 01:00:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQqU7-0002MB-W2 for qemu-devel@nongnu.org; Wed, 03 Feb 2016 01:00:15 -0500 Date: Wed, 3 Feb 2016 16:42:23 +1100 From: David Gibson Message-ID: <20160203054223.GL15080@voom.fritz.box> References: <20160201053517.GA20608@voom.redhat.com> <20160203050348.GB8516@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7l042bGvurpep9Wg" Content-Disposition: inline In-Reply-To: <20160203050348.GB8516@in.ibm.com> Subject: Re: [Qemu-devel] CPU hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: lvivier@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, aik@ozlabs.ru, agraf@suse.de, abologna@redhat.com, qemu-ppc@nongnu.org, pbonzini@redhat.com, imammedo@redhat.com, afaerber@suse.de --7l042bGvurpep9Wg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2016 at 10:33:48AM +0530, Bharata B Rao wrote: > On Mon, Feb 01, 2016 at 04:35:17PM +1100, David Gibson wrote: > > Hi, > >=20 > > It seems to me we're getting rather bogged down in how to proceed with > > an improved CPU hotplug (and hot unplug) interface, both generically > > and for ppc in particular. > >=20 > > So here's a somewhat more concrete suggestion of a way forward, to see > > if we can get some consensus. > >=20 > > The biggest difficulty I think we're grappling with is that device-add > > is actually *not* a great interface to cpu hotplug. Or rather, it's > > not great as the _only_ interface: in order to represent the many > > different constraints on how cpus can be plugged on various platforms, > > it's natural to use a heirarchy of cpu core / socket / package types > > specific to the specific platform or real-world cpu package being > > modeled. However, for the normal case of a regular homogenous (and at > > least slightly para-virtualized) server, that interface is nasty for > > management layers because they have to know the right type to > > instantiate. > >=20 > > To address this, I'm proposing this two layer interface: > >=20 > > Layer 1: Low-level, device-add based > >=20 > > * a new, generic cpu-package QOM type represents a group of 1 or > > more cpu threads which can be hotplugged as a unit > > * cpu-package is abstract and can't be instantiated directly > > * archs and/or individual platforms have specific subtypes of > > cpu-package which can be instantiated > > * for platforms attempting to be faithful representations of real > > hardware these subtypes would match the specific characteristics > > of the real hardware devices. In addition to the cpu threads, > > they may have other on chip devices as sub-objects. > > * for platforms which are paravirtual - or which have existing > > firmware abstractions for cpu cores/sockets/packages/whatever - > > these could be more abstract, but would still be tied to that > > platform's constraints > > * Depending on the platform the cpu-package object could have > > further internal structure (e.g. a package object representing a > > socket contains package objects representing each core, which in > > turn contain cpu objects for each thread) > > * Some crazy platform that has multiple daughterboards each with > > several multi-chip-modules each with several chips, each > > with several cores each with several threads could represent > > that too. > >=20 > > What would be common to all the cpu-package subtypes is: > > * A boolean "present" attribute ("realized" might already be > > suitable, but I'm not certain) > > * A generic means of determining the number of cpu threads in the > > package, and enumerating those > > * A generic means of determining if the package is hotpluggable or > > not > > * They'd get listed in a standard place in the QOM tree > >=20 > > This interface is suitable if you want complete control over > > constructing the system, including weird cases like heterogeneous > > machines (either totally different cpu types, or just different > > numbers of threads in different packages). > >=20 > > The intention is that these objects would never look at the global cpu > > type or sockets/cores/threads numbers. The next level up would > > instead configure the packages to match those for the common case. > >=20 > > Layer 2: Higher-level > >=20 > > * not all machine types need support this model, but I'd expect > > all future versions of machine types designed for production use > > to do so > > * machine types don't construct cpu objects directly > > * instead they create enough cpu-package objects - of a subtype > > suitable for this machine - to provide maxcpus threads > > * the machine type would set the "present" bit on enough of the > > cpu packages to provide the base number of cpu threads >=20 > In the generic cpu-core RFC that I posted last year > (https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg01526.html), > I did have backend objects (which I called them sockets) into which > the generic cpu-core device would fit it and I used the QOM links to > bring out the notion of cpu-core device populating the socket. >=20 > I had the sockets as backend objects and created as many of them as needed > upfront to fit the max_cpus. These objects weren't exposed them to the us= er, > but instead the cpu-core device was exposed to the user. Right, as I mentioned on IRC this is based partly on your earlier proposal. The big difference, as I see it, is that in this proposal the cpu package objects aren't linked directly to the socket/core/thread heirarchy - different platforms can place them differently based on what works for them. > However, I like the current proposal where Layer 2 interface is exposed t= o the > user and letting archs build up the CPU topology underneath in the manner > that they deem fit for the arch. >=20 > Regards, > Bharata. >=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 --7l042bGvurpep9Wg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWsZM/AAoJEGw4ysog2bOSogIQAKz5yf40ZDDehpAiD6UAKKGD ovKL8ltkSuJvvYzx3oVuX9GdkMkssSn+w2bbDU6pCCzlbFTBqkBYdlKLFzpwA8yb FkXW9+/+fWHT3t36O7YY5ex5Xu4TWT8I1mIkLmlCLIx23tGlDT2cBo1om9K8YGNt uoX73Jmk31wgP1RSDyfz/UyKkTAYd+X/XbehrlsTTlcl4Ddn104f4JNaCEticMci idchas/PJAqqedjib58+VKivQQv5QjOHHV4Hml++GSCvT9fwzUnjh3EwSRKXxVve rXEeaeigfmHOhUlte5T8/713zZspgBAxsplxblO2CIB5HFF132h4ScniIAy5EUuF JuNnvBwZtpbOVajex2XytMOEevYBR5kG4ygtzZTqnHIty82/+i24UtleAFMbYyPI dNhmePxOl4Takh9f6kB9QGd+2+mah0MvxgJuyFOSaT1Lh+6M3ixfb/GqXbkn6+Pf DLoqnVH+G1AIHGczl90wo2Hi1XMCwhE9S7AquYNrntLQ+hPtfo/eR2ZRc6m7uUTv FlmbupDAqxZV8ld9ZjZplwGR+zMi+waWaTVeCkDzEEB0FLjkYGVDle0MaZeQww58 tiwT26d1rmTU2VW8iSB042N0vFaKs3ekm/8p64aPhJwypb4Ez9VjaxMNsUWXWysR tTLhztbbfCyMc51qxLJ9 =v+8H -----END PGP SIGNATURE----- --7l042bGvurpep9Wg--