On 09/05/2016 03:45 AM, David Gibson wrote:
> On Tue, Aug 30, 2016 at 09:23:40AM +0200, Cédric 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 identifier.
>> sPAPRCPUCore assigns it :
>>
>> cs->cpu_index = cc->core_id + i
>
> 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.
>
> 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 = 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*
using the CPUState* as an index.
I will see if I can adapt pnv to use a contiguous cpu_index.
Thanks,
C.
