From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhB4z-0000SY-Q2 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 03:46:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhB4s-0001yA-4a for qemu-devel@nongnu.org; Tue, 06 Sep 2016 03:46:00 -0400 Received: from 12.mo6.mail-out.ovh.net ([178.32.125.228]:55018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhB4r-0001xn-VX for qemu-devel@nongnu.org; Tue, 06 Sep 2016 03:45:54 -0400 Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id E7D66FF94CD for ; Tue, 6 Sep 2016 09:45:52 +0200 (CEST) References: <1470388537-2908-1-git-send-email-clg@kaod.org> <1470388537-2908-4-git-send-email-clg@kaod.org> <20160816023900.GC14530@voom.fritz.box> <330ecf9d-6750-4b5f-ea5d-660e3f6a11d0@kaod.org> <20160829143021.GF2166@littlecatz> <1472537735.2388.32.camel@kernel.crashing.org> <168c7ae5-588d-23c6-7e51-79299c06431f@kaod.org> <20160905014505.GD2587@voom.fritz.box> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: Date: Tue, 6 Sep 2016 09:45:46 +0200 MIME-Version: 1.0 In-Reply-To: <20160905014505.GD2587@voom.fritz.box> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Benjamin Herrenschmidt , qemu-ppc@nongnu.org, Alexander Graf , qemu-devel@nongnu.org On 09/05/2016 03:45 AM, David Gibson wrote: > On Tue, Aug 30, 2016 at 09:23:40AM +0200, C=E9dric Le Goater wrote: >> On 08/30/2016 08:15 AM, Benjamin Herrenschmidt wrote: >>> On Mon, 2016-08-29 at 10:30 -0400, David Gibson wrote: >>>> >>>> Possibly. In fact, I'm planning to eliminate cpu->cpu_dt_id at some >>>> point, in favour of having the machine type construct the id when it >>>> actually builds the dt. It's not really a cpu level construct. >> >> >From my understanding, cs->cpu_index is becoming the main CPU identif= ier. >> sPAPRCPUCore assigns it : >> >> cs->cpu_index =3D cc->core_id + i >=20 > Uh.. yes and no. It's the main internal identifier, and it's become > stable at least on platforms which support cpu hotplug. This means > that it should be possible to derive any other platform specific > identifiers from cpu_index in a consistent way. >=20 > However, cpu_index values must still lie in the range 0..max_cpus-1, > which means it's not suitable for directly representing non-contiguous > platform identifiers. ah ok. So I might be doing something wrong on the pnv platform. As cc->core_id contains the cpu pir and cs->cpu_index is assigned doing: cs->cpu_index =3D cc->core_id + i It is useful to compute the threads pir but causes some issues in xics. These are solved with a couple of helpers to look for the ICPState*=20 using the CPUState* as an index.=20 I will see if I can adapt pnv to use a contiguous cpu_index.=20 Thanks, C.=20