[PATCH] riscv: Populate boot CPU topology on UP kernels

[PATCH] riscv: Populate boot CPU topology on UP kernels

[Chen Pei]

RISC-V selects GENERIC_ARCH_TOPOLOGY unconditionally, so the topology
cpumask accessors resolve into cpu_topology[]. The RISC-V calls to
init_cpu_topology() and store_cpu_topology() are in smpboot.c, which is
only built with CONFIG_SMP. On UP kernels, cpu_topology[] remains
zero-initialized and its sibling masks are empty.

The sysfs topology interface is available on UP kernels too. As a
result, cpu0 exports empty thread_siblings_list and core_siblings_list
attributes rather than masks containing itself, violating the expected
topology semantics of this stable ABI.

Initialize and store the boot CPU topology in a UP-only early initcall.
This runs after DT and ACPI CPU discovery and after the memory allocator
is available, before the topology is exposed through sysfs.

SMP kernels continue to initialize topology in smp_prepare_cpus(). NUMA
needs no additional handling because it depends on SMP.

Fixes: fbd92809997a ("riscv: topology: fix default topology reporting")
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
Tested on QEMU virt (RV64):
- UP, default DT: cpu0 thread_siblings_list, core_cpus_list,
  core_siblings_list and package_cpus_list all contain CPU0.
- UP, DT with 32 KiB L1 instruction/data caches: the same topology
  checks pass, and both caches appear in sysfs with shared_cpu_list=0.
- SMP, 8 CPUs: each CPU's thread_siblings_list and core_cpus_list
  contain itself; core_siblings_list and package_cpus_list are 0-7.

 arch/riscv/kernel/setup.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index d79f99b86033..234d9af414b7 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/arch_topology.h>
 #include <linux/cpu.h>
 #include <linux/init.h>
 #include <linux/mm.h>
@@ -370,6 +371,17 @@ void __init setup_arch(char **cmdline_p)
 	riscv_clear_hypervisor_csr();
 }
 
+#ifndef CONFIG_SMP
+static int __init riscv_init_cpu_topology(void)
+{
+	init_cpu_topology();
+	store_cpu_topology(0);
+
+	return 0;
+}
+early_initcall(riscv_init_cpu_topology);
+#endif
+
 bool arch_cpu_is_hotpluggable(int cpu)
 {
 	return cpu_has_hotplug(cpu);

-- 
2.50.1

Re: [PATCH] riscv: Populate boot CPU topology on UP kernels

[Guo Ren]

On Mon, Oct 12, 2026 at 9:11 PM Chen Pei <cp0613@linux.alibaba.com> wrote:
>
> RISC-V selects GENERIC_ARCH_TOPOLOGY unconditionally, so the topology
> cpumask accessors resolve into cpu_topology[]. The RISC-V calls to
> init_cpu_topology() and store_cpu_topology() are in smpboot.c, which is
> only built with CONFIG_SMP. On UP kernels, cpu_topology[] remains
> zero-initialized and its sibling masks are empty.
>
> The sysfs topology interface is available on UP kernels too. As a
> result, cpu0 exports empty thread_siblings_list and core_siblings_list
> attributes rather than masks containing itself, violating the expected
> topology semantics of this stable ABI.
>
> Initialize and store the boot CPU topology in a UP-only early initcall.
> This runs after DT and ACPI CPU discovery and after the memory allocator
> is available, before the topology is exposed through sysfs.
>
> SMP kernels continue to initialize topology in smp_prepare_cpus(). NUMA
> needs no additional handling because it depends on SMP.
>
> Fixes: fbd92809997a ("riscv: topology: fix default topology reporting")
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
> Tested on QEMU virt (RV64):
> - UP, default DT: cpu0 thread_siblings_list, core_cpus_list,
>   core_siblings_list and package_cpus_list all contain CPU0.
> - UP, DT with 32 KiB L1 instruction/data caches: the same topology
>   checks pass, and both caches appear in sysfs with shared_cpu_list=0.
> - SMP, 8 CPUs: each CPU's thread_siblings_list and core_cpus_list
>   contain itself; core_siblings_list and package_cpus_list are 0-7.
>
>  arch/riscv/kernel/setup.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index d79f99b86033..234d9af414b7 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -9,6 +9,7 @@
>   */
>
>  #include <linux/acpi.h>
> +#include <linux/arch_topology.h>
>  #include <linux/cpu.h>
>  #include <linux/init.h>
>  #include <linux/mm.h>
> @@ -370,6 +371,17 @@ void __init setup_arch(char **cmdline_p)
>         riscv_clear_hypervisor_csr();
>  }
>
> +#ifndef CONFIG_SMP
> +static int __init riscv_init_cpu_topology(void)
> +{
> +       init_cpu_topology();
> +       store_cpu_topology(0);
> +
> +       return 0;
> +}
> +early_initcall(riscv_init_cpu_topology);
> +#endif
> +

Good catch. Although CONFIG_SMP is enabled by default (default y), we
should still set the cpumask to BIT(0), so the cpumask stays valid
even when SMP is disabled.

Reviewed-by: GUO Ren <guoren@kernel.org>

-- 
Best Regards
 Guo Ren

Re: [PATCH] riscv: Populate boot CPU topology on UP kernels

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

