The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH 0/2] x86/topology: Add support for Low Power cpu_type
@ 2026-06-29  9:43 Vishal Badole
  2026-06-29  9:43 ` [PATCH 1/2] x86/topology: Name the AMD core-type values Vishal Badole
  2026-06-29  9:43 ` [PATCH 2/2] x86/topology: Add TOPO_CPU_TYPE_LOW_POWER Vishal Badole
  0 siblings, 2 replies; 8+ messages in thread
From: Vishal Badole @ 2026-06-29  9:43 UTC (permalink / raw)
  To: tglx, mingo, bp, dave.hansen, x86, hpa, rafael, lenb
  Cc: linux-kernel, linux-acpi, peterz, tony.luck, chang.seok.bae,
	wei.w.wang, 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-06-29  9:43 [PATCH 0/2] x86/topology: Add support for Low Power cpu_type Vishal Badole
@ 2026-06-29  9:43 ` Vishal Badole
  2026-07-02  0:27   ` Borislav Petkov
  2026-06-29  9:43 ` [PATCH 2/2] x86/topology: Add TOPO_CPU_TYPE_LOW_POWER Vishal Badole
  1 sibling, 1 reply; 8+ messages in thread
From: Vishal Badole @ 2026-06-29  9:43 UTC (permalink / raw)
  To: tglx, mingo, bp, dave.hansen, x86, hpa, rafael, lenb
  Cc: linux-kernel, linux-acpi, peterz, tony.luck, chang.seok.bae,
	wei.w.wang, 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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/2] x86/topology: Add TOPO_CPU_TYPE_LOW_POWER
  2026-06-29  9:43 [PATCH 0/2] x86/topology: Add support for Low Power cpu_type Vishal Badole
  2026-06-29  9:43 ` [PATCH 1/2] x86/topology: Name the AMD core-type values Vishal Badole
@ 2026-06-29  9:43 ` Vishal Badole
  1 sibling, 0 replies; 8+ messages in thread
From: Vishal Badole @ 2026-06-29  9:43 UTC (permalink / raw)
  To: tglx, mingo, bp, dave.hansen, x86, hpa, rafael, lenb
  Cc: linux-kernel, linux-acpi, peterz, tony.luck, chang.seok.bae,
	wei.w.wang, 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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-06-29  9:43 ` [PATCH 1/2] x86/topology: Name the AMD core-type values Vishal Badole
@ 2026-07-02  0:27   ` Borislav Petkov
  2026-07-02 22:06     ` Thomas Gleixner
  0 siblings, 1 reply; 8+ messages in thread
From: Borislav Petkov @ 2026-07-02  0:27 UTC (permalink / raw)
  To: Vishal Badole, dave.hansen, tglx
  Cc: mingo, x86, hpa, rafael, lenb, linux-kernel, linux-acpi, peterz,
	tony.luck, chang.seok.bae, wei.w.wang

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-07-02  0:27   ` Borislav Petkov
@ 2026-07-02 22:06     ` Thomas Gleixner
  2026-07-02 23:03       ` Borislav Petkov
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Gleixner @ 2026-07-02 22:06 UTC (permalink / raw)
  To: Borislav Petkov, Vishal Badole, dave.hansen
  Cc: mingo, x86, hpa, rafael, lenb, linux-kernel, linux-acpi, peterz,
	tony.luck, chang.seok.bae, wei.w.wang

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-07-02 22:06     ` Thomas Gleixner
@ 2026-07-02 23:03       ` Borislav Petkov
  2026-07-03 19:32         ` Borislav Petkov
  0 siblings, 1 reply; 8+ messages in thread
From: Borislav Petkov @ 2026-07-02 23:03 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Vishal Badole, dave.hansen, mingo, x86, hpa, rafael, lenb,
	linux-kernel, linux-acpi, peterz, tony.luck, chang.seok.bae,
	wei.w.wang

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-07-02 23:03       ` Borislav Petkov
@ 2026-07-03 19:32         ` Borislav Petkov
  2026-07-03 19:39           ` Thomas Gleixner
  0 siblings, 1 reply; 8+ messages in thread
From: Borislav Petkov @ 2026-07-03 19:32 UTC (permalink / raw)
  To: Thomas Gleixner, dave.hansen, Pawan Gupta
  Cc: Vishal Badole, mingo, x86, hpa, rafael, lenb, linux-kernel,
	linux-acpi, peterz, tony.luck, chang.seok.bae, wei.w.wang

+ 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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2] x86/topology: Name the AMD core-type values
  2026-07-03 19:32         ` Borislav Petkov
@ 2026-07-03 19:39           ` Thomas Gleixner
  0 siblings, 0 replies; 8+ messages in thread
From: Thomas Gleixner @ 2026-07-03 19:39 UTC (permalink / raw)
  To: Borislav Petkov, dave.hansen, Pawan Gupta
  Cc: Vishal Badole, mingo, x86, hpa, rafael, lenb, linux-kernel,
	linux-acpi, peterz, tony.luck, chang.seok.bae, wei.w.wang

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-07-03 19:40 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-29  9:43 [PATCH 0/2] x86/topology: Add support for Low Power cpu_type Vishal Badole
2026-06-29  9:43 ` [PATCH 1/2] x86/topology: Name the AMD core-type values Vishal Badole
2026-07-02  0:27   ` Borislav Petkov
2026-07-02 22:06     ` Thomas Gleixner
2026-07-02 23:03       ` Borislav Petkov
2026-07-03 19:32         ` Borislav Petkov
2026-07-03 19:39           ` Thomas Gleixner
2026-06-29  9:43 ` [PATCH 2/2] x86/topology: Add TOPO_CPU_TYPE_LOW_POWER Vishal Badole

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox