| Message ID | 20220812164144.30829-3-rui.zhang@intel.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | x86/topology: Improve CPUID.1F handling | expand |
diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index f7592814e5d5..5e868b62a7c4 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -141,7 +141,7 @@ int detect_extended_topology(struct cpuinfo_x86 *c) sub_index++; } - core_select_mask = (~(-1 << core_plus_mask_width)) >> ht_mask_width; + core_select_mask = (~(-1 << pkg_mask_width)) >> ht_mask_width; die_select_mask = (~(-1 << die_plus_mask_width)) >> core_plus_mask_width;
Today, core_id is assumed to be unique within each package. But an AlderLake-N platform adds a Module level between core and package, Linux excludes the unknown modules bits from the core_id, resulting in duplicate core_id's. To keep core_id unique within a package, Linux must include all APIC-id bits for known or un-known levels above the core and below the package in the core_id. It is important to understand that core_id's have always come directly from the APIC-id encoding, which comes from the BIOS. Thus there is no guarantee that they start at 0, or that they are contiguous. As such, using them for array indexes can be problematic. Suggested-and-reviewed-by: Len Brown <len.brown@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> --- arch/x86/kernel/cpu/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)