[PATCH 0/2] x86/topology: Add support for Low Power cpu_type

[PATCH 0/2] x86/topology: Add support for Low Power cpu_type

[Vishal Badole]

This series extends the x86 topology cpu_type classification to support
a Low Power core type, in addition to the existing Performance and
Efficiency types.

AMD heterogeneous parts report the core type via CPUID Fn0x80000026
EBX[31:28] (Extended CPU Topology, Core Type). Value 2 identifies a
low-power core designed for minimal power consumption during background
or idle workloads. Distinguishing it from a regular efficiency core
matters for:

  - user space exposure via /sys/kernel/debug/x86/topo/cpus/*, which
    today reports cpu_type "unknown" for low-power cores

  - amd_get_boost_ratio_numerator(): on every
    X86_FEATURE_AMD_HTR_CORES-capable AMD/Hygon part, low-power cores
    must scale by amd_get_highest_perf() rather than the fixed
    CPPC_HIGHEST_PERF_PERFORMANCE ceiling, matching the existing
    efficiency-core path

The series is structured as:

  1/2 Pre-patch: replace the bare 0/1 in get_topology_cpu_type() with
      named enum amd_cpu_type constants, mirroring the existing Intel
      side. No functional change.

  2/2 Add TOPO_CPU_TYPE_LOW_POWER, wire it through
      get_topology_cpu_type(), get_topology_cpu_type_name() and the
      switch in amd_get_boost_ratio_numerator() so allmodconfig builds
      cleanly under -Werror=switch.

Vishal Badole (2):
  x86/topology: Name the AMD core-type values
  x86/topology: Add TOPO_CPU_TYPE_LOW_POWER

 arch/x86/include/asm/topology.h       | 7 +++++++
 arch/x86/kernel/acpi/cppc.c           | 3 ++-
 arch/x86/kernel/cpu/topology_common.c | 7 +++++--
 3 files changed, 14 insertions(+), 3 deletions(-)

-- 
2.34.1

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

[Vishal Badole]

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@alien8.de>
Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
---
 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,
+	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

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@alien8.de>
> Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
> ---
>  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

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

[Thomas Gleixner]

On Wed, Jul 01 2026 at 17:27, Borislav Petkov wrote:
> On Mon, Jun 29, 2026 at 03:13:48PM +0530, Vishal Badole wrote:
> 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.

Just do the mapping to vendor-agnostic types _once_ when you enumerate the CPU
and store that information in the per CPU data.

Then you can do proper vendor agnostic matching against that and define
the TYPE_ANY value as you want without ever colliding with vendor
muck.

As a bonus get_topology_cpu_type() goes away too as the translation has
been done already.

Thanks,

        tglx

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

[Borislav Petkov]

On Fri, Jul 03, 2026 at 12:06:32AM +0200, Thomas Gleixner wrote:
> Just do the mapping to vendor-agnostic types _once_ when you enumerate the CPU
> and store that information in the per CPU data.
> 
> Then you can do proper vendor agnostic matching against that and define
> the TYPE_ANY value as you want without ever colliding with vendor
> muck.
> 
> As a bonus get_topology_cpu_type() goes away too as the translation has
> been done already.

Yeah, we should've done it from the very beginning this way. Lemme hack it up
and see how it looks like.

Thanks for the cool idea.

-- 
Regards/Gruss,
    Boris.

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

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

[Borislav Petkov]

+ Dave and Pawan.

On Thu, Jul 02, 2026 at 04:03:37PM -0700, Borislav Petkov wrote:
> On Fri, Jul 03, 2026 at 12:06:32AM +0200, Thomas Gleixner wrote:
> > Just do the mapping to vendor-agnostic types _once_ when you enumerate the CPU
> > and store that information in the per CPU data.
> > 
> > Then you can do proper vendor agnostic matching against that and define
> > the TYPE_ANY value as you want without ever colliding with vendor
> > muck.
> > 
> > As a bonus get_topology_cpu_type() goes away too as the translation has
> > been done already.
> 
> Yeah, we should've done it from the very beginning this way. Lemme hack it up
> and see how it looks like.
> 
> Thanks for the cool idea.

Something like the totally untested below - but it builds at least.

We've allocated a u8 for the struct x86_cpu_id member type and we compare that
to enum x86_topology_cpu_type cpu_type. I guess that's ok for now...

There's potential for more cleanup by removing the ->intel_type and ->amd_type
and converting them all to our internal represenation of CPU_TYPE but that's
for later and other patches anyway.

Thoughts?

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 8d8f890c4bc0..746822bd71fb 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -68,9 +68,13 @@ extern u16 __read_mostly tlb_lld_2m;
 extern u16 __read_mostly tlb_lld_4m;
 extern u16 __read_mostly tlb_lld_1g;
 
-/*
- * CPU type and hardware bug flags. Kept separately for each CPU.
- */
+enum x86_topology_cpu_type {
+	/* X86_CPU_TYPE_ANY */
+	TOPO_CPU_TYPE_ANY = 0,
+	TOPO_CPU_TYPE_PERFORMANCE,
+	TOPO_CPU_TYPE_EFFICIENCY,
+	TOPO_CPU_TYPE_UNKNOWN,
+};
 
 struct cpuinfo_topology {
 	// Real APIC ID read from the local APIC
@@ -104,7 +108,7 @@ struct cpuinfo_topology {
 
 	// Hardware defined CPU-type
 	union {
-		u32		cpu_type;
+		u32		hw_cpu_type;
 		struct {
 			// CPUID.1A.EAX[23-0]
 			u32	intel_native_model_id	:24;
@@ -119,8 +123,14 @@ struct cpuinfo_topology {
 				amd_type		:4;
 		};
 	};
+
+	// Linux vendor-agnostic CPU type
+	enum x86_topology_cpu_type cpu_type;
 };
 
+/*
+ * CPU type and hardware bug flags. Kept separately for each CPU.
+ */
 struct cpuinfo_x86 {
 	union {
 		/*
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 8fb61d2465eb..ef76ba674f1b 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -114,12 +114,6 @@ enum x86_topology_domains {
 	TOPO_MAX_DOMAIN,
 };
 
-enum x86_topology_cpu_type {
-	TOPO_CPU_TYPE_PERFORMANCE,
-	TOPO_CPU_TYPE_EFFICIENCY,
-	TOPO_CPU_TYPE_UNKNOWN,
-};
-
 struct x86_topology_system {
 	unsigned int	dom_shifts[TOPO_MAX_DOMAIN];
 	unsigned int	dom_size[TOPO_MAX_DOMAIN];
@@ -160,7 +154,6 @@ extern unsigned int __num_nodes_per_package;
 struct cpuinfo_x86;
 
 const char *get_topology_cpu_type_name(struct cpuinfo_x86 *c);
-enum x86_topology_cpu_type get_topology_cpu_type(struct cpuinfo_x86 *c);
 
 static inline unsigned int topology_max_packages(void)
 {
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index be4c5e9e5ff6..b8f5dd0a8117 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -241,7 +241,6 @@ EXPORT_SYMBOL_GPL(amd_detect_prefcore);
  */
 int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 {
-	enum x86_topology_cpu_type core_type = get_topology_cpu_type(&cpu_data(cpu));
 	bool prefcore;
 	int ret;
 	u32 tmp;
@@ -273,8 +272,9 @@ int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 
 	/* detect if running on heterogeneous design */
 	if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) {
-		switch (core_type) {
+		switch (cpu_data(cpu).topo.cpu_type) {
 		case TOPO_CPU_TYPE_UNKNOWN:
+		case TOPO_CPU_TYPE_ANY:
 			pr_warn("Undefined core type found for cpu %d\n", cpu);
 			break;
 		case TOPO_CPU_TYPE_PERFORMANCE:
diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
index 4604802692da..7ab077f0cc66 100644
--- a/arch/x86/kernel/cpu/match.c
+++ b/arch/x86/kernel/cpu/match.c
@@ -5,34 +5,6 @@
 #include <linux/export.h>
 #include <linux/slab.h>
 
-/**
- * x86_match_vendor_cpu_type - helper function to match the hardware defined
- *                             cpu-type for a single entry in the x86_cpu_id
- *                             table. Note, this function does not match the
- *                             generic cpu-types TOPO_CPU_TYPE_EFFICIENCY and
- *                             TOPO_CPU_TYPE_PERFORMANCE.
- * @c: Pointer to the cpuinfo_x86 structure of the CPU to match.
- * @m: Pointer to the x86_cpu_id entry to match against.
- *
- * Return: true if the cpu-type matches, false otherwise.
- */
-static bool x86_match_vendor_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m)
-{
-	if (m->type == X86_CPU_TYPE_ANY)
-		return true;
-
-	/* Hybrid CPUs are special, they are assumed to match all cpu-types */
-	if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU))
-		return true;
-
-	if (c->x86_vendor == X86_VENDOR_INTEL)
-		return m->type == c->topo.intel_type;
-	if (c->x86_vendor == X86_VENDOR_AMD)
-		return m->type == c->topo.amd_type;
-
-	return false;
-}
-
 /**
  * x86_match_cpu - match current CPU against an array of x86_cpu_ids
  * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
@@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
 			continue;
 		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
 			continue;
-		if (!x86_match_vendor_cpu_type(c, m))
+		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
 			continue;
 		return m;
 	}
diff --git a/arch/x86/kernel/cpu/topology.h b/arch/x86/kernel/cpu/topology.h
index 37326297f80c..74e02bacd854 100644
--- a/arch/x86/kernel/cpu/topology.h
+++ b/arch/x86/kernel/cpu/topology.h
@@ -22,6 +22,7 @@ void topology_set_dom(struct topo_scan *tscan, enum x86_topology_domains dom,
 bool cpu_parse_topology_ext(struct topo_scan *tscan);
 void cpu_parse_topology_amd(struct topo_scan *tscan);
 void cpu_topology_fixup_amd(struct topo_scan *tscan);
+enum x86_topology_cpu_type get_topology_cpu_type(struct cpuinfo_x86 *c);
 
 static inline u32 topo_shift_apicid(u32 apicid, enum x86_topology_domains dom)
 {
diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c
index da080d732e10..c5a6944df86a 100644
--- a/arch/x86/kernel/cpu/topology_amd.c
+++ b/arch/x86/kernel/cpu/topology_amd.c
@@ -177,8 +177,10 @@ static void topoext_fixup(struct topo_scan *tscan)
 
 static void parse_topology_amd(struct topo_scan *tscan)
 {
-	if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES))
-		tscan->c->topo.cpu_type = cpuid_ebx(0x80000026);
+	if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) {
+		tscan->c->topo.hw_cpu_type = cpuid_ebx(0x80000026);
+		tscan->c->topo.cpu_type    = get_topology_cpu_type(tscan->c);
+	}
 
 	/*
 	 * Try to get SMT, CORE, TILE, and DIE shifts from extended
diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index cf7513416b70..b9d025f3373a 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -168,8 +168,12 @@ static void parse_topology(struct topo_scan *tscan, bool early)
 	case X86_VENDOR_INTEL:
 		if (!IS_ENABLED(CONFIG_CPU_SUP_INTEL) || !cpu_parse_topology_ext(tscan))
 			parse_legacy(tscan);
-		if (c->cpuid_level >= 0x1a)
-			c->topo.cpu_type = cpuid_eax(0x1a);
+
+		if (c->cpuid_level >= 0x1a) {
+			c->topo.hw_cpu_type = cpuid_eax(0x1a);
+			c->topo.cpu_type    = get_topology_cpu_type(c);
+		}
+
 		break;
 	}
 }

-- 
Regards/Gruss,
    Boris.

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

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

[Thomas Gleixner]

On Fri, Jul 03 2026 at 12:32, Borislav Petkov wrote:
> Something like the totally untested below - but it builds at least.
>
> We've allocated a u8 for the struct x86_cpu_id member type and we compare that
> to enum x86_topology_cpu_type cpu_type. I guess that's ok for now...
>
> There's potential for more cleanup by removing the ->intel_type and ->amd_type
> and converting them all to our internal represenation of CPU_TYPE but that's
> for later and other patches anyway.
>
> Thoughts?

Looks reasonable to me and should avoid all the nonsense you had to work
around before.

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

[Pawan Gupta]

On Fri, Jul 03, 2026 at 12:32:22PM -0700, Borislav Petkov wrote:
> + Dave and Pawan.
> 
> On Thu, Jul 02, 2026 at 04:03:37PM -0700, Borislav Petkov wrote:
> > On Fri, Jul 03, 2026 at 12:06:32AM +0200, Thomas Gleixner wrote:
> > > Just do the mapping to vendor-agnostic types _once_ when you enumerate the CPU
> > > and store that information in the per CPU data.
> > > 
> > > Then you can do proper vendor agnostic matching against that and define
> > > the TYPE_ANY value as you want without ever colliding with vendor
> > > muck.
> > > 
> > > As a bonus get_topology_cpu_type() goes away too as the translation has
> > > been done already.
> > 
> > Yeah, we should've done it from the very beginning this way. Lemme hack it up
> > and see how it looks like.
> > 
> > Thanks for the cool idea.
> 
> Something like the totally untested below - but it builds at least.
> 
> We've allocated a u8 for the struct x86_cpu_id member type and we compare that
> to enum x86_topology_cpu_type cpu_type. I guess that's ok for now...
> 
> There's potential for more cleanup by removing the ->intel_type and ->amd_type
> and converting them all to our internal represenation of CPU_TYPE but that's
> for later and other patches anyway.
> 
> Thoughts?
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 8d8f890c4bc0..746822bd71fb 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -68,9 +68,13 @@ extern u16 __read_mostly tlb_lld_2m;
>  extern u16 __read_mostly tlb_lld_4m;
>  extern u16 __read_mostly tlb_lld_1g;
>  
> -/*
> - * CPU type and hardware bug flags. Kept separately for each CPU.
> - */
> +enum x86_topology_cpu_type {
> +	/* X86_CPU_TYPE_ANY */
> +	TOPO_CPU_TYPE_ANY = 0,
> +	TOPO_CPU_TYPE_PERFORMANCE,
> +	TOPO_CPU_TYPE_EFFICIENCY,
> +	TOPO_CPU_TYPE_UNKNOWN,
> +};
>  
>  struct cpuinfo_topology {
>  	// Real APIC ID read from the local APIC
> @@ -104,7 +108,7 @@ struct cpuinfo_topology {
>  
>  	// Hardware defined CPU-type
>  	union {
> -		u32		cpu_type;
> +		u32		hw_cpu_type;
>  		struct {
>  			// CPUID.1A.EAX[23-0]
>  			u32	intel_native_model_id	:24;
> @@ -119,8 +123,14 @@ struct cpuinfo_topology {
>  				amd_type		:4;
>  		};
>  	};
> +
> +	// Linux vendor-agnostic CPU type
> +	enum x86_topology_cpu_type cpu_type;

This looks good to me. However, we need to take care of some special cases
like ...

>  };
>  
> +/*
> + * CPU type and hardware bug flags. Kept separately for each CPU.
> + */
>  struct cpuinfo_x86 {
>  	union {
>  		/*
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index 8fb61d2465eb..ef76ba674f1b 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -114,12 +114,6 @@ enum x86_topology_domains {
>  	TOPO_MAX_DOMAIN,
>  };
>  
> -enum x86_topology_cpu_type {
> -	TOPO_CPU_TYPE_PERFORMANCE,
> -	TOPO_CPU_TYPE_EFFICIENCY,
> -	TOPO_CPU_TYPE_UNKNOWN,
> -};
> -
>  struct x86_topology_system {
>  	unsigned int	dom_shifts[TOPO_MAX_DOMAIN];
>  	unsigned int	dom_size[TOPO_MAX_DOMAIN];
> @@ -160,7 +154,6 @@ extern unsigned int __num_nodes_per_package;
>  struct cpuinfo_x86;
>  
>  const char *get_topology_cpu_type_name(struct cpuinfo_x86 *c);
> -enum x86_topology_cpu_type get_topology_cpu_type(struct cpuinfo_x86 *c);
>  
>  static inline unsigned int topology_max_packages(void)
>  {
> diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
> index be4c5e9e5ff6..b8f5dd0a8117 100644
> --- a/arch/x86/kernel/acpi/cppc.c
> +++ b/arch/x86/kernel/acpi/cppc.c
> @@ -241,7 +241,6 @@ EXPORT_SYMBOL_GPL(amd_detect_prefcore);
>   */
>  int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
>  {
> -	enum x86_topology_cpu_type core_type = get_topology_cpu_type(&cpu_data(cpu));
>  	bool prefcore;
>  	int ret;
>  	u32 tmp;
> @@ -273,8 +272,9 @@ int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
>  
>  	/* detect if running on heterogeneous design */
>  	if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) {
> -		switch (core_type) {
> +		switch (cpu_data(cpu).topo.cpu_type) {
>  		case TOPO_CPU_TYPE_UNKNOWN:
> +		case TOPO_CPU_TYPE_ANY:
>  			pr_warn("Undefined core type found for cpu %d\n", cpu);
>  			break;
>  		case TOPO_CPU_TYPE_PERFORMANCE:
> diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
> index 4604802692da..7ab077f0cc66 100644
> --- a/arch/x86/kernel/cpu/match.c
> +++ b/arch/x86/kernel/cpu/match.c
> @@ -5,34 +5,6 @@
>  #include <linux/export.h>
>  #include <linux/slab.h>
>  
> -/**
> - * x86_match_vendor_cpu_type - helper function to match the hardware defined
> - *                             cpu-type for a single entry in the x86_cpu_id
> - *                             table. Note, this function does not match the
> - *                             generic cpu-types TOPO_CPU_TYPE_EFFICIENCY and
> - *                             TOPO_CPU_TYPE_PERFORMANCE.
> - * @c: Pointer to the cpuinfo_x86 structure of the CPU to match.
> - * @m: Pointer to the x86_cpu_id entry to match against.
> - *
> - * Return: true if the cpu-type matches, false otherwise.
> - */
> -static bool x86_match_vendor_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m)
> -{
> -	if (m->type == X86_CPU_TYPE_ANY)
> -		return true;
> -
> -	/* Hybrid CPUs are special, they are assumed to match all cpu-types */
> -	if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU))
> -		return true;
> -
> -	if (c->x86_vendor == X86_VENDOR_INTEL)
> -		return m->type == c->topo.intel_type;
> -	if (c->x86_vendor == X86_VENDOR_AMD)
> -		return m->type == c->topo.amd_type;
> -
> -	return false;
> -}
> -
>  /**
>   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
>   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
> @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
>  			continue;
>  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
>  			continue;
> -		if (!x86_match_vendor_cpu_type(c, m))
> +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)

... matching a hybrid CPU to any cpu_type.

Also, I think now cpu_vuln_blacklist[] needs TOPO_CPU_TYPE_EFFICIENCY
instead of ATOM.

  VULNBL_INTEL_TYPE(INTEL_ALDERLAKE,                   ATOM,      RFDS | VMSCAPE),
  VULNBL_INTEL_STEPS(INTEL_ALDERLAKE,          X86_STEP_MAX,      VMSCAPE),
  VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L,        X86_STEP_MAX,      RFDS | VMSCAPE),
  VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE,                  ATOM,      RFDS | VMSCAPE),

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

[Borislav Petkov]

On Mon, Jul 06, 2026 at 11:29:07AM -0700, Pawan Gupta wrote:
> >  /**
> >   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
> >   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
> > @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
> >  			continue;
> >  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
> >  			continue;
> > -		if (!x86_match_vendor_cpu_type(c, m))
> > +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
> 
> ... matching a hybrid CPU to any cpu_type.

I don't know what you mean here.

enum x86_topology_cpu_type {
   /* X86_CPU_TYPE_ANY */
   TOPO_CPU_TYPE_ANY = 0,
   TOPO_CPU_TYPE_PERFORMANCE,
   TOPO_CPU_TYPE_EFFICIENCY,
   TOPO_CPU_TYPE_UNKNOWN,
};

These are the Linux-specific CPU types and all vendor CPU types will be mapped
to them. I hope 255 are enough.

> Also, I think now cpu_vuln_blacklist[] needs TOPO_CPU_TYPE_EFFICIENCY
> instead of ATOM.
> 
>   VULNBL_INTEL_TYPE(INTEL_ALDERLAKE,                   ATOM,      RFDS | VMSCAPE),
>   VULNBL_INTEL_STEPS(INTEL_ALDERLAKE,          X86_STEP_MAX,      VMSCAPE),
>   VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L,        X86_STEP_MAX,      RFDS | VMSCAPE),
>   VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE,                  ATOM,      RFDS | VMSCAPE),

Ack, right, ATOM == EFFICIENCY in Intel-speak, so I'd need to convert those.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Pawan Gupta]

On Mon, Jul 06, 2026 at 05:47:13PM -0700, Borislav Petkov wrote:
> On Mon, Jul 06, 2026 at 11:29:07AM -0700, Pawan Gupta wrote:
> > >  /**
> > >   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
> > >   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
> > > @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
> > >  			continue;
> > >  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
> > >  			continue;
> > > -		if (!x86_match_vendor_cpu_type(c, m))
> > > +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
> > 
> > ... matching a hybrid CPU to any cpu_type.
> 
> I don't know what you mean here.

Vulnerability enumeration is done on the BSP, for a hybrid system with BSP
as a performance-core, a vulnerability that only affects efficiency-cores
would not be enumerated. So, x86_match_cpu() currently returns a match for
any cpu-type on a hybrid system.

> enum x86_topology_cpu_type {
>    /* X86_CPU_TYPE_ANY */
>    TOPO_CPU_TYPE_ANY = 0,
>    TOPO_CPU_TYPE_PERFORMANCE,
>    TOPO_CPU_TYPE_EFFICIENCY,
>    TOPO_CPU_TYPE_UNKNOWN,
> };
> 
> These are the Linux-specific CPU types and all vendor CPU types will be mapped
> to them. I hope 255 are enough.

255 should be more than enough, but it doesn't take resolve the problem of
matching a hybrid CPU to any cpu_type.

Apart from struct cpuinfo_x86 for each CPU, we have separate boot_cpu_data
for BSP. One possible solution is to set cpu_type to TOPO_CPU_TYPE_ANY in
BSP specific struct for hybrid systems.

For more accurate matching, x86_topology_cpu_type could be a u32 with
bit-fields for each CPU type. And boot_cpu_data can have:

  boot_cpu_data.topo.cpu_type = (TOPO_CPU_TYPE_PERFORMANCE | TOPO_CPU_TYPE_EFFICIENCY | ...)

on a hybrid system. Problem with this approach is, unless secondary CPUs
are brought up, BSP will not know what all cpu-types are present in the
system. Also with bit-fields, possible cpu-types are further limited.

To circumvent this problem, current implementation matches a hybrid CPU
with any cpu_type.

> > Also, I think now cpu_vuln_blacklist[] needs TOPO_CPU_TYPE_EFFICIENCY
> > instead of ATOM.
> > 
> >   VULNBL_INTEL_TYPE(INTEL_ALDERLAKE,                   ATOM,      RFDS | VMSCAPE),
> >   VULNBL_INTEL_STEPS(INTEL_ALDERLAKE,          X86_STEP_MAX,      VMSCAPE),
> >   VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L,        X86_STEP_MAX,      RFDS | VMSCAPE),
> >   VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE,                  ATOM,      RFDS | VMSCAPE),
> 
> Ack, right, ATOM == EFFICIENCY in Intel-speak, so I'd need to convert those.
> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

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

[Thomas Gleixner]

On Tue, Jul 07 2026 at 10:52, Pawan Gupta wrote:
> On Mon, Jul 06, 2026 at 05:47:13PM -0700, Borislav Petkov wrote:
>> On Mon, Jul 06, 2026 at 11:29:07AM -0700, Pawan Gupta wrote:
>> > >  /**
>> > >   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
>> > >   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
>> > > @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
>> > >  			continue;
>> > >  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
>> > >  			continue;
>> > > -		if (!x86_match_vendor_cpu_type(c, m))
>> > > +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
>> > 
>> > ... matching a hybrid CPU to any cpu_type.
>> 
>> I don't know what you mean here.
>
> Vulnerability enumeration is done on the BSP, for a hybrid system with BSP
> as a performance-core, a vulnerability that only affects efficiency-cores
> would not be enumerated. So, x86_match_cpu() currently returns a match for
> any cpu-type on a hybrid system.

Abusing the type, which enumerates performance properties, for
vulnerability crystal ball logic is simply broken.

The type is a per CPU property and has nothing to do with hybrid or
not. Hybrid is a packet property.

Just because it is convenient does not make it more correct. If you need
to enable mitigations on hybrid systems, then explicitely check for the
hybrid property.

Thanks,

        tglx

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

[Pawan Gupta]

On Tue, Jul 07, 2026 at 09:29:32PM +0200, Thomas Gleixner wrote:
> On Tue, Jul 07 2026 at 10:52, Pawan Gupta wrote:
> > On Mon, Jul 06, 2026 at 05:47:13PM -0700, Borislav Petkov wrote:
> >> On Mon, Jul 06, 2026 at 11:29:07AM -0700, Pawan Gupta wrote:
> >> > >  /**
> >> > >   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
> >> > >   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
> >> > > @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
> >> > >  			continue;
> >> > >  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
> >> > >  			continue;
> >> > > -		if (!x86_match_vendor_cpu_type(c, m))
> >> > > +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
> >> > 
> >> > ... matching a hybrid CPU to any cpu_type.
> >> 
> >> I don't know what you mean here.
> >
> > Vulnerability enumeration is done on the BSP, for a hybrid system with BSP
> > as a performance-core, a vulnerability that only affects efficiency-cores
> > would not be enumerated. So, x86_match_cpu() currently returns a match for
> > any cpu-type on a hybrid system.
> 
> Abusing the type, which enumerates performance properties, for
> vulnerability crystal ball logic is simply broken.
> 
> The type is a per CPU property and has nothing to do with hybrid or
> not. Hybrid is a packet property.
> 
> Just because it is convenient does not make it more correct. If you need
> to enable mitigations on hybrid systems, then explicitely check for the
> hybrid property.

Right, I was convoluting 2 different goals. Vulnerability enumeration
should explicitly check for hybrid.

Currently, only RFDS needs to check for hybrid. It is probably not worth
creating a new mechanism for cpu_type check for vulnerability enumeration.
Below should work with current set of CPUs. Please let me know if there is
a better way to handle this:

---
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a3df21d26460..836076b1a3b5 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1316,10 +1316,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
 	VULNBL_INTEL_STEPS(INTEL_TIGERLAKE,	     X86_STEP_MAX,	GDS | ITS | ITS_NATIVE_ONLY),
 	VULNBL_INTEL_STEPS(INTEL_LAKEFIELD,	     X86_STEP_MAX,	MMIO | MMIO_SBDS | RETBLEED),
 	VULNBL_INTEL_STEPS(INTEL_ROCKETLAKE,	     X86_STEP_MAX,	MMIO | RETBLEED | GDS | ITS | ITS_NATIVE_ONLY),
-	VULNBL_INTEL_TYPE(INTEL_ALDERLAKE,		     ATOM,	RFDS | VMSCAPE),
 	VULNBL_INTEL_STEPS(INTEL_ALDERLAKE,	     X86_STEP_MAX,	VMSCAPE),
 	VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L,	     X86_STEP_MAX,	RFDS | VMSCAPE),
-	VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE,		     ATOM,	RFDS | VMSCAPE),
 	VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE,	     X86_STEP_MAX,	VMSCAPE),
 	VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_P,	     X86_STEP_MAX,	RFDS | VMSCAPE),
 	VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_S,	     X86_STEP_MAX,	RFDS | VMSCAPE),
@@ -1388,7 +1386,20 @@ static bool __init vulnerable_to_rfds(u64 x86_arch_cap_msr)
 		return true;
 
 	/* Only consult the blacklist when there is no enumeration: */
-	return cpu_matches(cpu_vuln_blacklist, RFDS);
+	if (!cpu_matches(cpu_vuln_blacklist, RFDS))
+		return false;
+
+	/*
+	 * ADL and RPL are only affected if they have Atom CPUs.
+	 * Hybrids have both Core and Atom CPUs, mark them vulnerable.
+	 */
+	if ((boot_cpu_data.x86_model == 0x97 ||
+	     boot_cpu_data.x86_model == 0xB7) &&
+	     boot_cpu_data.topo.hw_cpu_type == INTEL_CPU_TYPE_CORE &&
+	     !boot_cpu_has(X86_FEATURE_HYBRID_CPU))
+		return false;
+
+	return true;
 }
 
 static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)

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

