Re: [PATCH 1/2] x86/topology: Name the AMD core-type values

[Borislav Petkov]

On Mon, Jun 29, 2026 at 03:13:48PM +0530, Vishal Badole wrote:
> Replace the bare 0/1 in get_topology_cpu_type() with named constants
> that mirror what the AMD APM publishes for CPUID Fn0x80000026
> EBX[31:28] (Extended CPU Topology, Core Type):
> 
>   0 - Performance core
>   1 - Efficient core
>   2 - Low-power core (used by a follow-up)
> 
> No functional change.
> 
> Suggested-by: Borislav Petkov (AMD) <bp@xxxxxxxxx>
> Signed-off-by: Vishal Badole <Vishal.Badole@xxxxxxx>
> ---
>  arch/x86/include/asm/topology.h       | 6 ++++++
>  arch/x86/kernel/cpu/topology_common.c | 4 ++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index 0ba9bdb99871..9658b5676ce6 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -120,6 +120,12 @@ enum x86_topology_cpu_type {
>  	TOPO_CPU_TYPE_UNKNOWN,
>  };
>  
> +enum amd_cpu_type {
> +	AMD_CPU_TYPE_PERFORMANCE	= 0,

Sashiko says here:

---
  Will this break CPU matching if a driver attempts to target only AMD performance
  cores?
  The x86_cpu_id matching infrastructure treats 0 as the X86_CPU_TYPE_ANY wildcard.
  If a developer uses AMD_CPU_TYPE_PERFORMANCE (which evaluates to 0) in an
  x86_cpu_id match table, the infrastructure will interpret it as a wildcard:
  arch/x86/kernel/cpu/match.c:x86_match_vendor_cpu_type() {
  	...
  	if (m->type == X86_CPU_TYPE_ANY)
  		return true;
  	...
  }
  Could this cause drivers to silently bind to all AMD core types, including
  efficiency and low-power cores, instead of just the performance cores?
---

see https://sashiko.dev/#/patchset/20260629094349.533301-1-Vishal.Badole%40amd.com

And it does make sense to me - x86_match_vendor_cpu_type() is supposed to
receive the *hardware* defined CPU type - not the generic ones. And I think
that was a mistake because the value 0 on AMD means a performance core type
but in the kernel we called it X86_CPU_TYPE_ANY. Which is also not surprising
- all our ANY types are 0.

Now, one fix would be if we define X86_CPU_TYPE_ANY as 0xff and hope that
Intel will never define it.

On AMD that value is guaranteed to be invalid because the core type field is
only 4 bits.

But it can happen that one vendor's core type field can match another core
type of the other vendor. Which would mean that we cannot use X86_VENDOR_ANY
in any of the match_id tables when using a core type.

Or, we do the proper fix and we map all vendor core types to the kernel's,
vendor-agnostic TOPO_CPU_TYPE_* enums and then we're all good - we'd only need
to convert the vendor ones to the generic ones on comparison but we do that
anyway.

Thoughts?

> +	AMD_CPU_TYPE_EFFICIENCY		= 1,
> +	AMD_CPU_TYPE_LOW_POWER		= 2,
> +};
> +
>  struct x86_topology_system {
>  	unsigned int	dom_shifts[TOPO_MAX_DOMAIN];
>  	unsigned int	dom_size[TOPO_MAX_DOMAIN];
> diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
> index cf7513416b70..e1cc25a115ca 100644
> --- a/arch/x86/kernel/cpu/topology_common.c
> +++ b/arch/x86/kernel/cpu/topology_common.c
> @@ -42,8 +42,8 @@ enum x86_topology_cpu_type get_topology_cpu_type(struct cpuinfo_x86 *c)
>  	}
>  	if (c->x86_vendor == X86_VENDOR_AMD) {
>  		switch (c->topo.amd_type) {
> -		case 0:	return TOPO_CPU_TYPE_PERFORMANCE;
> -		case 1:	return TOPO_CPU_TYPE_EFFICIENCY;
> +		case AMD_CPU_TYPE_PERFORMANCE:	return TOPO_CPU_TYPE_PERFORMANCE;
> +		case AMD_CPU_TYPE_EFFICIENCY:	return TOPO_CPU_TYPE_EFFICIENCY;
>  		}
>  	}
>  
> -- 
> 2.34.1
> 

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette