[PATCH] kconfig: adjust NR_CPUS defaults

Jan Beulich posted 1 patch 1 week, 4 days ago
Failed in applying to current master (apply log)
[PATCH] kconfig: adjust NR_CPUS defaults
Posted by Jan Beulich 1 week, 4 days ago
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
Re: [PATCH] kconfig: adjust NR_CPUS defaults
Posted by Oleksii Kurochko 3 days, 13 hours ago
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