[PATCH v4 00/10] Add CPU-type to topology

[PATCH v4 00/10] Add CPU-type to topology

[Pawan Gupta]

v4:
- Series doesn't apply to upstream cleanly anymore, rebased to v6.12-rc1,
  resolved the merge conflict in files:
	arch/x86/include/asm/cpu_device_id.h
	arch/x86/kernel/cpu/common.c
- Remove redundant "hw_" in intel_hw_native_model_id().

v3: https://lore.kernel.org/r/20240815-add-cpu-type-v3-0-234162352057@linux.intel.com
- Add a patch to prepend "0x" to hex values in cpu_debug_show() (Borislav).
- Add support to to also get Intel Native Model ID (Dapeng).
- Keep similar models together in the affected processor list (Josh).
- Add a comparison of .init.data in commit message for cpu_vuln_blacklist
  before and after decluttering patch for affected processor list (Josh).
- Drop the debugfs file reference in the commit message (Borislav).
- s/cpu_type/hw_cpu_type/ (Borislav).
- Add a union for hw_cpu_type for easy retrieval of intel_core_type and
  intel_native_model_id.
- Updated commit messages, collected tags.
- Rebased to v6.11-rc3.

Note, I will be off work till Tuesday, will reply to any comments then.

v2: https://lore.kernel.org/r/20240627-add-cpu-type-v2-0-f927bde83ad0@linux.intel.com
- Move CPU-type to the end of the CPU topology structure (Andrew).
- Use c->cpuid_level instead of cpuid_eax(0) (Andrew).
- Move CPU-type enum out of ifdef CONFIG_NUMA (kernel test robot).
- Rename cpu_type to hw_cpu_type (Borislav).
- Explain replacing get_this_hybrid_cpu_type() with topology_hw_cpu_type()
  in the commit message (Dave).
- Fix the alignment in cpu_vuln_whitelist (Andrew).
- Add the obj compare note in the commit message (Dave/Tony).
- s/X86_CPU_TYPE_INTEL_ATOM/ATOM/ in cpu_vuln_whitelist (Dave).

v1: https://lore.kernel.org/r/20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com

Hi,

This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to
differentiate between hybrid variants P+E, P-only, E-only that share the
same Family/Model/Stepping. One of the use case for CPU-type is the
affected CPU table for CPU vulnerabilities, which can now use the CPU-type
to filter the unaffected variants.

* Patch 1 fixes a minor formatting issue in cpu_debug_show().

* Patch 2 adds hardware cpu-type to CPU topology structure and introduces
  topology_hw_cpu_type().

* Patch 3-5 replaces usages of get_this_hybrid_cpu_type() with
  topology_hw_cpu_type().

* Patch 6-8 Updates CPU-matching infrastructure to use CPU-type.

* Patch 9 cleans up the affected CPU list.

* Patch 10 uses the CPU-type to exclude P-only parts from the RFDS affected
  list.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Pawan Gupta (10):
      x86/cpu: Prepend 0x to the hex values in cpu_debug_show()
      x86/cpu/topology: Add CPU type to struct cpuinfo_topology
      cpufreq: intel_pstate: Use topology_hw_cpu_type()
      perf/x86/intel: Use topology_hw_cpu_type()
      x86/cpu: Remove get_this_hybrid_cpu_type()
      x86/cpu: Name CPU matching macro more generically (and shorten)
      x86/cpu: Add cpu_type to struct x86_cpu_id
      x86/cpu: Update x86_match_cpu() to also use cpu-type
      x86/bugs: Declutter vulnerable CPU list
      x86/rfds: Exclude P-only parts from the RFDS affected list

 .../admin-guide/hw-vuln/reg-file-data-sampling.rst |   8 --
 arch/x86/events/intel/core.c                       |   3 +-
 arch/x86/include/asm/cpu.h                         |   4 +-
 arch/x86/include/asm/cpu_device_id.h               | 113 ++++++----------
 arch/x86/include/asm/processor.h                   |  11 ++
 arch/x86/include/asm/topology.h                    |   8 ++
 arch/x86/kernel/cpu/common.c                       | 148 +++++++++++----------
 arch/x86/kernel/cpu/debugfs.c                      |   5 +-
 arch/x86/kernel/cpu/intel.c                        |  15 +--
 arch/x86/kernel/cpu/match.c                        |  22 +++
 arch/x86/kernel/cpu/topology_common.c              |  11 ++
 drivers/cpufreq/intel_pstate.c                     |  14 +-
 include/linux/mod_devicetable.h                    |   2 +
 13 files changed, 186 insertions(+), 178 deletions(-)
---
base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc
change-id: 20240617-add-cpu-type-4d5e47efc117

Best regards,
-- 
Thanks,
Pawan

[PATCH v4 01/10] x86/cpu: Prepend 0x to the hex values in cpu_debug_show()

[Pawan Gupta]

The hex values in CPU debug interface are not prepended with 0x. This may
cause misinterpretation of values. Fix it.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/kernel/cpu/debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c
index 3baf3e435834..ca373b990c47 100644
--- a/arch/x86/kernel/cpu/debugfs.c
+++ b/arch/x86/kernel/cpu/debugfs.c
@@ -16,8 +16,8 @@ static int cpu_debug_show(struct seq_file *m, void *p)
 	if (!c->initialized)
 		return 0;
 
-	seq_printf(m, "initial_apicid:      %x\n", c->topo.initial_apicid);
-	seq_printf(m, "apicid:              %x\n", c->topo.apicid);
+	seq_printf(m, "initial_apicid:	  0x%x\n", c->topo.initial_apicid);
+	seq_printf(m, "apicid:		  0x%x\n", c->topo.apicid);
 	seq_printf(m, "pkg_id:              %u\n", c->topo.pkg_id);
 	seq_printf(m, "die_id:              %u\n", c->topo.die_id);
 	seq_printf(m, "cu_id:               %u\n", c->topo.cu_id);

-- 
2.34.1

[PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Pawan Gupta]

Sometimes it is required to take actions based on if a CPU is a performance
or efficiency core. As an example, intel_pstate driver uses the Intel
core-type to determine CPU scaling. Also, some CPU vulnerabilities only
affect a specific CPU type, like RFDS only affects Intel Atom. Hybrid
systems that have variants P+E, P-only(Core) and E-only(Atom), it is not
straightforward to identify which variant is affected by a type specific
vulnerability.

Such processors do have CPUID field that can uniquely identify them. Like,
P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while
P+E additionally enumerates CPUID.7.HYBRID. Based on this information, it
is possible for boot CPU to identify if a system has mixed CPU types.

Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
hardware specific CPU type. This saves the overhead of IPIs to get the CPU
type of a different CPU. CPU type is populated early in the boot process,
before vulnerabilities are enumerated.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/include/asm/cpu.h            |  6 ++++++
 arch/x86/include/asm/processor.h      | 11 +++++++++++
 arch/x86/include/asm/topology.h       |  8 ++++++++
 arch/x86/kernel/cpu/debugfs.c         |  1 +
 arch/x86/kernel/cpu/intel.c           |  5 +++++
 arch/x86/kernel/cpu/topology_common.c | 11 +++++++++++
 6 files changed, 42 insertions(+)

diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index aa30fd8cad7f..2244dd86066a 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -32,6 +32,7 @@ extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
 extern bool handle_guest_split_lock(unsigned long ip);
 extern void handle_bus_lock(struct pt_regs *regs);
 u8 get_this_hybrid_cpu_type(void);
+u32 intel_native_model_id(struct cpuinfo_x86 *c);
 #else
 static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
 static inline bool handle_user_split_lock(struct pt_regs *regs, long error_code)
@@ -50,6 +51,11 @@ static inline u8 get_this_hybrid_cpu_type(void)
 {
 	return 0;
 }
+
+static u32 intel_native_model_id(struct cpuinfo_x86 *c)
+{
+	return 0;
+}
 #endif
 #ifdef CONFIG_IA32_FEAT_CTL
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 4a686f0e5dbf..61c8336bc99b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -105,6 +105,17 @@ struct cpuinfo_topology {
 	// Cache level topology IDs
 	u32			llc_id;
 	u32			l2c_id;
+
+	// Hardware defined CPU-type
+	union {
+		u32		hw_cpu_type;
+		struct {
+			/* CPUID.1A.EAX[23-0] */
+			u32	intel_core_native_model_id:24;
+			/* CPUID.1A.EAX[31-24] */
+			u32	intel_core_type:8;
+		};
+	};
 };
 
 struct cpuinfo_x86 {
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index aef70336d624..faf7cb7f7d7e 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -114,6 +114,12 @@ enum x86_topology_domains {
 	TOPO_MAX_DOMAIN,
 };
 
+enum x86_topology_hw_cpu_type {
+	TOPO_HW_CPU_TYPE_UNKNOWN	= 0,
+	TOPO_HW_CPU_TYPE_INTEL_ATOM	= 0x20,
+	TOPO_HW_CPU_TYPE_INTEL_CORE	= 0x40,
+};
+
 struct x86_topology_system {
 	unsigned int	dom_shifts[TOPO_MAX_DOMAIN];
 	unsigned int	dom_size[TOPO_MAX_DOMAIN];
@@ -149,6 +155,8 @@ extern unsigned int __max_threads_per_core;
 extern unsigned int __num_threads_per_package;
 extern unsigned int __num_cores_per_package;
 
+enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c);
+
 static inline unsigned int topology_max_packages(void)
 {
 	return __max_logical_packages;
diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c
index ca373b990c47..d1731e0e36b0 100644
--- a/arch/x86/kernel/cpu/debugfs.c
+++ b/arch/x86/kernel/cpu/debugfs.c
@@ -22,6 +22,7 @@ static int cpu_debug_show(struct seq_file *m, void *p)
 	seq_printf(m, "die_id:              %u\n", c->topo.die_id);
 	seq_printf(m, "cu_id:               %u\n", c->topo.cu_id);
 	seq_printf(m, "core_id:             %u\n", c->topo.core_id);
+	seq_printf(m, "hw_cpu_type:       0x%x\n", c->topo.hw_cpu_type);
 	seq_printf(m, "logical_pkg_id:      %u\n", c->topo.logical_pkg_id);
 	seq_printf(m, "logical_die_id:      %u\n", c->topo.logical_die_id);
 	seq_printf(m, "llc_id:              %u\n", c->topo.llc_id);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index e7656cbef68d..e56401c5c050 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1299,3 +1299,8 @@ u8 get_this_hybrid_cpu_type(void)
 
 	return cpuid_eax(0x0000001a) >> X86_HYBRID_CPU_TYPE_ID_SHIFT;
 }
+
+u32 intel_native_model_id(struct cpuinfo_x86 *c)
+{
+	return c->topo.intel_core_native_model_id;
+}
diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index 9a6069e7133c..e4814cd3d8ae 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -27,6 +27,14 @@ void topology_set_dom(struct topo_scan *tscan, enum x86_topology_domains dom,
 	}
 }
 
+enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c)
+{
+	if (c->x86_vendor == X86_VENDOR_INTEL)
+		return c->topo.intel_core_type;
+
+	return c->topo.hw_cpu_type;
+}
+
 static unsigned int __maybe_unused parse_num_cores_legacy(struct cpuinfo_x86 *c)
 {
 	struct {
@@ -87,6 +95,7 @@ static void parse_topology(struct topo_scan *tscan, bool early)
 		.cu_id			= 0xff,
 		.llc_id			= BAD_APICID,
 		.l2c_id			= BAD_APICID,
+		.hw_cpu_type		= TOPO_HW_CPU_TYPE_UNKNOWN,
 	};
 	struct cpuinfo_x86 *c = tscan->c;
 	struct {
@@ -132,6 +141,8 @@ 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.hw_cpu_type = cpuid_eax(0x1a);
 		break;
 	case X86_VENDOR_HYGON:
 		if (IS_ENABLED(CONFIG_CPU_SUP_HYGON))

-- 
2.34.1

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Borislav Petkov]

On Mon, Sep 30, 2024 at 07:47:24AM -0700, Pawan Gupta wrote:
> Subject: Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct...

x86/cpu: ...

is enough.

> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 4a686f0e5dbf..61c8336bc99b 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -105,6 +105,17 @@ struct cpuinfo_topology {
>  	// Cache level topology IDs
>  	u32			llc_id;
>  	u32			l2c_id;
> +
> +	// Hardware defined CPU-type
> +	union {
> +		u32		hw_cpu_type;
> +		struct {
> +			/* CPUID.1A.EAX[23-0] */

Might as well stick to only // comments as we do those in headers now.

> +			u32	intel_core_native_model_id:24;

wow, that needs a whole breath to speak: "intel_core_native_model_id".

"core" and "native" look like they wanna go. What is that field supposed to
mean even?

> +			/* CPUID.1A.EAX[31-24] */
> +			u32	intel_core_type:8;
> +		};
> +	};
>  };

...

> +enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c)
> +{
> +	if (c->x86_vendor == X86_VENDOR_INTEL)
> +		return c->topo.intel_core_type;
> +
> +	return c->topo.hw_cpu_type;

Huh, the other vendors are not enabled. This should return
TOPO_HW_CPU_TYPE_UNKNOWN then.

I know, it does but make explicit pls.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Pawan Gupta]

On Fri, Oct 18, 2024 at 06:19:56PM +0200, Borislav Petkov wrote:
> On Mon, Sep 30, 2024 at 07:47:24AM -0700, Pawan Gupta wrote:
> > Subject: Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct...
> 
> x86/cpu: ...
> 
> is enough.

Ok.

> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 4a686f0e5dbf..61c8336bc99b 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -105,6 +105,17 @@ struct cpuinfo_topology {
> >  	// Cache level topology IDs
> >  	u32			llc_id;
> >  	u32			l2c_id;
> > +
> > +	// Hardware defined CPU-type
> > +	union {
> > +		u32		hw_cpu_type;
> > +		struct {
> > +			/* CPUID.1A.EAX[23-0] */
> 
> Might as well stick to only // comments as we do those in headers now.

Will do.

> > +			u32	intel_core_native_model_id:24;
> 
> wow, that needs a whole breath to speak: "intel_core_native_model_id".

Yes, it needs to be shortened.

> "core" and "native" look like they wanna go. What is that field supposed to
> mean even?

In combination with core_type, this field can be used to uniquely identify
the microarchitecture.

I will drop "core", but can we keep "native"? "native" is used in SDM to
define this field. Also model_id could be confused with model number.

  From Intel SDM Vol. 2A:

  Bits 23-00: Native model ID of the core. The core-type and native model
  ID can be used to uniquely identify the microarchitecture of the core.
  This native model ID is not unique across core types, and not related to
  the model ID reported in CPUID leaf 01H, and does not identify the SOC.


> > +			/* CPUID.1A.EAX[31-24] */
> > +			u32	intel_core_type:8;
> > +		};
> > +	};
> >  };
> 
> ...
> 
> > +enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c)
> > +{
> > +	if (c->x86_vendor == X86_VENDOR_INTEL)
> > +		return c->topo.intel_core_type;
> > +
> > +	return c->topo.hw_cpu_type;
> 
> Huh, the other vendors are not enabled. This should return
> TOPO_HW_CPU_TYPE_UNKNOWN then.
> 
> I know, it does but make explicit pls.

Yes, topo.hw_cpu_type is initialized to TOPO_HW_CPU_TYPE_UNKNOWN. We should
not ideally need the vendor check at all. As long as topo.hw_cpu_type has
the core type, returning it should be enough here. For Intel hw_cpu_type
also has the native_model_id, that is why we need the vendor check.

If AMD or other vendors have similar use case, it makes sense to add the
explicit vendor check. Please let me know if thats the likely case.

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Borislav Petkov]

On October 18, 2024 10:30:53 PM GMT+02:00, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>I will drop "core", but can we keep "native"? "native" is used in SDM to
>define this field. Also model_id could be confused with model number.
>
>  From Intel SDM Vol. 2A:
>
>  Bits 23-00: Native model ID of the core. The core-type and native model
>  ID can be used to uniquely identify the microarchitecture of the core.
>  This native model ID is not unique across core types, and not related to
>  the model ID reported in CPUID leaf 01H, and does not identify the SOC.

I'm still not clear on what "native" is supposed to mean here?

The core is born this way and then it changes... so this is its native model ID? Weird...

>Yes, topo.hw_cpu_type is initialized to TOPO_HW_CPU_TYPE_UNKNOWN. We should
>not ideally need the vendor check at all. As long as topo.hw_cpu_type has
>the core type, returning it should be enough here. For Intel hw_cpu_type
>also has the native_model_id, that is why we need the vendor check.
>
>If AMD or other vendors have similar use case, it makes sense to add the
>explicit vendor check. Please let me know if thats the likely case.

Yes, it either needs to be vendor-agnostic or you need to accommodate all vendors. Former sounds cleaner...

-- 
Sent from a small device: formatting sucks and brevity is inevitable.

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Pawan Gupta]

On Mon, Oct 21, 2024 at 03:38:06PM +0200, Borislav Petkov wrote:
> On October 18, 2024 10:30:53 PM GMT+02:00, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> >I will drop "core", but can we keep "native"? "native" is used in SDM to
> >define this field. Also model_id could be confused with model number.
> >
> >  From Intel SDM Vol. 2A:
> >
> >  Bits 23-00: Native model ID of the core. The core-type and native model
> >  ID can be used to uniquely identify the microarchitecture of the core.
> >  This native model ID is not unique across core types, and not related to
> >  the model ID reported in CPUID leaf 01H, and does not identify the SOC.
> 
> I'm still not clear on what "native" is supposed to mean here?
>
> The core is born this way and then it changes... so this is its native
> model ID? Weird...

In a hybrid system the model number reported by CPUID could represent
multiple core-types. As model number is same for all cores, it is
insufficient to uniquely identify the microarchitecture of a core. I
believe "native model ID" bridges that gap as it is specific to a core.

> >Yes, topo.hw_cpu_type is initialized to TOPO_HW_CPU_TYPE_UNKNOWN. We should
> >not ideally need the vendor check at all. As long as topo.hw_cpu_type has
> >the core type, returning it should be enough here. For Intel hw_cpu_type
> >also has the native_model_id, that is why we need the vendor check.
> >
> >If AMD or other vendors have similar use case, it makes sense to add the
> >explicit vendor check. Please let me know if thats the likely case.
> 
> Yes, it either needs to be vendor-agnostic or you need to accommodate all
> vendors. Former sounds cleaner...

Ok, I will add an explicit vendor check for AMD as well.

RE: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Luck, Tony]

>> The core is born this way and then it changes... so this is its native
>> model ID? Weird...
>
> In a hybrid system the model number reported by CPUID could represent
> multiple core-types. As model number is same for all cores, it is
> insufficient to uniquely identify the microarchitecture of a core. I
> believe "native model ID" bridges that gap as it is specific to a core.

Example from <asm/intel-family.h>

#define INTEL_ALDERLAKE_L               IFM(6, 0x9A) /* Golden Cove / Gracemont */

#define INTEL_RAPTORLAKE                IFM(6, 0xB7) /* Raptor Cove / Enhanced Gracemont */

The native model number could be helpful to tell what each of your P-cores and E-cores
are based on. Could be useful when the same base core is used in more than one SoC
generation.

-Tony

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Borislav Petkov]

On Mon, Oct 21, 2024 at 05:13:41PM +0000, Luck, Tony wrote:
> Example from <asm/intel-family.h>
> 
> #define INTEL_ALDERLAKE_L               IFM(6, 0x9A) /* Golden Cove / Gracemont */
> 
> #define INTEL_RAPTORLAKE                IFM(6, 0xB7) /* Raptor Cove / Enhanced Gracemont */
> 
> The native model number could be helpful to tell what each of your P-cores and E-cores
> are based on. Could be useful when the same base core is used in more than one SoC
> generation.

How am I supposed to read this?

Gracemont is the "native", base core and from that they do a Golden Cove and
a Raptor Cove?

What does that have to do with the P- and E-cores? Are those above two
different types wrt performance?

Thx.

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Luck, Tony]

> > #define INTEL_ALDERLAKE_L               IFM(6, 0x9A) /* Golden Cove / Gracemont */
> >
> > #define INTEL_RAPTORLAKE                IFM(6, 0xB7) /* Raptor Cove / Enhanced Gracemont */
> >
> > The native model number could be helpful to tell what each of your P-cores and E-cores
> > are based on. Could be useful when the same base core is used in more than one SoC
> > generation.
>
> How am I supposed to read this?
>
> Gracemont is the "native", base core and from that they do a Golden Cove and
> a Raptor Cove?
>
> What does that have to do with the P- and E-cores? Are those above two
> different types wrt performance?

