From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIqc1-0001H0-PC for qemu-devel@nongnu.org; Mon, 11 Jan 2016 23:31:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIqbz-0001hq-0i for qemu-devel@nongnu.org; Mon, 11 Jan 2016 23:31:17 -0500 Received: from ozlabs.org ([103.22.144.67]:43584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIqby-0001h6-NG for qemu-devel@nongnu.org; Mon, 11 Jan 2016 23:31:14 -0500 Date: Tue, 12 Jan 2016 14:54:34 +1100 From: David Gibson Message-ID: <20160112035434.GI22925@voom.redhat.com> References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <567180EA.5040709@suse.de> <20151216164441.270a1f72@igors-macbook-pro.local> <56718A02.1090701@suse.de> <20151216182220.258dc9f0@igors-macbook-pro.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VSaCG/zfRnOiPJtU" Content-Disposition: inline In-Reply-To: <20151216182220.258dc9f0@igors-macbook-pro.local> Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: peter.maydell@linaro.org, ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, Bharata B Rao , pbonzini@redhat.com, Andreas =?iso-8859-1?Q?F=E4rber?= --VSaCG/zfRnOiPJtU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2015 at 06:22:20PM +0100, Igor Mammedov wrote: > On Wed, 16 Dec 2015 16:57:54 +0100 > Andreas F=E4rber wrote: >=20 > > Am 16.12.2015 um 16:44 schrieb Igor Mammedov: > > > On Wed, 16 Dec 2015 16:19:06 +0100 > > > Andreas F=E4rber wrote: > > >=20 > > >> Am 10.12.2015 um 07:15 schrieb Bharata B Rao: > > >>> CPU hotplug granularity > > >>> ----------------------- > > >>> CPU hotplug will now be done in cpu-core device granularity. > > >> > > >> Nack. > > >> > > >>> Are there archs that would need thread level CPU addition ? > > >> > > >> Yes, s390. And for x86 people called for socket level. > > > socket level hotplug would be the last resort if we can't agree > > > on thread level one. As it would break existing setups where > > > user can hotplug 1 core, and I'd like to avoid it if it is > > > possible. > >=20 > > We still need to keep cpu-add for backwards compatibility, so I am > > discussing solely the new device_add interface. My previous x86 series > > went to severe hacks trying to keep cpu-add working with > > sockets&cores. > if possible, it would be better to make cpu-add to use device_add > internally. >=20 > >=20 > > Attendees in Seattle said that thread-level hot-plug were dangerous > > for Linux guests due to assumptions in the (guest's) scheduler > > breaking for any incompletely filled cores or sockets. No one present > There is not such thing as cpu hotplug at socket level in x86 linux so fa= r. > CPUs are plugged at logical(thread) cpu level, one at a time. > And ACPI spec does the same (describes logical CPUs) and hotplug > notification in guest handled per one logical cpu at a time. I don't think that precludes handling hotplug at socket level in qemu. The user <-> qemu interaction can work on the socket level, then the qemu <-> guest interaction on the thread level, iterating through the threads in the socket. Problems arise when the qemu <-> guest protocol is at a coarser granularity than the user <-> qemu protocol, rather than the other way around, AFAICT. This is the problem we have with the existing interfaces for Power - there the qemu <-> guest protocol specified by the platform has no way of representing a single thread hotplug, it's always a core at a time (as a paravirt platform, there's not really a useful difference between cores and sockets). --=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 --VSaCG/zfRnOiPJtU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWlHj6AAoJEGw4ysog2bOS34IP/1/nNVTwAvKIMyzABE6iDOsp iRaPKBU49QakNrjOFcQgndkxH1LKMMaLx65cA5W23dwLeXsoacuP5d0KkmCe/Ko9 RQ91m51lmgUi8f9d2NF19uRYqIZKK4FEXz8dmF0KhVbaqCXWKAvmTxvwAmuYUaWh oE0Tuw9zqekHG1nBbR1qO7dI2obUXeYkmXYGdVNVaygZTFDI1I3dEgRXt2hfRYag SJzdjSnH6HKZ5f1zbr1GtgLO1zFStvvPbZHN8TyFVZAMCRue2hrt7OnjpjWHs4Rb uk4Uz+GWzaUOoEfictxg9uBXe1PyihV7C6gkuMwZL8l8j00GdB7eYCZQKjbTLG9j igd5QQDXjIrqchv3gLkvG1qAPDlGgUjWv4fIib02kX/bA7LumNMmRRZNXbMWfJNn bO7NT2aIH+LpzcgTsiVIs88E/MkqONwxf9o82evWwOJyDZ7L/xRQ62UyUByf0U6j h8t6zfMuY8EjxqsKleyIoxsxd8rrwzhl2obv1b2QtArrijXGLE+O09GgWGVAZjfz cFZTeJqFG1izs+v84fZDyA/KxU45UxQOqRiN4j6abvBlyOsJKnmwUDG32XLM6OPW YB7lIc1bzUCmBxSaf5xqAs1WgslC72yBInfWs5VNo2roNetWZgUsqZlhaYPLut2L PA7bgCv62fcSN1we8ylL =iQ59 -----END PGP SIGNATURE----- --VSaCG/zfRnOiPJtU--