qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object


From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object
Date: Tue, 6 Sep 2016 09:45:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]