If you are running on an Alder Lake you'll see that CPUID says you are
family 6, model 9A. CPUID will also tell you that this is a hybrid part
with both P-cores and E-cores. CPUID will tell you which logical CPUs
are P-cores and which are E-cores.

But in some cases you might want to know *which* E-core you have
(likely cases are for performance counters). The native model number
will help with that.

We probably ought to publish a table of native model numbers ... but
I don't know if there are plans to do that. Likely that Wikipedia will get
to that before Intel does. 

-Tony

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Mario Limonciello]

On 9/30/2024 09:47, Pawan Gupta wrote:
> Sometimes it is required to take actions based on if a CPU is a performance
> or efficiency core. As an example, intel_pstate driver uses the Intel
> core-type to determine CPU scaling. Also, some CPU vulnerabilities only
> affect a specific CPU type, like RFDS only affects Intel Atom. Hybrid
> systems that have variants P+E, P-only(Core) and E-only(Atom), it is not
> straightforward to identify which variant is affected by a type specific
> vulnerability.
> 
> Such processors do have CPUID field that can uniquely identify them. Like,
> P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while
> P+E additionally enumerates CPUID.7.HYBRID. Based on this information, it
> is possible for boot CPU to identify if a system has mixed CPU types.
> 
> Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
> hardware specific CPU type. This saves the overhead of IPIs to get the CPU
> type of a different CPU. CPU type is populated early in the boot process,
> before vulnerabilities are enumerated.
> 
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
>   arch/x86/include/asm/cpu.h            |  6 ++++++
>   arch/x86/include/asm/processor.h      | 11 +++++++++++
>   arch/x86/include/asm/topology.h       |  8 ++++++++
>   arch/x86/kernel/cpu/debugfs.c         |  1 +
>   arch/x86/kernel/cpu/intel.c           |  5 +++++
>   arch/x86/kernel/cpu/topology_common.c | 11 +++++++++++
>   6 files changed, 42 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> index aa30fd8cad7f..2244dd86066a 100644
> --- a/arch/x86/include/asm/cpu.h
> +++ b/arch/x86/include/asm/cpu.h
> @@ -32,6 +32,7 @@ extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
>   extern bool handle_guest_split_lock(unsigned long ip);
>   extern void handle_bus_lock(struct pt_regs *regs);
>   u8 get_this_hybrid_cpu_type(void);
> +u32 intel_native_model_id(struct cpuinfo_x86 *c);
>   #else
>   static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
>   static inline bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> @@ -50,6 +51,11 @@ static inline u8 get_this_hybrid_cpu_type(void)
>   {
>   	return 0;
>   }
> +
> +static u32 intel_native_model_id(struct cpuinfo_x86 *c)
> +{
> +	return 0;
> +}
>   #endif
>   #ifdef CONFIG_IA32_FEAT_CTL
>   void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 4a686f0e5dbf..61c8336bc99b 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -105,6 +105,17 @@ struct cpuinfo_topology {
>   	// Cache level topology IDs
>   	u32			llc_id;
>   	u32			l2c_id;
> +
> +	// Hardware defined CPU-type
> +	union {
> +		u32		hw_cpu_type;
> +		struct {
> +			/* CPUID.1A.EAX[23-0] */
> +			u32	intel_core_native_model_id:24;
> +			/* CPUID.1A.EAX[31-24] */
> +			u32	intel_core_type:8;
> +		};
> +	};
>   };
>   
>   struct cpuinfo_x86 {
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index aef70336d624..faf7cb7f7d7e 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -114,6 +114,12 @@ enum x86_topology_domains {
>   	TOPO_MAX_DOMAIN,
>   };
>   
> +enum x86_topology_hw_cpu_type {
> +	TOPO_HW_CPU_TYPE_UNKNOWN	= 0,
> +	TOPO_HW_CPU_TYPE_INTEL_ATOM	= 0x20,
> +	TOPO_HW_CPU_TYPE_INTEL_CORE	= 0x40,
> +};

This isn't exactly generic.  Unless you have a strong need to know 
"Atom" instead of "Efficient" or "Core" instead of "Performance" I think 
it would be better to do this as:

enum x86_topology_hw_core_type {
	TOPO_HW_CORE_TYPE_UNKNOWN	= 0,
	TOPO_HW_CORE_TYPE_PERFORMANT,
	TOPO_HW_CORE_TYPE_EFFICIENT,
};

Then you can do the mapping of 0x20 = Efficient and 0x40 = performant in 
the Intel topology lookup function.

After you land the series we can do something similar to move AMD code 
around and map it out to the right generic mapping.

> +
>   struct x86_topology_system {
>   	unsigned int	dom_shifts[TOPO_MAX_DOMAIN];
>   	unsigned int	dom_size[TOPO_MAX_DOMAIN];
> @@ -149,6 +155,8 @@ extern unsigned int __max_threads_per_core;
>   extern unsigned int __num_threads_per_package;
>   extern unsigned int __num_cores_per_package;
>   
> +enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c);
> +
>   static inline unsigned int topology_max_packages(void)
>   {
>   	return __max_logical_packages;
> diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c
> index ca373b990c47..d1731e0e36b0 100644
> --- a/arch/x86/kernel/cpu/debugfs.c
> +++ b/arch/x86/kernel/cpu/debugfs.c
> @@ -22,6 +22,7 @@ static int cpu_debug_show(struct seq_file *m, void *p)
>   	seq_printf(m, "die_id:              %u\n", c->topo.die_id);
>   	seq_printf(m, "cu_id:               %u\n", c->topo.cu_id);
>   	seq_printf(m, "core_id:             %u\n", c->topo.core_id);
> +	seq_printf(m, "hw_cpu_type:       0x%x\n", c->topo.hw_cpu_type);
>   	seq_printf(m, "logical_pkg_id:      %u\n", c->topo.logical_pkg_id);
>   	seq_printf(m, "logical_die_id:      %u\n", c->topo.logical_die_id);
>   	seq_printf(m, "llc_id:              %u\n", c->topo.llc_id);
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index e7656cbef68d..e56401c5c050 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -1299,3 +1299,8 @@ u8 get_this_hybrid_cpu_type(void)
>   
>   	return cpuid_eax(0x0000001a) >> X86_HYBRID_CPU_TYPE_ID_SHIFT;
>   }
> +
> +u32 intel_native_model_id(struct cpuinfo_x86 *c)
> +{
> +	return c->topo.intel_core_native_model_id;
> +}
> diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
> index 9a6069e7133c..e4814cd3d8ae 100644
> --- a/arch/x86/kernel/cpu/topology_common.c
> +++ b/arch/x86/kernel/cpu/topology_common.c
> @@ -27,6 +27,14 @@ void topology_set_dom(struct topo_scan *tscan, enum x86_topology_domains dom,
>   	}
>   }
>   
> +enum x86_topology_hw_cpu_type topology_hw_cpu_type(struct cpuinfo_x86 *c)
> +{
> +	if (c->x86_vendor == X86_VENDOR_INTEL)
> +		return c->topo.intel_core_type;
> +
> +	return c->topo.hw_cpu_type;
> +}
> +
>   static unsigned int __maybe_unused parse_num_cores_legacy(struct cpuinfo_x86 *c)
>   {
>   	struct {
> @@ -87,6 +95,7 @@ static void parse_topology(struct topo_scan *tscan, bool early)
>   		.cu_id			= 0xff,
>   		.llc_id			= BAD_APICID,
>   		.l2c_id			= BAD_APICID,
> +		.hw_cpu_type		= TOPO_HW_CPU_TYPE_UNKNOWN,
>   	};
>   	struct cpuinfo_x86 *c = tscan->c;
>   	struct {
> @@ -132,6 +141,8 @@ 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.hw_cpu_type = cpuid_eax(0x1a);
>   		break;
>   	case X86_VENDOR_HYGON:
>   		if (IS_ENABLED(CONFIG_CPU_SUP_HYGON))
> 

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Pawan Gupta]

On Fri, Oct 18, 2024 at 11:28:31AM -0500, Mario Limonciello wrote:
> On 9/30/2024 09:47, Pawan Gupta wrote:
> > Sometimes it is required to take actions based on if a CPU is a performance
> > or efficiency core. As an example, intel_pstate driver uses the Intel
> > core-type to determine CPU scaling. Also, some CPU vulnerabilities only
> > affect a specific CPU type, like RFDS only affects Intel Atom. Hybrid
> > systems that have variants P+E, P-only(Core) and E-only(Atom), it is not
> > straightforward to identify which variant is affected by a type specific
> > vulnerability.
> > 
> > Such processors do have CPUID field that can uniquely identify them. Like,
> > P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while
> > P+E additionally enumerates CPUID.7.HYBRID. Based on this information, it
> > is possible for boot CPU to identify if a system has mixed CPU types.
> > 
> > Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
> > hardware specific CPU type. This saves the overhead of IPIs to get the CPU
> > type of a different CPU. CPU type is populated early in the boot process,
> > before vulnerabilities are enumerated.
> > 
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
> >   arch/x86/include/asm/cpu.h            |  6 ++++++
> >   arch/x86/include/asm/processor.h      | 11 +++++++++++
> >   arch/x86/include/asm/topology.h       |  8 ++++++++
> >   arch/x86/kernel/cpu/debugfs.c         |  1 +
> >   arch/x86/kernel/cpu/intel.c           |  5 +++++
> >   arch/x86/kernel/cpu/topology_common.c | 11 +++++++++++
> >   6 files changed, 42 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> > index aa30fd8cad7f..2244dd86066a 100644
> > --- a/arch/x86/include/asm/cpu.h
> > +++ b/arch/x86/include/asm/cpu.h
> > @@ -32,6 +32,7 @@ extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
> >   extern bool handle_guest_split_lock(unsigned long ip);
> >   extern void handle_bus_lock(struct pt_regs *regs);
> >   u8 get_this_hybrid_cpu_type(void);
> > +u32 intel_native_model_id(struct cpuinfo_x86 *c);
> >   #else
> >   static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
> >   static inline bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> > @@ -50,6 +51,11 @@ static inline u8 get_this_hybrid_cpu_type(void)
> >   {
> >   	return 0;
> >   }
> > +
> > +static u32 intel_native_model_id(struct cpuinfo_x86 *c)
> > +{
> > +	return 0;
> > +}
> >   #endif
> >   #ifdef CONFIG_IA32_FEAT_CTL
> >   void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 4a686f0e5dbf..61c8336bc99b 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -105,6 +105,17 @@ struct cpuinfo_topology {
> >   	// Cache level topology IDs
> >   	u32			llc_id;
> >   	u32			l2c_id;
> > +
> > +	// Hardware defined CPU-type
> > +	union {
> > +		u32		hw_cpu_type;
> > +		struct {
> > +			/* CPUID.1A.EAX[23-0] */
> > +			u32	intel_core_native_model_id:24;
> > +			/* CPUID.1A.EAX[31-24] */
> > +			u32	intel_core_type:8;
> > +		};
> > +	};
> >   };
> >   struct cpuinfo_x86 {
> > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > index aef70336d624..faf7cb7f7d7e 100644
> > --- a/arch/x86/include/asm/topology.h
> > +++ b/arch/x86/include/asm/topology.h
> > @@ -114,6 +114,12 @@ enum x86_topology_domains {
> >   	TOPO_MAX_DOMAIN,
> >   };
> > +enum x86_topology_hw_cpu_type {
> > +	TOPO_HW_CPU_TYPE_UNKNOWN	= 0,
> > +	TOPO_HW_CPU_TYPE_INTEL_ATOM	= 0x20,
> > +	TOPO_HW_CPU_TYPE_INTEL_CORE	= 0x40,
> > +};
> 
> This isn't exactly generic.  Unless you have a strong need to know "Atom"

The goal was not to have generic cpu_type here, but the actual CPU type
that hardware enumerates. I was asked to prepend "hw_" to cpu_type to make
is clear that this is hardware defined, and to leave scope for generic
cpu_type, if we add those in future.

> instead of "Efficient" or "Core" instead of "Performance" I think it would
> be better to do this as:
>
> enum x86_topology_hw_core_type {
> 	TOPO_HW_CORE_TYPE_UNKNOWN	= 0,
> 	TOPO_HW_CORE_TYPE_PERFORMANT,
> 	TOPO_HW_CORE_TYPE_EFFICIENT,
> };
>
> Then you can do the mapping of 0x20 = Efficient and 0x40 = performant in the
> Intel topology lookup function.

I can add a lookup function, but I wanted to understand the use case of
generic cpu_type. If we always have to lookup and map the cpu_type, then
why not have the actual cpu_type in the first place?

One case where generic cpu_type can be useful is when we expose them to
userspace, which I think is inevitable. Overall I am fine with adding generic
cpu type. It may also make sense to have separate accessors for generic and
and hardware defined cpu_type, and the generic ones when we actually have a
use case. Thoughts?

> After you land the series we can do something similar to move AMD code
> around and map it out to the right generic mapping.

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Mario Limonciello]

On 10/18/2024 16:11, Pawan Gupta wrote:
> On Fri, Oct 18, 2024 at 11:28:31AM -0500, Mario Limonciello wrote:
>> On 9/30/2024 09:47, Pawan Gupta wrote:
>>> Sometimes it is required to take actions based on if a CPU is a performance
>>> or efficiency core. As an example, intel_pstate driver uses the Intel
>>> core-type to determine CPU scaling. Also, some CPU vulnerabilities only
>>> affect a specific CPU type, like RFDS only affects Intel Atom. Hybrid
>>> systems that have variants P+E, P-only(Core) and E-only(Atom), it is not
>>> straightforward to identify which variant is affected by a type specific
>>> vulnerability.
>>>
>>> Such processors do have CPUID field that can uniquely identify them. Like,
>>> P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while
>>> P+E additionally enumerates CPUID.7.HYBRID. Based on this information, it
>>> is possible for boot CPU to identify if a system has mixed CPU types.
>>>
>>> Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
>>> hardware specific CPU type. This saves the overhead of IPIs to get the CPU
>>> type of a different CPU. CPU type is populated early in the boot process,
>>> before vulnerabilities are enumerated.
>>>
>>> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>>> ---
>>>    arch/x86/include/asm/cpu.h            |  6 ++++++
>>>    arch/x86/include/asm/processor.h      | 11 +++++++++++
>>>    arch/x86/include/asm/topology.h       |  8 ++++++++
>>>    arch/x86/kernel/cpu/debugfs.c         |  1 +
>>>    arch/x86/kernel/cpu/intel.c           |  5 +++++
>>>    arch/x86/kernel/cpu/topology_common.c | 11 +++++++++++
>>>    6 files changed, 42 insertions(+)
>>>
>>> diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
>>> index aa30fd8cad7f..2244dd86066a 100644
>>> --- a/arch/x86/include/asm/cpu.h
>>> +++ b/arch/x86/include/asm/cpu.h
>>> @@ -32,6 +32,7 @@ extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
>>>    extern bool handle_guest_split_lock(unsigned long ip);
>>>    extern void handle_bus_lock(struct pt_regs *regs);
>>>    u8 get_this_hybrid_cpu_type(void);
>>> +u32 intel_native_model_id(struct cpuinfo_x86 *c);
>>>    #else
>>>    static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
>>>    static inline bool handle_user_split_lock(struct pt_regs *regs, long error_code)
>>> @@ -50,6 +51,11 @@ static inline u8 get_this_hybrid_cpu_type(void)
>>>    {
>>>    	return 0;
>>>    }
>>> +
>>> +static u32 intel_native_model_id(struct cpuinfo_x86 *c)
>>> +{
>>> +	return 0;
>>> +}
>>>    #endif
>>>    #ifdef CONFIG_IA32_FEAT_CTL
>>>    void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
>>> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
>>> index 4a686f0e5dbf..61c8336bc99b 100644
>>> --- a/arch/x86/include/asm/processor.h
>>> +++ b/arch/x86/include/asm/processor.h
>>> @@ -105,6 +105,17 @@ struct cpuinfo_topology {
>>>    	// Cache level topology IDs
>>>    	u32			llc_id;
>>>    	u32			l2c_id;
>>> +
>>> +	// Hardware defined CPU-type
>>> +	union {
>>> +		u32		hw_cpu_type;
>>> +		struct {
>>> +			/* CPUID.1A.EAX[23-0] */
>>> +			u32	intel_core_native_model_id:24;
>>> +			/* CPUID.1A.EAX[31-24] */
>>> +			u32	intel_core_type:8;
>>> +		};
>>> +	};
>>>    };
>>>    struct cpuinfo_x86 {
>>> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
>>> index aef70336d624..faf7cb7f7d7e 100644
>>> --- a/arch/x86/include/asm/topology.h
>>> +++ b/arch/x86/include/asm/topology.h
>>> @@ -114,6 +114,12 @@ enum x86_topology_domains {
>>>    	TOPO_MAX_DOMAIN,
>>>    };
>>> +enum x86_topology_hw_cpu_type {
>>> +	TOPO_HW_CPU_TYPE_UNKNOWN	= 0,
>>> +	TOPO_HW_CPU_TYPE_INTEL_ATOM	= 0x20,
>>> +	TOPO_HW_CPU_TYPE_INTEL_CORE	= 0x40,
>>> +};
>>
>> This isn't exactly generic.  Unless you have a strong need to know "Atom"
> 
> The goal was not to have generic cpu_type here, but the actual CPU type
> that hardware enumerates. I was asked to prepend "hw_" to cpu_type to make
> is clear that this is hardware defined, and to leave scope for generic
> cpu_type, if we add those in future.
> 
>> instead of "Efficient" or "Core" instead of "Performance" I think it would
>> be better to do this as:
>>
>> enum x86_topology_hw_core_type {
>> 	TOPO_HW_CORE_TYPE_UNKNOWN	= 0,
>> 	TOPO_HW_CORE_TYPE_PERFORMANT,
>> 	TOPO_HW_CORE_TYPE_EFFICIENT,
>> };
>>
>> Then you can do the mapping of 0x20 = Efficient and 0x40 = performant in the
>> Intel topology lookup function.
> 
> I can add a lookup function, but I wanted to understand the use case of
> generic cpu_type. If we always have to lookup and map the cpu_type, then
> why not have the actual cpu_type in the first place?
> 
> One case where generic cpu_type can be useful is when we expose them to
> userspace, which I think is inevitable. Overall I am fine with adding generic
> cpu type. It may also make sense to have separate accessors for generic and
> and hardware defined cpu_type, and the generic ones when we actually have a
> use case. Thoughts?
> 
>> After you land the series we can do something similar to move AMD code
>> around and map it out to the right generic mapping.

I took your patch and made the modifications that I thought made sense 
for a generic type while adding the matching AMD code and sent it out 
(you're on CC).  Can you take a look and see what you think?  Boris 
already provided some feedback that I'm going to spin it again.
I think if we can align on that one we can land that patch and you can 
rebase the rest of the series on it.

Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology

[Pawan Gupta]

On Tue, Oct 22, 2024 at 09:42:37AM -0500, Mario Limonciello wrote:
> On 10/18/2024 16:11, Pawan Gupta wrote:
> > On Fri, Oct 18, 2024 at 11:28:31AM -0500, Mario Limonciello wrote:
> > > On 9/30/2024 09:47, Pawan Gupta wrote:
> > > > Sometimes it is required to take actions based on if a CPU is a performance
> > > > or efficiency core. As an example, intel_pstate driver uses the Intel
> > > > core-type to determine CPU scaling. Also, some CPU vulnerabilities only
> > > > affect a specific CPU type, like RFDS only affects Intel Atom. Hybrid
> > > > systems that have variants P+E, P-only(Core) and E-only(Atom), it is not
> > > > straightforward to identify which variant is affected by a type specific
> > > > vulnerability.
> > > > 
> > > > Such processors do have CPUID field that can uniquely identify them. Like,
> > > > P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while
> > > > P+E additionally enumerates CPUID.7.HYBRID. Based on this information, it
> > > > is possible for boot CPU to identify if a system has mixed CPU types.
> > > > 
> > > > Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
> > > > hardware specific CPU type. This saves the overhead of IPIs to get the CPU
> > > > type of a different CPU. CPU type is populated early in the boot process,
> > > > before vulnerabilities are enumerated.
> > > > 
> > > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > > > ---
> > > >    arch/x86/include/asm/cpu.h            |  6 ++++++
> > > >    arch/x86/include/asm/processor.h      | 11 +++++++++++
> > > >    arch/x86/include/asm/topology.h       |  8 ++++++++
> > > >    arch/x86/kernel/cpu/debugfs.c         |  1 +
> > > >    arch/x86/kernel/cpu/intel.c           |  5 +++++
> > > >    arch/x86/kernel/cpu/topology_common.c | 11 +++++++++++
> > > >    6 files changed, 42 insertions(+)
> > > > 
> > > > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> > > > index aa30fd8cad7f..2244dd86066a 100644
> > > > --- a/arch/x86/include/asm/cpu.h
> > > > +++ b/arch/x86/include/asm/cpu.h
> > > > @@ -32,6 +32,7 @@ extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
> > > >    extern bool handle_guest_split_lock(unsigned long ip);
> > > >    extern void handle_bus_lock(struct pt_regs *regs);
> > > >    u8 get_this_hybrid_cpu_type(void);
> > > > +u32 intel_native_model_id(struct cpuinfo_x86 *c);
> > > >    #else
> > > >    static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
> > > >    static inline bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> > > > @@ -50,6 +51,11 @@ static inline u8 get_this_hybrid_cpu_type(void)
> > > >    {
> > > >    	return 0;
> > > >    }
> > > > +
> > > > +static u32 intel_native_model_id(struct cpuinfo_x86 *c)
> > > > +{
> > > > +	return 0;
> > > > +}
> > > >    #endif
> > > >    #ifdef CONFIG_IA32_FEAT_CTL
> > > >    void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
> > > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > > > index 4a686f0e5dbf..61c8336bc99b 100644
> > > > --- a/arch/x86/include/asm/processor.h
> > > > +++ b/arch/x86/include/asm/processor.h
> > > > @@ -105,6 +105,17 @@ struct cpuinfo_topology {
> > > >    	// Cache level topology IDs
> > > >    	u32			llc_id;
> > > >    	u32			l2c_id;
> > > > +
> > > > +	// Hardware defined CPU-type
> > > > +	union {
> > > > +		u32		hw_cpu_type;
> > > > +		struct {
> > > > +			/* CPUID.1A.EAX[23-0] */
> > > > +			u32	intel_core_native_model_id:24;
> > > > +			/* CPUID.1A.EAX[31-24] */
> > > > +			u32	intel_core_type:8;
> > > > +		};
> > > > +	};
> > > >    };
> > > >    struct cpuinfo_x86 {
> > > > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > > > index aef70336d624..faf7cb7f7d7e 100644
> > > > --- a/arch/x86/include/asm/topology.h
> > > > +++ b/arch/x86/include/asm/topology.h
> > > > @@ -114,6 +114,12 @@ enum x86_topology_domains {
> > > >    	TOPO_MAX_DOMAIN,
> > > >    };
> > > > +enum x86_topology_hw_cpu_type {
> > > > +	TOPO_HW_CPU_TYPE_UNKNOWN	= 0,
> > > > +	TOPO_HW_CPU_TYPE_INTEL_ATOM	= 0x20,
> > > > +	TOPO_HW_CPU_TYPE_INTEL_CORE	= 0x40,
> > > > +};
> > > 
> > > This isn't exactly generic.  Unless you have a strong need to know "Atom"
> > 
> > The goal was not to have generic cpu_type here, but the actual CPU type
> > that hardware enumerates. I was asked to prepend "hw_" to cpu_type to make
> > is clear that this is hardware defined, and to leave scope for generic
> > cpu_type, if we add those in future.
> > 
> > > instead of "Efficient" or "Core" instead of "Performance" I think it would
> > > be better to do this as:
> > > 
> > > enum x86_topology_hw_core_type {
> > > 	TOPO_HW_CORE_TYPE_UNKNOWN	= 0,
> > > 	TOPO_HW_CORE_TYPE_PERFORMANT,
> > > 	TOPO_HW_CORE_TYPE_EFFICIENT,
> > > };
> > > 
> > > Then you can do the mapping of 0x20 = Efficient and 0x40 = performant in the
> > > Intel topology lookup function.
> > 
> > I can add a lookup function, but I wanted to understand the use case of
> > generic cpu_type. If we always have to lookup and map the cpu_type, then
> > why not have the actual cpu_type in the first place?
> > 
> > One case where generic cpu_type can be useful is when we expose them to
> > userspace, which I think is inevitable. Overall I am fine with adding generic
> > cpu type. It may also make sense to have separate accessors for generic and
> > and hardware defined cpu_type, and the generic ones when we actually have a
> > use case. Thoughts?
> > 
> > > After you land the series we can do something similar to move AMD code
> > > around and map it out to the right generic mapping.
> 
> I took your patch and made the modifications that I thought made sense for a
> generic type while adding the matching AMD code and sent it out (you're on
> CC).  Can you take a look and see what you think?  Boris already provided
> some feedback that I'm going to spin it again.
> I think if we can align on that one we can land that patch and you can
> rebase the rest of the series on it.

I left some feedback on that series. Overall it looks good. For Intel's use
case it needs to add accessor for hardware defined cpu_type. This is needed
for cpu-type matching in affected processor list.

[PATCH v4 03/10] cpufreq: intel_pstate: Use topology_hw_cpu_type()

[Pawan Gupta]

Intel pstate driver relies on SMP calls to get the cpu-type of a given CPU.
Replace the SMP calls with more efficient topology_hw_cpu_type(cpu) that
returns the per-cpu cached value.

Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 drivers/cpufreq/intel_pstate.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index aaea9a39eced..1d37b2a7b3b1 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2193,24 +2193,16 @@ static int knl_get_turbo_pstate(int cpu)
 	return ret;
 }
 
-static void hybrid_get_type(void *data)
-{
-	u8 *cpu_type = data;
-
-	*cpu_type = get_this_hybrid_cpu_type();
-}
-
 static int hwp_get_cpu_scaling(int cpu)
 {
-	u8 cpu_type = 0;
+	u8 cpu_type = topology_hw_cpu_type(&cpu_data(cpu));
 
-	smp_call_function_single(cpu, hybrid_get_type, &cpu_type, 1);
 	/* P-cores have a smaller perf level-to-freqency scaling factor. */
-	if (cpu_type == 0x40)
+	if (cpu_type == TOPO_HW_CPU_TYPE_INTEL_CORE)
 		return hybrid_scaling_factor;
 
 	/* Use default core scaling for E-cores */
-	if (cpu_type == 0x20)
+	if (cpu_type == TOPO_HW_CPU_TYPE_INTEL_ATOM)
 		return core_get_scaling();
 
 	/*

-- 
2.34.1

[PATCH v4 04/10] perf/x86/intel: Use topology_hw_cpu_type()

[Pawan Gupta]

get_this_hybrid_cpu_type() misses a case when cpu-type is populated
regardless of X86_FEATURE_HYBRID_CPU. This is particularly true for hybrid
variants that have P or E cores fused off.

Instead use topology_hw_cpu_type() as it does not rely on hybrid feature to
enumerate cpu-type. This can also help avoid the model-specific fixup
get_hybrid_cpu_type().

Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/events/intel/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index d879478db3f5..80a2a307e678 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4906,7 +4906,8 @@ static void intel_pmu_check_hybrid_pmus(struct x86_hybrid_pmu *pmu)
 
 static struct x86_hybrid_pmu *find_hybrid_pmu_for_cpu(void)
 {
-	u8 cpu_type = get_this_hybrid_cpu_type();
+	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
+	u8 cpu_type = topology_hw_cpu_type(c);
 	int i;
 
 	/*

-- 
2.34.1

Re: [PATCH v4 04/10] perf/x86/intel: Use topology_hw_cpu_type()

[Liang, Kan]

Hi Pawan,

On 2024-09-30 10:47 a.m., Pawan Gupta wrote:
> get_this_hybrid_cpu_type() misses a case when cpu-type is populated
> regardless of X86_FEATURE_HYBRID_CPU. This is particularly true for hybrid
> variants that have P or E cores fused off.
> 
> Instead use topology_hw_cpu_type() as it does not rely on hybrid feature to
> enumerate cpu-type. This can also help avoid the model-specific fixup
> get_hybrid_cpu_type().
> 
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
>  arch/x86/events/intel/core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index d879478db3f5..80a2a307e678 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -4906,7 +4906,8 @@ static void intel_pmu_check_hybrid_pmus(struct x86_hybrid_pmu *pmu)
>  
>  static struct x86_hybrid_pmu *find_hybrid_pmu_for_cpu(void)
>  {
> -	u8 cpu_type = get_this_hybrid_cpu_type();
> +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> +	u8 cpu_type = topology_hw_cpu_type(c);
>  	int i;
>  
>  	/*
> 

Dapeng's patch to utilize the native model ID in perf has been merged.
Please replace the get_this_hybrid_cpu_native_id() as well when you spin
a new version.
https://lore.kernel.org/all/20240820073853.1974746-4-dapeng1.mi@linux.intel.com/

Thanks,
Kan

Re: [PATCH v4 04/10] perf/x86/intel: Use topology_hw_cpu_type()

[Pawan Gupta]

On Mon, Oct 21, 2024 at 09:54:57AM -0400, Liang, Kan wrote:
> Hi Pawan,
> 
> On 2024-09-30 10:47 a.m., Pawan Gupta wrote:
> > get_this_hybrid_cpu_type() misses a case when cpu-type is populated
> > regardless of X86_FEATURE_HYBRID_CPU. This is particularly true for hybrid
> > variants that have P or E cores fused off.
> > 
> > Instead use topology_hw_cpu_type() as it does not rely on hybrid feature to
> > enumerate cpu-type. This can also help avoid the model-specific fixup
> > get_hybrid_cpu_type().
> > 
> > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
> >  arch/x86/events/intel/core.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index d879478db3f5..80a2a307e678 100644
> > --- a/arch/x86/events/intel/core.c
> > +++ b/arch/x86/events/intel/core.c
> > @@ -4906,7 +4906,8 @@ static void intel_pmu_check_hybrid_pmus(struct x86_hybrid_pmu *pmu)
> >  
> >  static struct x86_hybrid_pmu *find_hybrid_pmu_for_cpu(void)
> >  {
> > -	u8 cpu_type = get_this_hybrid_cpu_type();
> > +	struct cpuinfo_x86 *c = &cpu_data(smp_processor_id());
> > +	u8 cpu_type = topology_hw_cpu_type(c);
> >  	int i;
> >  
> >  	/*
> > 
> 
> Dapeng's patch to utilize the native model ID in perf has been merged.
> Please replace the get_this_hybrid_cpu_native_id() as well when you spin
> a new version.

Will do. Thanks for letting me know.

[PATCH v4 05/10] x86/cpu: Remove get_this_hybrid_cpu_type()

[Pawan Gupta]

Because calls to get_this_hybrid_cpu_type() were replaced by
topology_hw_cpu_type().

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/include/asm/cpu.h  |  6 ------
 arch/x86/kernel/cpu/intel.c | 16 ----------------
 2 files changed, 22 deletions(-)

diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 2244dd86066a..c53a98751a92 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -31,7 +31,6 @@ extern void __init sld_setup(struct cpuinfo_x86 *c);
 extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
 extern bool handle_guest_split_lock(unsigned long ip);
 extern void handle_bus_lock(struct pt_regs *regs);
-u8 get_this_hybrid_cpu_type(void);
 u32 intel_native_model_id(struct cpuinfo_x86 *c);
 #else
 static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
@@ -47,11 +46,6 @@ static inline bool handle_guest_split_lock(unsigned long ip)
 
 static inline void handle_bus_lock(struct pt_regs *regs) {}
 
-static inline u8 get_this_hybrid_cpu_type(void)
-{
-	return 0;
-}
-
 static u32 intel_native_model_id(struct cpuinfo_x86 *c)
 {
 	return 0;
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index e56401c5c050..4536206e6b3c 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1284,22 +1284,6 @@ void __init sld_setup(struct cpuinfo_x86 *c)
 	sld_state_show();
 }
 
-#define X86_HYBRID_CPU_TYPE_ID_SHIFT	24
-
-/**
- * get_this_hybrid_cpu_type() - Get the type of this hybrid CPU
- *
- * Returns the CPU type [31:24] (i.e., Atom or Core) of a CPU in
- * a hybrid processor. If the processor is not hybrid, returns 0.
- */
-u8 get_this_hybrid_cpu_type(void)
-{
-	if (!cpu_feature_enabled(X86_FEATURE_HYBRID_CPU))
-		return 0;
-
-	return cpuid_eax(0x0000001a) >> X86_HYBRID_CPU_TYPE_ID_SHIFT;
-}
-
 u32 intel_native_model_id(struct cpuinfo_x86 *c)
 {
 	return c->topo.intel_core_native_model_id;

-- 
2.34.1

[PATCH v4 06/10] x86/cpu: Name CPU matching macro more generically (and shorten)

[Pawan Gupta]

To add cpu-type to the existing CPU matching infrastructure, the base macro
X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE need to append _CPU_TYPE. This
makes an already long name longer, and somewhat incomprehensible.

To avoid this, rename the base macro to X86_MATCH_CPU. The macro name
doesn't need to explicitly tell everything that it matches. The arguments
to the macro already hints what it matches.

For consistency, use this base macro to define X86_MATCH_VFM and friends.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/include/asm/cpu_device_id.h | 100 ++++++++++-------------------------
 1 file changed, 29 insertions(+), 71 deletions(-)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index e4121d9aa9e1..dee45332b682 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -58,7 +58,7 @@
 
 #define X86_STEPPINGS(mins, maxs)    GENMASK(maxs, mins)
 /**
- * X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE - Base macro for CPU matching
+ * X86_MATCH_CPU -  Base macro for CPU matching
  * @_vendor:	The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
  *		The name is expanded to X86_VENDOR_@_vendor
  * @_family:	The family number or X86_FAMILY_ANY
@@ -75,19 +75,7 @@
  * into another macro at the usage site for good reasons, then please
  * start this local macro with X86_MATCH to allow easy grepping.
  */
-#define X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
-						    _steppings, _feature, _data) { \
-	.vendor		= X86_VENDOR_##_vendor,				\
-	.family		= _family,					\
-	.model		= _model,					\
-	.steppings	= _steppings,					\
-	.feature	= _feature,					\
-	.flags		= X86_CPU_ID_FLAG_ENTRY_VALID,			\
-	.driver_data	= (unsigned long) _data				\
-}
-
-#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
-						    _steppings, _feature, _data) { \
+#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \
 	.vendor		= _vendor,					\
 	.family		= _family,					\
 	.model		= _model,					\
@@ -107,13 +95,10 @@
  * @_data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * The steppings arguments of X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE() is
- * set to wildcards.
  */
-#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \
-	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(vendor, family, model, \
-						X86_STEPPING_ANY, feature, data)
+#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data)	\
+	X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY,		\
+		      feature, data)
 
 /**
  * X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature
@@ -124,13 +109,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
  */
-#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data)	\
-	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family,		\
-					   X86_MODEL_ANY, feature, data)
+#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data)		\
+	X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY,		\
+		      X86_STEPPING_ANY, feature, data)
 
 /**
  * X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature
@@ -140,12 +122,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
  */
-#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data)			\
-	X86_MATCH_VENDOR_FAM_FEATURE(vendor, X86_FAMILY_ANY, feature, data)
+#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data)				\
+	X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY,	\
+		      X86_STEPPING_ANY, feature, data)
 
 /**
  * X86_MATCH_FEATURE - Macro for matching a CPU feature
@@ -153,12 +133,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
  */
