From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRZs8-0005Xx-UQ for qemu-devel@nongnu.org; Mon, 25 Jul 2016 03:00:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRZs4-00023e-0a for qemu-devel@nongnu.org; Mon, 25 Jul 2016 03:00:15 -0400 Date: Mon, 25 Jul 2016 16:01:31 +1000 From: David Gibson Message-ID: <20160725060131.GJ24621@voom.fritz.box> References: <146918576946.26293.7740314135850382852.stgit@bahia.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6THr7QwYWIbrk6Kt" Content-Disposition: inline In-Reply-To: <146918576946.26293.7740314135850382852.stgit@bahia.lan> Subject: Re: [Qemu-devel] [PATCH RFC] spapr: disintricate core-id from DT semantics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Igor Mammedov , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Bharata B Rao --6THr7QwYWIbrk6Kt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 01:10:36PM +0200, Greg Kurz wrote: > The goal of this patch is to have a stable core-id which does not depend > on any DT related semantics, which involve non-obvious computations on > modern PowerPC server cpus. >=20 > With this patch, the DT core id is computed on-demand as: >=20 > (core-id / smp_threads) * smt >=20 > where smt is the number of threads per core in the host. >=20 > This formula should be consolidated in a helper since it is needed in > several places. It's a little odd you node this but don't do so. > Other uses for core-id includes: compute a stable cpu_index (which > allows random order hotplug/unplug without breaking migration) and > NUMA. >=20 > Signed-off-by: Greg Kurz > --- >=20 > It was first suggested here: >=20 > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01727.html >=20 > and as option 1) in the following discussion on IRC: >=20 > imammedo, basically the options are: 1) change core-ids to be > 0, 1, .. n and compute cpu_index as core_id * threads + thread#, or > 2) leave core-ids as they are and calculate cpu_index as > core-id / smt * threads + thread# >=20 > It is based on David's ppc-for-2.7 branch (commit bb6268f35f457). >=20 > It is lightly tested but I could at least do in-order > hotplug/unplug. I think this is basically the right approach, and I've applied to ppc-for-2.7. Here's my plan for what to do about all this id stuff: 1. Merge this to ppc-for-2.7 (done) 2. Assuming there are now show-stoppers in testing, send a pull request tomorrow 3. Once this is merged, try to get Igor's series (or a respin of it) in ASAP. I'm hoping that will give us good-enough hotplug for 2.7. In the 2.8 timeframe, I want to: 4. Disconnect KVM vcpu ID from dt_id, instead calculate it from (now stable) cpu_index 5. Remove dt_id as a cpu field - instead just compute DT ids from the (now stable) cpu_index when we build the DT 6. (for new machine type versions) Change DT ID assignment, so it no longer depends on kvmppc_smt_threads(). The current scheme means that migration between hosts with different native SMT values won't work, which is unfortunate. I suspect there may be other problems with any real situation where that's the case, but nontheless it's a silly restriction. Nice to have but bigger scope things for 2.8: 7. Update archs to they *all* call cpu_exec_init() / cpu_exec_exit() at realize / unrealize time instead of init / finalize time. 8. Update all archs and machines to use stable cpu_index --=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 --6THr7QwYWIbrk6Kt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXlas7AAoJEGw4ysog2bOSipcP/iNrCN+qbCBkmP9z1mYjpcLE FRlbXYqrua4gqH7RwYr4Qnf8lii56G62OVfGLK/1f01dlaLPWNRIjMlKzFc5OJbw +7Jv0P0zDzDD89mVYc/dMyBu6SR0tsabJmjLpojFr8+GkOvW7zfs7B3iWNAcU53p +MCTx/cqQWuAkLIEt9pRuJCgKCuI1UVEikgmunTiRsmgUrOrNhI0nH2lSEFZ4ChF hRc7yuhl7t2r3qE/Bjaer71VKxZjNR25FkU+6t3ol+W+OF/RgcRkCL/FGVn4ABFF mRHhtWpKCY3g457e9++5bD+XMKg5Nq6j0lT/HAoaErb5n73z4T83sE4TzWo2YKBU fl66SEX8u7GJdJq0zUmWfryYOJE8QEKjuNiF6aYltKdLW7V2wPtAWcqmt3IfXVpi 4WxThYOHeJpmR/5pRHWekbVCsHUMpQ8ZoTizeB0w1PKRA9KKYAc2AWP65OS07qjY s/putW76nROf+LdItLfvZwRvzilg0AkBm3s40bCk0cfC5CpNf6Rxammv2AJsZZNx 0jth9F/bkAjggVQEiyZ+gNN60Wj0fLHw02j8ZjS1SbW+Y0nsmkaLRl2WlcDQLl7g dNar/FR9uhv7Hw02YfIaEWU6R6y8MOzcxhvLa9brq5nL2l5v07VKcRY+Dik5bsbc 8ioWK8rvQwz8yvf5K2yM =RZMf -----END PGP SIGNATURE----- --6THr7QwYWIbrk6Kt--