Re: [Qemu-ppc] [PATCH] ppc/pnv: fix cores per chip for multiple cpus

[Cédric Le Goater]

On 09/22/2017 12:12 PM, David Gibson wrote:
> On Fri, Sep 22, 2017 at 08:07:06AM +0200, Cédric Le Goater wrote:
>> On 09/22/2017 08:00 AM, Nikunj A Dadhania wrote:
>>> David Gibson <address@hidden> writes:
>>>
>>>>>>>
>>>>>>> As smp_thread defaults to 1 in vl.c, similarly smp_cores also has the
>>>>>>> default value of 1 in vl.c. In powernv, we were setting nr-cores like
>>>>>>> this:
>>>>>>>
>>>>>>>         object_property_set_int(chip, smp_cores, "nr-cores", 
>>>>>>> &error_fatal);
>>>>>>>
>>>>>>> Even when there were multiple cpus (-smp 4), when the guest boots up, we
>>>>>>> just get one core (i.e. smp_cores was 1) with single thread(smp_threads
>>>>>>> was 1), which is wrong as per the command-line that was provided.
>>>>>>
>>>>>> Right, so, -smp 4 defaults to 4 sockets, each with 1 core of 1
>>>>>> thread.  If you can't supply 4 sockets you should error, but you
>>>>>> shouldn't go and change the number of cores per socket.
>>>>>
>>>>> OK, that makes sense now. And I do see that smp_cpus is 4 in the above
>>>>> case. Now looking more into it, i see that powernv has something called
>>>>> "num_chips", isnt this same as sockets ? Do we need num_chips separately?
>>>>
>>>> Ah, yes, I see.  It's probably still reasonable to keep num_chips as
>>>> an internal variable, rather than using (smp_cpus / smp_cores /
>>>> smp_threads) everywhere.  But we shouldn't have it as a direct
>>>> user-settable property, instead setting it from the -smp command line
>>>> option.
>>>
>>> Something like the below works till num_chips=2, after that guest does
>>> not boot up. This might be some limitation within the OS, Cedric might
>>> have some clue.
>>
>> Some controllers might need some more tweaking, PSI, LPC, to elect a 
>> master one.
> 
> Uh.. why?

that's not true. I managed to boot a pnv machine with 4 chips/sockets 
each having 4 cpus using a 4.4.9-openpower2 skiroot kernel, from an 
openpower firmare 1.10 I think. Recent openpower kernel must be using 
some new features/instructions that we don't manage well in QEMU.

I would need to build a kernel with more output.

>> Anyhow I don't think we want to deduce the number of chips
>> from the number of cpus. These two figures are very different.
> 
> How so?  It's not totally perfect, but making a single chip correspond
> to a "socket" in qemu's (somewhat x86 centric) terminology is still a
> pretty good match.

well, it would be good to be able to define chips with different
numbers of cpus. That is something will we want to do for sure.

Thanks,

C.