-#define X86_MATCH_FEATURE(feature, data)				\
-	X86_MATCH_VENDOR_FEATURE(ANY, feature, data)
+#define X86_MATCH_FEATURE(feature, data)					\
+	X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY,		\
+		      X86_STEPPING_ANY, feature, data)
 
 /**
  * X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model
@@ -169,13 +147,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
  */
-#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data)		\
-	X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model,	\
-					   X86_FEATURE_ANY, data)
+#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data)			\
+	X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY,	\
+		      X86_FEATURE_ANY, data)
 
 /**
  * X86_MATCH_VENDOR_FAM - Match vendor and family
@@ -185,12 +160,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is casted to unsigned long internally.
- *
- * All other missing arguments to X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set of wildcards.
  */
-#define X86_MATCH_VENDOR_FAM(vendor, family, data)			\
-	X86_MATCH_VENDOR_FAM_MODEL(vendor, family, X86_MODEL_ANY, data)
+#define X86_MATCH_VENDOR_FAM(vendor, family, data)				\
+	X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY,		\
+		      X86_STEPPING_ANY, X86_FEATURE_ANY, data)
 
 /**
  * X86_MATCH_VFM - Match encoded vendor/family/model
@@ -198,15 +171,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is cast to unsigned long internally.
- *
- * Stepping and feature are set to wildcards
  */
-#define X86_MATCH_VFM(vfm, data)			\
-	X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(	\
-		VFM_VENDOR(vfm),			\
-		VFM_FAMILY(vfm),			\
-		VFM_MODEL(vfm),				\
-		X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+#define X86_MATCH_VFM(vfm, data)						\
+	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm),	VFM_MODEL(vfm),		\
+		      X86_STEPPING_ANY, X86_FEATURE_ANY, data)
 
 /**
  * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping
@@ -215,15 +183,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is cast to unsigned long internally.
- *
- * feature is set to wildcard
  */
-#define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data)	\
-	X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(	\
-		VFM_VENDOR(vfm),			\
-		VFM_FAMILY(vfm),			\
-		VFM_MODEL(vfm),				\
-		steppings, X86_FEATURE_ANY, data)
+#define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data)				\
+	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm),		\
+		      steppings, X86_FEATURE_ANY, data)
 
 /**
  * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
@@ -232,15 +195,10 @@
  * @data:	Driver specific data or NULL. The internal storage
  *		format is unsigned long. The supplied value, pointer
  *		etc. is cast to unsigned long internally.
- *
- * Steppings is set to wildcard
  */
-#define X86_MATCH_VFM_FEATURE(vfm, feature, data)	\
-	X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(	\
-		VFM_VENDOR(vfm),			\
-		VFM_FAMILY(vfm),			\
-		VFM_MODEL(vfm),				\
-		X86_STEPPING_ANY, feature, data)
+#define X86_MATCH_VFM_FEATURE(vfm, feature, data)				\
+	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm),		\
+		      X86_STEPPING_ANY, feature, data)
 
 /*
  * Match specific microcode revisions.

-- 
2.34.1

[PATCH v4 07/10] x86/cpu: Add cpu_type to struct x86_cpu_id

[Pawan Gupta]

In addition to matching vendor/family/model/feature, for hybrid variants it
is required to also match cpu-type also. For example some CPU
vulnerabilities only affect a specific cpu-type. RFDS only affects Intel
Atom parts.

To be able to also match CPUs based on type add a new field cpu_type to
struct x86_cpu_id which is used by the CPU-matching tables. Introduce
X86_CPU_TYPE_ANY for the cases that don't care about the cpu-type.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/include/asm/cpu_device_id.h | 33 +++++++++++++++++++++++----------
 include/linux/mod_devicetable.h      |  2 ++
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index dee45332b682..f50377a32cb6 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -75,13 +75,14 @@
  * into another macro at the usage site for good reasons, then please
  * start this local macro with X86_MATCH to allow easy grepping.
  */
