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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3083 bytes --]

On Fri, Sep 22, 2017 at 12:46:58PM +0200, Cédric Le Goater wrote:
> 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 <david@gibson.dropbear.id.au> 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.

You mean multiple chips in a single system with non-uniform numbers of
cores?  Are there really such systems in the wild?

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]