[Thomas Gleixner]

On Tue, Jul 07 2026 at 13:46, Pawan Gupta wrote:
> On Tue, Jul 07, 2026 at 09:29:32PM +0200, Thomas Gleixner wrote:
>> Just because it is convenient does not make it more correct. If you need
>> to enable mitigations on hybrid systems, then explicitely check for the
>> hybrid property.
>
> Right, I was convoluting 2 different goals. Vulnerability enumeration
> should explicitly check for hybrid.
>
> Currently, only RFDS needs to check for hybrid. It is probably not worth
> creating a new mechanism for cpu_type check for vulnerability enumeration.
> Below should work with current set of CPUs. Please let me know if there is
> a better way to handle this:

If that's the only case to handle, then sure that open coded check is
fine.

[PATCH 2/2] x86/topology: Add TOPO_CPU_TYPE_LOW_POWER

[Vishal Badole]

AMD heterogeneous parts report a third core type via CPUID
Fn0x80000026 EBX[31:28] (Extended CPU Topology, Core Type):

  0 - Performance
  1 - Efficiency
  2 - Low Power

get_topology_cpu_type() only translates the first two, so on parts
that ship low-power cores the third type falls through to
TOPO_CPU_TYPE_UNKNOWN. That has two visible effects:

  - /sys/kernel/debug/x86/topo/cpus/* reports cpu_type "unknown" via
    get_topology_cpu_type_name().

  - amd_get_boost_ratio_numerator() hits the default arm of its
    x86_topology_cpu_type switch and uses the
    CPPC_HIGHEST_PERF_PREFCORE fallback instead of scaling by
    amd_get_highest_perf() as efficiency cores do.

Add TOPO_CPU_TYPE_LOW_POWER, translate AMD_CPU_TYPE_LOW_POWER to it
in get_topology_cpu_type(), and expose a "low_power" name via
get_topology_cpu_type_name().

In amd_get_boost_ratio_numerator(), share the efficiency-core arm of
the switch with the new type so low-power cores scale by
amd_get_highest_perf() rather than the performance-core ceiling. The
new case sits under the existing
cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES) gate and therefore
applies to every HTR_CORES-capable AMD/Hygon part that reports core
type 2.

Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
---
 arch/x86/include/asm/topology.h       | 1 +
 arch/x86/kernel/acpi/cppc.c           | 3 ++-
 arch/x86/kernel/cpu/topology_common.c | 3 +++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 9658b5676ce6..1e65a6ea5de4 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -117,6 +117,7 @@ enum x86_topology_domains {
 enum x86_topology_cpu_type {
 	TOPO_CPU_TYPE_PERFORMANCE,
 	TOPO_CPU_TYPE_EFFICIENCY,
+	TOPO_CPU_TYPE_LOW_POWER,
 	TOPO_CPU_TYPE_UNKNOWN,
 };
 
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index d7c8ef1e354d..df2c7579309c 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -281,8 +281,9 @@ int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
 			/* use the max scale for performance cores */
 			*numerator = CPPC_HIGHEST_PERF_PERFORMANCE;
 			return 0;