-#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \
+#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _cpu_type, _data) { \
 	.vendor		= _vendor,					\
 	.family		= _family,					\
 	.model		= _model,					\
 	.steppings	= _steppings,					\
 	.feature	= _feature,					\
 	.flags		= X86_CPU_ID_FLAG_ENTRY_VALID,			\
+	.cpu_type	= _cpu_type,					\
 	.driver_data	= (unsigned long) _data				\
 }
 
@@ -98,7 +99,7 @@
  */
 #define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data)	\
 	X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY,		\
-		      feature, data)
+		      feature, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature
@@ -112,7 +113,7 @@
  */
 #define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data)		\
 	X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY,		\
-		      X86_STEPPING_ANY, feature, data)
+		      X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature
@@ -125,7 +126,7 @@
  */
 #define X86_MATCH_VENDOR_FEATURE(vendor, feature, data)				\
 	X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY,	\
-		      X86_STEPPING_ANY, feature, data)
+		      X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_FEATURE - Macro for matching a CPU feature
@@ -136,7 +137,7 @@
  */
 #define X86_MATCH_FEATURE(feature, data)					\
 	X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY,		\
-		      X86_STEPPING_ANY, feature, data)
+		      X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model
@@ -150,7 +151,7 @@
  */
 #define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data)			\
 	X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY,	\
