Re: [PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime

[Julien Grall <julien@xxxxxxx>]

On 24/05/2022 07:34, Michal Orzel wrote:
> Hi Julien,
Hi Michal,

> On 23.05.2022 22:00, Julien Grall wrote:
> > On 23/05/2022 11:21, Michal Orzel wrote:
> > > Hi Julien,
> > Hi Michal,
> >
> > > On 23.05.2022 12:05, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 23/05/2022 10:13, Michal Orzel wrote:
> > > > > Introduce a command line parameter "maxcpus" on Arm to allow adjusting
> > > > > the number of CPUs to activate.
> > > > The current definition "maxcpus" is not really suitable for big.LITTLE systems 
> > > > as you have no flexibility to say how many types of each cores you want to boot.
> > > >
> > > > Instead, Xen will pick-up the first CPUs it parsed from the firmware tables.
> > > >
> > > >
> > > > So what's your use-case/target?
> > > - use cases where we have no big little (although even on big.LITTLE limiting 
> > > this number makes sense if we do not care about the types)
> > This may make sense in debug build, but for prod I think you need some 
> > certainty how which CPUs you are going to use.
> My conviction was that using big.LITTLE by enabling hmp-unsafe is not really 
> used in the production systems (after all it's called *unsafe*)
> as it may easily end up in an insecure/unstable platform without specifying the 
> cpu affinity (which must be done carefully).
>
> > So I would like a warning in the documentation "maxcpus" that in big.LITTLE 
> > system, there are no guarantee on which types will be used.
> I'm fully ok with adding this warning.
>
> **WARNING: On Arm big.LITTLE systems, when `hmp-unsafe` option is enabled, this 
> command line
> option does not guarantee on which CPU types will be used.**
NIT: s/on//

> > This is technically a lie, but I don't want a user to start relying on how Xen 
> > will parse the DT.
> >
> > > - debug cases where we want to set maxcpus=1
> > Thanks for the clarification. I would be happy to add my tag with a warning in 
> > the documentation.
> Does it mean you want to do this on commit or should I handle it in v2?
It depends whether there are other comments on the series. If there are 
none, then I will do it on commit.
I will wait until next week to give a chance to Bertrand/Stefano to comment.

Cheers,

--
Julien Grall