+		case TOPO_CPU_TYPE_LOW_POWER:
 		case TOPO_CPU_TYPE_EFFICIENCY:
-			/* use the highest perf value for efficiency cores */
+			/* use the highest perf value for efficiency and low-power cores */
 			ret = amd_get_highest_perf(cpu, &tmp);
 			if (ret)
 				return ret;
diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index e1cc25a115ca..8c8267c812e0 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -44,6 +44,7 @@ enum x86_topology_cpu_type get_topology_cpu_type(struct cpuinfo_x86 *c)
 		switch (c->topo.amd_type) {
 		case AMD_CPU_TYPE_PERFORMANCE:	return TOPO_CPU_TYPE_PERFORMANCE;
 		case AMD_CPU_TYPE_EFFICIENCY:	return TOPO_CPU_TYPE_EFFICIENCY;
+		case AMD_CPU_TYPE_LOW_POWER:	return TOPO_CPU_TYPE_LOW_POWER;
 		}
 	}
 
@@ -57,6 +58,8 @@ const char *get_topology_cpu_type_name(struct cpuinfo_x86 *c)
 		return "performance";
 	case TOPO_CPU_TYPE_EFFICIENCY:
 		return "efficiency";
+	case TOPO_CPU_TYPE_LOW_POWER:
+		return "low_power";
 	default:
 		return "unknown";
 	}
-- 
2.34.1