From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQUfS-00042m-VK for qemu-devel@nongnu.org; Fri, 22 Jul 2016 03:14:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQUfR-000648-G9 for qemu-devel@nongnu.org; Fri, 22 Jul 2016 03:14:42 -0400 Date: Fri, 22 Jul 2016 17:14:33 +1000 From: David Gibson Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E0IhBwMLbrMClE+H" Content-Disposition: inline In-Reply-To: <20160722061003.GD7036@in.ibm.com> Subject: Re: [Qemu-devel] [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: Bharata B Rao Cc: Igor Mammedov , qemu-devel@nongnu.org, Paolo Bonzini , Peter Crosthwaite , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Alexander Graf , Riku Voipio , qemu-ppc@nongnu.org --E0IhBwMLbrMClE+H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > On Thu, Jul 21, 2016 at 05:54:37PM +0200, Igor Mammedov wrote: > > > 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 > > 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 > 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. Which "This" are you referring to? >=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. 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 (now stable) cpu index when we go to construct the device tree. --=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 --E0IhBwMLbrMClE+H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXkcfZAAoJEGw4ysog2bOSPvIQALp+gmFZ72mZZDqAkHuvGEyV nx47LiQrPmj8TmX6jyZAjV1EdbBhGuXyfQ4WsRwbUYOvt4LqXTLDjt6uKgoIOr1M b6fPfpQHICOpSOgj8CRvGYxP190Ujgh3uVUwxYngLGDVetrLLEFQ6VfRm6hZ2aQ8 Q1/KRaQ7Rl8QL0+a7AxUVBErj/O5rpm7avFF966nhDUDj3xyaBns5fP67jY9DouM iWc/2h0AQUlfXPQiNy4EWLKdzlXTQpdyQIZA5TzMspXso1LOW6aq1Ny4qxLbTM9o IOr3PiNZSl1gE5DazohkHh3/zJT6hdoUWXaDZnvkSDChydxb+GyCkWJggH2B4v86 ODB2x4H+Czu3F5e0Gh0Df3g4DO1Gq9iUuRIl+hugiMTEbqH9kU5J2KK4PtaB+fh/ RbEsPbkmhhOiDkIgZd4Ls2aTW0E7fZ8O33eakYjDxokmiZQUz3s/hdIxNrfmv6M1 dX8+pnQX7dOk1m2IL5zWoXmnSLMhuZN8YgnzRfSXgOMYbGDDrSo7Jf2FcbqEY+zP /6Jq9ZYg8QVQFeBWBKln7uAY9uGccDTiFMaNJNqixgf6FOmBkob3Q6VZL9GnXkNw txV56J8u1Zgv0v26VL4RuH7dvw6L0vlq1GwpZaCXr3K21S4eCxpo9SBva/5RRww0 gHbr4Ek2/NPGxzV4XycH =bek4 -----END PGP SIGNATURE----- --E0IhBwMLbrMClE+H--