On Mon, Oct 12, 2026 at 09:10:33PM +0800, Chen Pei wrote:
> RISC-V selects GENERIC_ARCH_TOPOLOGY unconditionally, so the topology
> cpumask accessors resolve into cpu_topology[]. The RISC-V calls to
> init_cpu_topology() and store_cpu_topology() are in smpboot.c, which is
> only built with CONFIG_SMP. On UP kernels, cpu_topology[] remains
> zero-initialized and its sibling masks are empty.

I'm curious about arm64 since they've got the same as us as far as I
know. Is the same issue there or are they solving it in a different way?

Cheers,
Conor.

> 
> The sysfs topology interface is available on UP kernels too. As a
> result, cpu0 exports empty thread_siblings_list and core_siblings_list
> attributes rather than masks containing itself, violating the expected
> topology semantics of this stable ABI.
> 
> Initialize and store the boot CPU topology in a UP-only early initcall.
> This runs after DT and ACPI CPU discovery and after the memory allocator
> is available, before the topology is exposed through sysfs.
> 
> SMP kernels continue to initialize topology in smp_prepare_cpus(). NUMA
> needs no additional handling because it depends on SMP.
> 
> Fixes: fbd92809997a ("riscv: topology: fix default topology reporting")
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
> ---
> Tested on QEMU virt (RV64):
> - UP, default DT: cpu0 thread_siblings_list, core_cpus_list,
>   core_siblings_list and package_cpus_list all contain CPU0.
> - UP, DT with 32 KiB L1 instruction/data caches: the same topology
>   checks pass, and both caches appear in sysfs with shared_cpu_list=0.
> - SMP, 8 CPUs: each CPU's thread_siblings_list and core_cpus_list
>   contain itself; core_siblings_list and package_cpus_list are 0-7.
> 
>  arch/riscv/kernel/setup.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index d79f99b86033..234d9af414b7 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -9,6 +9,7 @@
>   */
>  
>  #include <linux/acpi.h>
> +#include <linux/arch_topology.h>
>  #include <linux/cpu.h>
>  #include <linux/init.h>
>  #include <linux/mm.h>
> @@ -370,6 +371,17 @@ void __init setup_arch(char **cmdline_p)
>  	riscv_clear_hypervisor_csr();
>  }
>  
> +#ifndef CONFIG_SMP
> +static int __init riscv_init_cpu_topology(void)
> +{
> +	init_cpu_topology();
> +	store_cpu_topology(0);
> +
> +	return 0;
> +}
> +early_initcall(riscv_init_cpu_topology);
> +#endif
> +
>  bool arch_cpu_is_hotpluggable(int cpu)
>  {
>  	return cpu_has_hotplug(cpu);
> 
> -- 
> 2.50.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] riscv: Populate boot CPU topology on UP kernels

[Sudeep Holla]

On Tue, Oct 20, 2026 at 11:23:34AM +0100, Conor Dooley wrote:
> On Mon, Oct 12, 2026 at 09:10:33PM +0800, Chen Pei wrote:
> > RISC-V selects GENERIC_ARCH_TOPOLOGY unconditionally, so the topology
> > cpumask accessors resolve into cpu_topology[]. The RISC-V calls to
> > init_cpu_topology() and store_cpu_topology() are in smpboot.c, which is
> > only built with CONFIG_SMP. On UP kernels, cpu_topology[] remains
> > zero-initialized and its sibling masks are empty.
> 
> I'm curious about arm64 since they've got the same as us as far as I
> know. Is the same issue there or are they solving it in a different way?
> 

Commit 4b3dc9679cf7 ("arm64: force CONFIG_SMP=y and remove redundant #ifdefs")
removed UP support and made SMP default enabled.

-- 
Regards,
Sudeep

Re: [PATCH] riscv: Populate boot CPU topology on UP kernels

[Chen Pei]

On Tue, Oct 20, 2026 at 01:24:00PM +0100, Sudeep Holla wrote:
> Commit 4b3dc9679cf7 ("arm64: force CONFIG_SMP=y and remove redundant #ifdefs")
> removed UP support and made SMP default enabled.

Thanks. RISC-V still allows UP: CONFIG_SMP is a plain bool with no
default, yet arch/riscv/Kconfig selects GENERIC_ARCH_TOPOLOGY
unconditionally while the only callers of init_cpu_topology() and
store_cpu_topology() sit in smpboot.c, which is built only for
CONFIG_SMP. That mismatch is what this patch closes.

Gating that select on SMP instead does not work. UP would then fall back
to the cpumask_of(cpu) defaults in include/linux/topology.h and report
the same sysfs, but vmlinux no longer links: arch_freq_scale,
capacity_freq_ref, topology_scale_freq_tick and topology_set_freq_scale
all become undefined references.

arch/riscv/include/asm/topology.h binds the arch_scale_freq_* and
arch_set_freq_scale hooks to symbols that only drivers/base/arch_topology.c
provides, and those defines suppress the generic fallbacks in
kernel/sched/sched.h and include/linux/sched/topology.h. Making the
gating work needs extra conditionals at several Kconfig and Makefile
gates, and gives up freq and capacity invariance on UP, which is a much
larger change than the twelve lines here.

Conor, and RISC-V maintainers: would you rather force CONFIG_SMP=y on
RISC-V as well and drop UP altogether, or keep UP buildable and take
this fix? I would keep the current approach unless you prefer the
former.

Best regards,
Pei