-		      X86_FEATURE_ANY, data)
+		      X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VENDOR_FAM - Match vendor and family
@@ -163,7 +164,7 @@
  */
 #define X86_MATCH_VENDOR_FAM(vendor, family, data)				\
 	X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY,		\
-		      X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+		      X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VFM - Match encoded vendor/family/model
@@ -174,7 +175,7 @@
  */
 #define X86_MATCH_VFM(vfm, data)						\
 	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm),	VFM_MODEL(vfm),		\
-		      X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+		      X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping
@@ -186,7 +187,7 @@
  */
 #define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data)				\
 	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm),		\
-		      steppings, X86_FEATURE_ANY, data)
+		      steppings, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
@@ -198,7 +199,19 @@
  */
 #define X86_MATCH_VFM_FEATURE(vfm, feature, data)				\
 	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm),		\
-		      X86_STEPPING_ANY, feature, data)
+		      X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
+
+/**
+ * X86_MATCH_VFM_CPU_TYPE - Match encoded vendor/family/model/cpu-type
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @cpu_type:	CPU type e.g. P-core, E-core on Intel
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is cast to unsigned long internally.
+ */
+#define X86_MATCH_VFM_CPU_TYPE(vfm, cpu_type, data)			\
+	X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm),	\
+		      X86_STEPPING_ANY, X86_FEATURE_ANY, cpu_type, data)
 
 /*
  * Match specific microcode revisions.
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 4338b1b4ac44..b8a2e88f966f 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -692,6 +692,7 @@ struct x86_cpu_id {
 	__u16 feature;	/* bit index */
 	/* Solely for kernel-internal use: DO NOT EXPORT to userspace! */
 	__u16 flags;
+	__u8  cpu_type;
 	kernel_ulong_t driver_data;
 };
 
@@ -701,6 +702,7 @@ struct x86_cpu_id {
 #define X86_MODEL_ANY  0
 #define X86_STEPPING_ANY 0
 #define X86_FEATURE_ANY 0	/* Same as FPU, you can't test for that */
+#define X86_CPU_TYPE_ANY 0
 
 /*
  * Generic table type for matching CPU features.

-- 
2.34.1

[PATCH v4 08/10] x86/cpu: Update x86_match_cpu() to also use cpu-type

[Pawan Gupta]

Non-hybrid CPU variants that share the same Family/Model could be
differentiated by their cpu-type. x86_match_cpu() currently does not use
cpu-type for CPU matching.

Dave Hansen suggested to use below conditions to match CPU-type:

  1. If CPU_TYPE_ANY (the wildcard), then matched
  2. If hybrid, then matched
  3. If !hybrid, look at the boot CPU and compare the cpu-type to determine
     if it is a match.

  This special case for hybrid systems allows more compact vulnerability
  list.  Imagine that "Haswell" CPUs might or might not be hybrid and that
  only Atom cores are vulnerable to Meltdown.  That means there are three
  possibilities:

  	1. P-core only
  	2. Atom only
  	3. Atom + P-core (aka. hybrid)

  One might be tempted to code up the vulnerability list like this:

  	MATCH(     HASWELL, X86_FEATURE_HYBRID, MELTDOWN)
  	MATCH_TYPE(HASWELL, ATOM,               MELTDOWN)

  Logically, this matches #2 and #3. But that's a little silly. You would
  only ask for the "ATOM" match in cases where there *WERE* hybrid cores in
  play. You shouldn't have to _also_ ask for hybrid cores explicitly.

  In short, assume that processors that enumerate Hybrid==1 have a
  vulnerable core type.

Update x86_match_cpu() to also match cpu-type. Also treat hybrid systems as
special, and match them to any cpu-type.

Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/kernel/cpu/match.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
index 8e7de733320a..351b583cb9b5 100644
--- a/arch/x86/kernel/cpu/match.c
+++ b/arch/x86/kernel/cpu/match.c
@@ -5,6 +5,26 @@
 #include <linux/export.h>
 #include <linux/slab.h>
 
+/**
+ * x86_match_hw_cpu_type - helper function to match the hardware defined
+ *                         cpu-type for a single entry in the x86_cpu_id table.
+ * @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_hw_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m)
+{
+	if (m->cpu_type == X86_CPU_TYPE_ANY)
+		return true;
+
+	/* Hybrid CPUs are special, they are assumed to match all cpu-types */
+	if (boot_cpu_has(X86_FEATURE_HYBRID_CPU))
+		return true;
+
+	return m->cpu_type == topology_hw_cpu_type(c);
+}
+
 /**
  * x86_match_cpu - match current CPU again an array of x86_cpu_ids
  * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
@@ -50,6 +70,8 @@ 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_hw_cpu_type(c, m))
+			continue;
 		return m;
 	}
 	return NULL;

-- 
2.34.1

[PATCH v4 09/10] x86/bugs: Declutter vulnerable CPU list

[Pawan Gupta]

The affected processor table has a lot of repetition and redundant
information that can be omitted. For example:

  VULNBL_INTEL_STEPPINGS(INTEL_IVYBRIDGE,		X86_STEPPING_ANY,		SRBDS),

can easily be simplified to:

  VULNBL_INTEL(IVYBRIDGE,	SRBDS),

Apply this to all the entries in the affected processor table.

No functional change.

Disassembly of cpu_vuln_blacklist:

  objdump -j .init.data --disassemble=cpu_vuln_blacklist vmlinux

doesn't show any difference before and after the change.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/kernel/cpu/common.c | 143 ++++++++++++++++++++++---------------------
 1 file changed, 73 insertions(+), 70 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 07a34d723505..66f691db5ec6 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1128,7 +1128,7 @@ static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
 	X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, whitelist)
 
 #define VULNWL_INTEL(vfm, whitelist)		\
-	X86_MATCH_VFM(vfm, whitelist)
+	X86_MATCH_VFM(INTEL_##vfm, whitelist)
 
 #define VULNWL_AMD(family, whitelist)		\
 	VULNWL(AMD, family, X86_MODEL_ANY, whitelist)
@@ -1145,32 +1145,32 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	VULNWL(VORTEX,	6, X86_MODEL_ANY,	NO_SPECULATION),
 
 	/* Intel Family 6 */
-	VULNWL_INTEL(INTEL_TIGERLAKE,		NO_MMIO),
-	VULNWL_INTEL(INTEL_TIGERLAKE_L,		NO_MMIO),
-	VULNWL_INTEL(INTEL_ALDERLAKE,		NO_MMIO),
-	VULNWL_INTEL(INTEL_ALDERLAKE_L,		NO_MMIO),
+	VULNWL_INTEL(TIGERLAKE,			NO_MMIO),
+	VULNWL_INTEL(TIGERLAKE_L,		NO_MMIO),
+	VULNWL_INTEL(ALDERLAKE,			NO_MMIO),
+	VULNWL_INTEL(ALDERLAKE_L,		NO_MMIO),
 
-	VULNWL_INTEL(INTEL_ATOM_SALTWELL,	NO_SPECULATION | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_SALTWELL_TABLET, NO_SPECULATION | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_SALTWELL_MID,	NO_SPECULATION | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_BONNELL,	NO_SPECULATION | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_BONNELL_MID,	NO_SPECULATION | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SALTWELL,		NO_SPECULATION | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SALTWELL_TABLET,	NO_SPECULATION | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SALTWELL_MID,		NO_SPECULATION | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_BONNELL,		NO_SPECULATION | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_BONNELL_MID,		NO_SPECULATION | NO_ITLB_MULTIHIT),
 
