From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afzW3-0000Ff-L1 for qemu-devel@nongnu.org; Tue, 15 Mar 2016 20:40:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afzVx-0004Aa-2z for qemu-devel@nongnu.org; Tue, 15 Mar 2016 20:40:47 -0400 Date: Wed, 16 Mar 2016 11:41:44 +1100 From: David Gibson Message-ID: <20160316004144.GO9032@voom> References: <1457974600-13828-1-git-send-email-clg@fr.ibm.com> <1457974600-13828-5-git-send-email-clg@fr.ibm.com> <20160315094545.GD9032@voom> <1458076308.3107.46.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9DptZICXTlJ7FQ09" Content-Disposition: inline In-Reply-To: <1458076308.3107.46.camel@kernel.crashing.org> Subject: Re: [Qemu-devel] [PATCH 04/17] ppc: Add number of threads per core to the processor definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Thomas Huth , =?iso-8859-1?Q?C=E9dric?= Le Goater , qemu-ppc@nongnu.org, qemu-devel@nongnu.org --9DptZICXTlJ7FQ09 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 08:11:48AM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2016-03-15 at 20:45 +1100, David Gibson wrote: > > On Mon, Mar 14, 2016 at 05:56:27PM +0100, C=E9dric Le Goater wrote: > > >=20 > > > From: Benjamin Herrenschmidt > > >=20 > > > Also use it to clamp the max SMT mode and ensure that the cpu_dt_id > > > are offset by that value in order to preserve consistency with the > > > HW implementations. >=20 > > I think this can change change CPU ids, and therefore break migration > > on some existing setups.=A0=A0So it will need some rework to apply at > > all, and will certainly want to wait until after 2.6 >=20 > Our migration is so bloody damn fragile ... grrr. Well, yes, but that can't really be blamed for this one: you're changing a guest visible detail. > We will need it for powernv though, there are many things especially in > OPAL that rely on the consistent numbering. Right. Really it doesn't make sense to allocate the dt_id here - that should be done in the machine type code which actually controls the DT. That way we can change to fixed numbering for powernv (and possibly future spapr) machine types, while leaving it the same for existing machine types for compatibility. > In fact, it will have to go further and number the cores based on their > equivalent HW numbers at some point for SCOMs to work, which means a > slightly discontiguous numbering scheme (no core 0 for example). At > least if we want to model some of the EX XSCOMs. Right, another argument that the machine setup code needs to be in charge of the guest visible CPU ids. --=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 --9DptZICXTlJ7FQ09 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW6KvIAAoJEGw4ysog2bOSl1sP/iIWsckqOhGLIe+OKcrbBt8n AEq7FMknvT7gI0SJMQ2Z8/vyQ9FNCQ9xMyOFc/Dw6DRi4TEE9xCMVfriIrt4++Oi 8taHYLvXKvcv7/ERNTT8HK03u0zunZ8rAanRwDBdkuglg4aUW7Aa0ZWS9UDjArpa S3hRtd+36UTN+psP09dOB+k/q4+XHFbVAdPHW79SdHdmPmo+yt2fTEqJDcaPiIPK qa6YSgy9hnMfvMLt5TtTDFGI451x6kwlU86CNjiOJ+JL/A3wmZcsL6HB9BYOtTD5 ae+woOw2qc40z7Oey1d9DiXX/aHRH9OjRYeL9ZtiLofI42V0jY8BMBs5TzG1qIPK HKlvoti3SxwxSBEOApBfL/m4G5X+L27FnHJYhJOZLfWThL7lEBnKoCGw9M/g2bFT Mnp6Pkiu9RF0m6ypEWPQIczto+TH3jkddWIFS08auoFa7GG0btlMenZjbcK8gzf9 hc3p0tK/G994AXlwSxjCZNM50MUOBKThsdt2uyHvDCMNCwoFML4empr9Vc0XLad2 WehE+O6LhY/vsPVI+YvIxVCjzhdpNsX7kOma1KSAG8Y0FqmYv6PHAguxZiklZ9XG lN7GuP9Yli9QVcZpmWon+8XkXQJ8h4sMuvRmhWxh1yzG/I28rUJACKnXdpq4GvL5 9HCQ1fe2Oj0TSgtlgvWk =L104 -----END PGP SIGNATURE----- --9DptZICXTlJ7FQ09--