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 <jbeulich@suse.com>
---
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
 	range 1 16383
 	default "256" if X86
-	default "1" if ARM && MPU
-	default "8" if ARM && RCAR3
-	default "4" if ARM && QEMU
-	default "4" if ARM && MPSOC
-	default "128" if ARM
+	default "1" if !ARM || MPU
+	default "8" if RCAR3
+	default "4" if QEMU
+	default "4" if MPSOC
+	default "128"
 	help
 	  Controls the build-time size of various arrays and bitmaps
 	  associated with multiple-cpu management.  It is the upper bound of

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 <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

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.

~Michal

>  	range 1 16383
>  	default "256" if X86
> -	default "1" if ARM && MPU
> -	default "8" if ARM && RCAR3
> -	default "4" if ARM && QEMU
> -	default "4" if ARM && MPSOC
> -	default "128" if ARM
> +	default "1" if !ARM || MPU
> +	default "8" if RCAR3
> +	default "4" if QEMU
> +	default "4" if MPSOC
> +	default "128"
>  	help
>  	  Controls the build-time size of various arrays and bitmaps
>  	  associated with multiple-cpu management.  It is the upper bound of

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 <jbeulich@suse.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>

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?

Jan

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 <jbeulich@suse.com>
>> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
> 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

On 1/14/26 12:33 PM, 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 <jbeulich@suse.com>

LGTM: Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Now I have to drop the same patch from my list. Likely I checked my e-mail
before sending it.

~ Oleksii