On 26/01/2026 11:13, Jan Beulich wrote:
> On 26.01.2026 11:08, Orzel, Michal wrote:
>> On 14/01/2026 12:33, Jan Beulich wrote:
>>> Discussion of a RISC-V change revealed that for PPC and RISC-V we don't
>>> really set any default, but rather rely on internals of kconfig picking
>>> the lowest of the permitted values in such a case. Let's make this
>>> explicit, requiring architectures that mean to permit SMP by default to
>>> explicitly record some sensible value here.
>>>
>>> Leverage the adjustment to the "1" case to simplify all subsequent ones.
>>>
>>> Signed-off-by: Jan Beulich <[email protected]>
>> Reviewed-by: Michal Orzel <[email protected]>
>
> Thanks.
>
>> with one question...
>>
>>> ---
>>> For not-yet-SMP-capable ports we might go even further and use
>>>
>>> range 1 1 if !X86 && (!ARM || MPU)
>>>
>>> at the top. Thoughts? (I've not done this right away as it is liable to
>>> get unwieldy when we have a larger number of SMP-capable ports.)
>>>
>>> --- a/xen/arch/Kconfig
>>> +++ b/xen/arch/Kconfig
>>> @@ -9,11 +9,11 @@ config NR_CPUS
>>> range 1 1 if ARM && MPU
>> Why not simply && MPU given that MPU is an ARM specific option in our
>> Kconfig.
>
> Good question, to be answered by whoever put this here. I guess the
> anticipation
> may have been that "MPU" might end up meaning something else on another arch,
> at
> some future point?
Except for this specific case, there is no other use of MPU in non-arch Kconfig
or code, so it's difficult to say. I would be more willing to tie it to Arm, so
that we don't need ARM/CONFIG_ARM before MPU/CONFIG_MPU.
~Michal
