Re: [patch 53/53] x86/cpu/topology: Get rid of cpuinfo::x86_max_cores

Zhang, Rui
2023-12-14T14:00:30Z

> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -566,7 +566,7 @@ static void __init build_sched_topology(
>  void set_cpu_sibling_map(int cpu)
>  {
>         bool has_smt = topology_smt_supported();
> -       bool has_mp = has_smt || boot_cpu_data.x86_max_cores > 1;
> +       bool has_mp = has_smt || topology_num_cores_per_package() >
> 1;

This patch series, especially the change here, indeed fixes a bug
observed on a platform with below cpuid.1f output,

# taskset -c 0 cpuid -1 -l 0x1f -s 0
CPU:
V2 extended topology (0x1f):
x2APIC ID of logical processor = 0x0 (0)
--- level 0 ---
level number = 0x0 (0)
level type = thread (1)
bit width of level & previous levels = 0x1 (1)
number of logical processors at level = 0x1 (1)
# taskset -c 0 cpuid -1 -l 0x1f -s 1
CPU:
--- level 1 ---
level number = 0x1 (1)
level type = core (2)
bit width of level & previous levels = 0x3 (3)
number of logical processors at level = 0x1 (1)
# taskset -c 0 cpuid -1 -l 0x1f -s 2
CPU:
--- level 2 ---
level number = 0x2 (2)
level type = module (3)
bit width of level & previous levels = 0x7 (7)
number of logical processors at level = 0x18 (24)

The bug is that, on this platform, without this patch series,
1. has_smt is false because there is indeed no HT
2. has_mp is false because
1. core_level_siblings from CPUID.1F Core level EBX is 1
2. current code does not parse Module type and use
core_level_siblings as the number_of_cpus_in_a_package, so
boot_cpu_data.x86_max_cores =
core_level_siblings / smp_num_siblings = 1

As a result, set_cpu_sibling_map() assumes this is a UP system and does
not update any sibling maps, the topology is totally broken then.

thanks,
rui