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

[Michal Orzel <michal.orzel@xxxxxxx>]

Hi Julien,

Gentle ping asking to reply to my previous mail.

On 24.05.2022 08:34, Michal Orzel wrote:
> Hi Julien,
> 
> 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.**
> 
>>
>> 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?
> 
>> Cheers,
>>
> 
> Cheers,
> Michal
>