From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmgwZ-0002Jk-L5 for qemu-devel@nongnu.org; Mon, 27 Apr 2015 07:11:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmgwV-00062s-Ii for qemu-devel@nongnu.org; Mon, 27 Apr 2015 07:11:19 -0400 Received: from ozlabs.org ([103.22.144.67]:36690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmgwV-00061v-0S for qemu-devel@nongnu.org; Mon, 27 Apr 2015 07:11:15 -0400 Date: Mon, 27 Apr 2015 20:46:07 +1000 From: David Gibson Message-ID: <20150427104607.GE20223@voom.redhat.com> References: <1427131923-4670-1-git-send-email-afaerber@suse.de> <5523D0FF.7090609@de.ibm.com> <20150423073233.GB26536@voom.redhat.com> <20150423131736.GA17796@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WK3l2KTTmXPVedZ6" Content-Disposition: inline In-Reply-To: <20150423131736.GA17796@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] cpu modelling and hotplug (was: [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Peter Maydell , Bharata B Rao , qemu-devel@nongnu.org, Alexander Graf , Christian Borntraeger , "Jason J. Herne" , Paolo Bonzini , Cornelia Huck , Igor Mammedov , Andreas =?iso-8859-1?Q?F=E4rber?= --WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 23, 2015 at 10:17:36AM -0300, Eduardo Habkost wrote: > On Thu, Apr 23, 2015 at 05:32:33PM +1000, David Gibson wrote: > > On Tue, Apr 07, 2015 at 02:43:43PM +0200, Christian Borntraeger wrote: > > > We had a call and I was asked to write a summary about our conclusion. > > >=20 > > > The more I wrote, there more I became uncertain if we really came to = a=20 > > > conclusion and became more certain that we want to define the QMP/HMP= /CLI > > > interfaces first (or quite early in the process) > > >=20 > > > As discussed I will provide an initial document as a discussion start= er > > >=20 > > > So here is my current understanding with each piece of information on= one line, so=20 > > > that everybody can correct me or make additions: > > >=20 > > > current wrap-up of architecture support > > > ------------------- > > > x86 > > > - Topology possible > > > - can be hierarchical > > > - interfaces to query topology > > > - SMT: fanout in host, guest uses host threads to back guest vCPUS > > > - supports cpu hotplug via cpu_add > > >=20 > > > power > > > - Topology possible > > > - interfaces to query topology? > >=20 > > For power, topology information is communicated via the > > "ibm,associativity" (and related) properties in the device tree. This > > is can encode heirarchical topologies, but it is *not* bound to the > > socket/core/thread heirarchy. On the guest side in Power there's no > > real notion of "socket", just cores with specified proximities to > > various memory nodes. > >=20 > > > - SMT: Power8: no threads in host and full core passed in due to HW d= esign > > > may change in the future > > >=20 > > > s/390 > > > - Topology possible > > > - can be hierarchical > > > - interfaces to query topology > > > - always virtualized via PR/SM LPAR > > > - host topology from LPAR can be heterogenous (e.g. 3 cpus in 1st= socket, 4 in 2nd) > > > - SMT: fanout in host, guest uses host threads to back guest vCPUS > > >=20 > > >=20 > > > Current downsides of CPU definitions/hotplug > > > ----------------------------------------------- > > > - smp, sockets=3D,cores=3D,threads=3D builds only homogeneous topology > > > - cpu_add does not tell were to add > > > - artificial icc bus construct on x86 for several reasons (link, sysb= us not hotpluggable..) > >=20 > > Artificial though it may be, I think having a "cpus" pseudo-bus is not > > such a bad idea >=20 > That was considered before[1][2]. We have use cases for adding > additional information about VCPUs to query-cpus, but we could simply > use qom-get for that. The only thing missing is a predictable QOM path > for VCPU objects. >=20 > If we provide something like "/cpus/" links on all machines, > callers could simply use qom-get to get just the information they need, > instead of getting too much information from query-cpus (which also has > the side-effect of interrupting all running VCPUs to synchronize > register information). >=20 > Quoting part of your proposal below: > > Ignoring NUMA topology (I'll come back to that in a moment) qemu > > should really only care about two things: > >=20 > > a) the unit of execution scheduling (a vCPU or "thread") > > b) the unit of plug/unplug > > > [...] > > 3) I'm thinking we'd have a "cpus" virtual bus represented in QOM, > > which would contain the vCMs (also QOM objects). Their existence > > would be generic, though we'd almost certainly use arch and/or machine > > specific subtypes. > >=20 > > 4) There would be a (generic) way of finding the vCPUS (threads) in a > > vCM and the vCM for a specific vCPU. > > >=20 > What I propose now is a bit simpler: just a mechanism for enumerating > VCPUs/threads (a), that would replace query-cpus. Later we could also > have a generic mechanism for (b), if we decide to introduce a generic > "CPU module" abstraction for plug/unplug. >=20 > A more complex mechanism to enumerating vCMs and the vCPUs inside a vCM > would be a superset of (a), so in theory we wouldn't need both. But I > believe that: 1) we will take some time to define the details of the > vCM/plug/unplug abstractions; 2) we already have use cases today[2] that > could benefit from a generic QOM path for (a). That seems like a reasonable first step. I don't think it conflicts with any of the things I was suggesting. --=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 --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVPhNvAAoJEGw4ysog2bOSU3wQAJGCV/BemgTe9jCe1v6EEnou z4FRIfSu5vFT2KPHeVhAx7kPrt+9tDYEkWOi4nmZEgSlde91etMfSrjm7VBa8QXb /Ls43yo+aS/+hoxitboscWFBX0JMAQN3UiDwcCdigBjyYP3nh9ujhWewp5Ut/SiC q2TI10Ull5Z9Eh3cn6PYAtOonakYOJosuXLW74/x5DYg3DBMbJZfzV7wzgd7zqcn nhDLkPXlJiuPk4yvZM/HaiLSgFfMDStuUMl7OqK4XjLwNVl0ZM1ckEhPc8iT57gY 4bEcpwmOUJE+pQHuZE9FHzTSsowUsWNL4UcRZro4bd0YgR2fkABvPG1h/mowCcck WRxC3MhYYat8HbGtlRAjAU/EnI0r0h42qERYistq47cmTktH93O5eXnpju1LM6S9 9uWc7XoF4VvLYVSZb4DgsQjNfkeWmxCX1yq9Rv/XCgvxua2JCxIzd1qFRLOsEWp+ 7zntN8Y5LeVf2MLB4/JxPkgR+CQD89/otjlkWzy1gIznXwnXvl05Nt+E5IC5Eayg XcuZeGOu376TTcl8QpEaQdrcoJRarbJ+bdOcmnN3Gh70FZEQWWejceDyMc6oK/01 PD9b9LeY/YJd2qmaNJpknjHEizbZSJUmQir2Wmf0Bws6mcbRYK0IBDdRPFqfCOMH FuwnEbITYpe89jRZN2HI =TKp9 -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6--