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

[Zhang, Rui]

> --- 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