From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQW3K-0001LF-45 for qemu-devel@nongnu.org; Fri, 22 Jul 2016 04:43:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQW3D-00076I-4J for qemu-devel@nongnu.org; Fri, 22 Jul 2016 04:43:24 -0400 Received: from 2.mo178.mail-out.ovh.net ([46.105.39.61]:52536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQW3C-00075v-R4 for qemu-devel@nongnu.org; Fri, 22 Jul 2016 04:43:19 -0400 Received: from player169.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 767C61004DCF for ; Fri, 22 Jul 2016 10:43:15 +0200 (CEST) Date: Fri, 22 Jul 2016 10:42:53 +0200 From: Greg Kurz Message-ID: <20160722104253.1957a5d4@bahia.lan> In-Reply-To: <20160722071433.GX15941@voom.fritz.box> References: <1469116479-233280-1-git-send-email-imammedo@redhat.com> <1469116479-233280-7-git-send-email-imammedo@redhat.com> <20160722032301.GG15941@voom.fritz.box> <20160722061003.GD7036@in.ibm.com> <20160722071433.GX15941@voom.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/07w++.OpTJH1OtawNiZJP7Z"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 6/8] spapr: init CPUState->cpu_index with index relative to core-id List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Bharata B Rao , Riku Voipio , Eduardo Habkost , Peter Crosthwaite , "Michael S. Tsirkin" , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini , Igor Mammedov , Richard Henderson --Sig_/07w++.OpTJH1OtawNiZJP7Z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 22 Jul 2016 17:14:33 +1000 David Gibson wrote: > On Fri, Jul 22, 2016 at 11:40:03AM +0530, Bharata B Rao wrote: > > On Fri, Jul 22, 2016 at 01:23:01PM +1000, David Gibson wrote: =20 > > > On Thu, Jul 21, 2016 at 05:54:37PM +0200, Igor Mammedov wrote: =20 > > > > It will enshure that cpu_index for a given cpu stays the same > > > > regardless of the order cpus has been created/deleted and so > > > > it would be possible to migrate QEMU instance with out of order > > > > created CPU. > > > >=20 > > > > Signed-off-by: Igor Mammedov =20 > > >=20 > > > So, this isn't quite right (it wasn't right in my version either). > > >=20 > > > The problem occurs when smp_threads < kvmppc_smt_threads(). That is, > > > when the requested threads-per-core is less than the hardware's > > > maximum number of threads-per-core. > > >=20 > > > The core-id values are assigned essentially as i * > > > kvmppc_smt_threads(), meaning the patch below will leave gaps in the > > > cpu_index values and the last ones will exceed max_cpus, causing other > > > problems. =20 > >=20 > > This would lead to hotplug failures as cpu_dt_id is still being > > derived from non-contiguous cpu_index resulting in wrong enumeration > > of CPU nodes in DT. =20 >=20 > Which "This" are you referring to? >=20 > >=20 > > For -smp 8,threads=3D4 we see the following CPU nodes in DT > >=20 > > PowerPC,POWER8@0 PowerPC,POWER8@10 > >=20 > > which otherwise should have been > >=20 > > PowerPC,POWER8@0 PowerPC,POWER8@8 > >=20 > > The problem manifests as drmgr failure. > >=20 > > Greg's patchset that moved cpu_dt_id setting to machine code and that > > derived cpu_dt_id from core-id for sPAPR would be needed to fix this > > I guess. =20 >=20 > No, it shouldn't be necessary to fix it. But we certainly do want to > clean this stuff up. I'm not terribly convinced by the current > approach in Greg's series though. I'd actually prefer to remove > cpu_dt_id from the cpustate entirely and instead work it out from the That was the initial plan for my series :) > (now stable) cpu index when we go to construct the device tree. >=20 Patch 5/8 provides a stable cpu_index for the pc machine type out of the index in possible_cpus[]. Since we also store cores and threads in fixed size arrays, we could easily follow the same logic:=20 index_of_core_in_spapr_cores * smp_threads + index_of_thread_in_core_threads Cheers. -- Greg --Sig_/07w++.OpTJH1OtawNiZJP7Z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAleR3I0ACgkQAvw66wEB28KeUwCfQ4b7leRKel/VXQox2mYYcyn1 X4EAn1dLn/v66hPtZfFbXiWwfeVdWu0x =2b1Z -----END PGP SIGNATURE----- --Sig_/07w++.OpTJH1OtawNiZJP7Z--