-	VULNWL_INTEL(INTEL_ATOM_SILVERMONT,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_SILVERMONT_D,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_AIRMONT,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_XEON_PHI_KNL,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_XEON_PHI_KNM,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SILVERMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SILVERMONT_D,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
 
-	VULNWL_INTEL(INTEL_CORE_YONAH,		NO_SSB),
+	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
 
-	VULNWL_INTEL(INTEL_ATOM_AIRMONT_MID,	NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | MSBDS_ONLY),
-	VULNWL_INTEL(INTEL_ATOM_AIRMONT_NP,	NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | MSBDS_ONLY),
+	VULNWL_INTEL(ATOM_AIRMONT_NP,		NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT),
 
-	VULNWL_INTEL(INTEL_ATOM_GOLDMONT,	NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
-	VULNWL_INTEL(INTEL_ATOM_GOLDMONT_D,	NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
-	VULNWL_INTEL(INTEL_ATOM_GOLDMONT_PLUS,	NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_EIBRS_PBRSB),
+	VULNWL_INTEL(ATOM_GOLDMONT,		NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
+	VULNWL_INTEL(ATOM_GOLDMONT_D,		NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
+	VULNWL_INTEL(ATOM_GOLDMONT_PLUS,	NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_EIBRS_PBRSB),
 
 	/*
 	 * Technically, swapgs isn't serializing on AMD (despite it previously
@@ -1180,9 +1180,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	 * good enough for our purposes.
 	 */
 
-	VULNWL_INTEL(INTEL_ATOM_TREMONT,	NO_EIBRS_PBRSB),
-	VULNWL_INTEL(INTEL_ATOM_TREMONT_L,	NO_EIBRS_PBRSB),
-	VULNWL_INTEL(INTEL_ATOM_TREMONT_D,	NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB),
+	VULNWL_INTEL(ATOM_TREMONT,	NO_EIBRS_PBRSB),
+	VULNWL_INTEL(ATOM_TREMONT_L,	NO_EIBRS_PBRSB),
+	VULNWL_INTEL(ATOM_TREMONT_D,	NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB),
 
 	/* AMD Family 0xf - 0x12 */
 	VULNWL_AMD(0x0f,	NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
@@ -1203,8 +1203,11 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 #define VULNBL(vendor, family, model, blacklist)	\
 	X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, blacklist)
 
-#define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues)		   \
-	X86_MATCH_VFM_STEPPINGS(vfm, steppings, issues)
+#define VULNBL_INTEL(vfm, issues)			\
+	X86_MATCH_VFM(INTEL_##vfm, issues)
+
+#define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues)	\
+	X86_MATCH_VFM_STEPPINGS(INTEL_##vfm, steppings, issues)
 
 #define VULNBL_AMD(family, blacklist)		\
 	VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
@@ -1229,49 +1232,49 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 #define RFDS		BIT(7)
 
 static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
-	VULNBL_INTEL_STEPPINGS(INTEL_IVYBRIDGE,		X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_HASWELL,		X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_HASWELL_L,		X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_HASWELL_G,		X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_HASWELL_X,		X86_STEPPING_ANY,		MMIO),
-	VULNBL_INTEL_STEPPINGS(INTEL_BROADWELL_D,	X86_STEPPING_ANY,		MMIO),
-	VULNBL_INTEL_STEPPINGS(INTEL_BROADWELL_G,	X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_BROADWELL_X,	X86_STEPPING_ANY,		MMIO),
-	VULNBL_INTEL_STEPPINGS(INTEL_BROADWELL,		X86_STEPPING_ANY,		SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_SKYLAKE_X,		X86_STEPPING_ANY,		MMIO | RETBLEED | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_SKYLAKE_L,		X86_STEPPING_ANY,		MMIO | RETBLEED | GDS | SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_SKYLAKE,		X86_STEPPING_ANY,		MMIO | RETBLEED | GDS | SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_KABYLAKE_L,	X86_STEPPING_ANY,		MMIO | RETBLEED | GDS | SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_KABYLAKE,		X86_STEPPING_ANY,		MMIO | RETBLEED | GDS | SRBDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_CANNONLAKE_L,	X86_STEPPING_ANY,		RETBLEED),
-	VULNBL_INTEL_STEPPINGS(INTEL_ICELAKE_L,		X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ICELAKE_D,		X86_STEPPING_ANY,		MMIO | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ICELAKE_X,		X86_STEPPING_ANY,		MMIO | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_COMETLAKE,		X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(INTEL_COMETLAKE_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_TIGERLAKE_L,	X86_STEPPING_ANY,		GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_TIGERLAKE,		X86_STEPPING_ANY,		GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_LAKEFIELD,		X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RETBLEED),
-	VULNBL_INTEL_STEPPINGS(INTEL_ROCKETLAKE,	X86_STEPPING_ANY,		MMIO | RETBLEED | GDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ALDERLAKE,		X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ALDERLAKE_L,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_RAPTORLAKE,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_RAPTORLAKE_P,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_RAPTORLAKE_S,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_GRACEMONT,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_TREMONT,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_TREMONT_D,	X86_STEPPING_ANY,		MMIO | RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_TREMONT_L,	X86_STEPPING_ANY,		MMIO | MMIO_SBDS | RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_GOLDMONT,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_GOLDMONT_D,	X86_STEPPING_ANY,		RFDS),
-	VULNBL_INTEL_STEPPINGS(INTEL_ATOM_GOLDMONT_PLUS, X86_STEPPING_ANY,		RFDS),
-
-	VULNBL_AMD(0x15, RETBLEED),
-	VULNBL_AMD(0x16, RETBLEED),
-	VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO),
-	VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO),
-	VULNBL_AMD(0x19, SRSO),
+	VULNBL_INTEL(		IVYBRIDGE,		SRBDS),
+	VULNBL_INTEL(		HASWELL,		SRBDS),
+	VULNBL_INTEL(		HASWELL_L,		SRBDS),
+	VULNBL_INTEL(		HASWELL_G,		SRBDS),
+	VULNBL_INTEL(		HASWELL_X,		MMIO),
+	VULNBL_INTEL(		BROADWELL_D,		MMIO),
+	VULNBL_INTEL(		BROADWELL_G,		SRBDS),
+	VULNBL_INTEL(		BROADWELL_X,		MMIO),
+	VULNBL_INTEL(		BROADWELL,		SRBDS),
+	VULNBL_INTEL(		SKYLAKE_X,		MMIO | RETBLEED | GDS),
+	VULNBL_INTEL(		SKYLAKE_L,		MMIO | RETBLEED | GDS | SRBDS),
+	VULNBL_INTEL(		SKYLAKE,		MMIO | RETBLEED | GDS | SRBDS),
+	VULNBL_INTEL(		KABYLAKE_L,		MMIO | RETBLEED | GDS | SRBDS),
+	VULNBL_INTEL(		KABYLAKE,		MMIO | RETBLEED | GDS | SRBDS),
+	VULNBL_INTEL(		CANNONLAKE_L,		RETBLEED),
+	VULNBL_INTEL(		ICELAKE_L,		MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL(		ICELAKE_D,		MMIO | GDS),
+	VULNBL_INTEL(		ICELAKE_X,		MMIO | GDS),
+	VULNBL_INTEL(		COMETLAKE,		MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL_STEPPINGS(	COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED),
+	VULNBL_INTEL(		COMETLAKE_L,		MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL(		TIGERLAKE_L,		GDS),
+	VULNBL_INTEL(		TIGERLAKE,		GDS),
+	VULNBL_INTEL(		LAKEFIELD,		MMIO | MMIO_SBDS | RETBLEED),
+	VULNBL_INTEL(		ROCKETLAKE,		MMIO | RETBLEED | GDS),
+	VULNBL_INTEL(		ALDERLAKE,		RFDS),
+	VULNBL_INTEL(		ALDERLAKE_L,		RFDS),
+	VULNBL_INTEL(		RAPTORLAKE,		RFDS),
+	VULNBL_INTEL(		RAPTORLAKE_P,		RFDS),
+	VULNBL_INTEL(		RAPTORLAKE_S,		RFDS),
+	VULNBL_INTEL(		ATOM_GRACEMONT,		RFDS),
+	VULNBL_INTEL(		ATOM_TREMONT,		MMIO | MMIO_SBDS | RFDS),
+	VULNBL_INTEL(		ATOM_TREMONT_D,		MMIO | RFDS),
+	VULNBL_INTEL(		ATOM_TREMONT_L,		MMIO | MMIO_SBDS | RFDS),
+	VULNBL_INTEL(		ATOM_GOLDMONT,		RFDS),
+	VULNBL_INTEL(		ATOM_GOLDMONT_D,	RFDS),
+	VULNBL_INTEL(		ATOM_GOLDMONT_PLUS,	RFDS),
+
+	VULNBL_AMD(		0x15,			RETBLEED),
+	VULNBL_AMD(		0x16,			RETBLEED),
+	VULNBL_AMD(		0x17,			RETBLEED | SMT_RSB | SRSO),
+	VULNBL_HYGON(		0x18,			RETBLEED | SMT_RSB | SRSO),
+	VULNBL_AMD(		0x19,			SRSO),
 	{}
 };
 

-- 
2.34.1

[PATCH v4 10/10] x86/rfds: Exclude P-only parts from the RFDS affected list

[Pawan Gupta]

RFDS only affects Atom parts. Vendor/Family/Model matching in the affected
processor table makes Alderlake and Raptorlake P-only parts affected (which
are not affected in reality). This is because the affected hybrid and
E-only parts have the same Family/Model as the unaffected P-only parts.

Match CPU-type as Atom to exclude P-only parts as RFDS affected.

Note, a guest with the same Family/Model as the affected part may not have
leaf 1A enumerated to know its CPU-type, but it should not be a problem as
guest's Family/Model can anyways be inaccurate. Moreover, RFDS_NO or
RFDS_CLEAR enumeration by the VMM decides the affected status of the guest.

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst | 8 --------
 arch/x86/kernel/cpu/common.c                                 | 9 +++++++--
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
index 0585d02b9a6c..ad15417d39f9 100644
--- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
@@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_:
    RAPTORLAKE_S            06_BFH
    ===================  ============
 
-As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and
-RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as
-vulnerable in Linux because they share the same family/model with an affected
-part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or
-CPUID.HYBRID. This information could be used to distinguish between the
-affected and unaffected parts, but it is deemed not worth adding complexity as
-the reporting is fixed automatically when these parts enumerate RFDS_NO.
-
 Mitigation
 ==========
 Intel released a microcode update that enables software to clear sensitive
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 66f691db5ec6..04695f74919e 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1209,6 +1209,11 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 #define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues)	\
 	X86_MATCH_VFM_STEPPINGS(INTEL_##vfm, steppings, issues)
 
+#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues)			\
+	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm,				\
+			       TOPO_HW_CPU_TYPE_INTEL_##cpu_type,	\
+			       issues)
+
 #define VULNBL_AMD(family, blacklist)		\
 	VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
 
@@ -1257,9 +1262,9 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
 	VULNBL_INTEL(		TIGERLAKE,		GDS),
 	VULNBL_INTEL(		LAKEFIELD,		MMIO | MMIO_SBDS | RETBLEED),
 	VULNBL_INTEL(		ROCKETLAKE,		MMIO | RETBLEED | GDS),
-	VULNBL_INTEL(		ALDERLAKE,		RFDS),
+	VULNBL_INTEL_TYPE(	ALDERLAKE,	ATOM,	RFDS),
 	VULNBL_INTEL(		ALDERLAKE_L,		RFDS),
-	VULNBL_INTEL(		RAPTORLAKE,		RFDS),
+	VULNBL_INTEL_TYPE(	RAPTORLAKE,	ATOM,	RFDS),
 	VULNBL_INTEL(		RAPTORLAKE_P,		RFDS),
 	VULNBL_INTEL(		RAPTORLAKE_S,		RFDS),
 	VULNBL_INTEL(		ATOM_GRACEMONT,		RFDS),

-- 
2.34.1

Re: [PATCH v4 00/10] Add CPU-type to topology

[Dave Hansen]

On 9/30/24 07:47, Pawan Gupta wrote:
> This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to
> differentiate between hybrid variants P+E, P-only, E-only that share the
> same Family/Model/Stepping. One of the use case for CPU-type is the
> affected CPU table for CPU vulnerabilities, which can now use the CPU-type
> to filter the unaffected variants.

The series looks fine to me now.  The diffstat is _almost_ even, despite
the series adding functionality.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Re: [PATCH v4 00/10] Add CPU-type to topology

[Pawan Gupta]

On Mon, Sep 30, 2024 at 08:12:57AM -0700, Dave Hansen wrote:
> On 9/30/24 07:47, Pawan Gupta wrote:
> > This series adds support for CPU-type (CPUID.1A.EAX[31-24] on Intel) to
> > differentiate between hybrid variants P+E, P-only, E-only that share the
> > same Family/Model/Stepping. One of the use case for CPU-type is the
> > affected CPU table for CPU vulnerabilities, which can now use the CPU-type
> > to filter the unaffected variants.
> 
> The series looks fine to me now.  The diffstat is _almost_ even, despite
> the series adding functionality.
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Thanks.