[PATCH 0/9] Add CPU-type to topology

[PATCH 0/9] Add CPU-type to topology

[Pawan Gupta]

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 adds cpu-type to CPU topology structure and introduces
  topology_cpu_type() to get the CPU-type.

* Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
  topology_cpu_type().

* Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.

* Patch 8 cleans up the affected CPU list.

* Patch 9 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 (9):
      x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology
      cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type
      perf/x86/intel: Use topology_cpu_type() to get 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                       |   2 +-
 arch/x86/include/asm/cpu.h                         |   6 -
 arch/x86/include/asm/cpu_device_id.h               | 117 +++++++-----------
 arch/x86/include/asm/processor.h                   |   3 +
 arch/x86/include/asm/topology.h                    |   9 ++
 arch/x86/kernel/cpu/common.c                       | 136 +++++++++++----------
 arch/x86/kernel/cpu/debugfs.c                      |   1 +
 arch/x86/kernel/cpu/intel.c                        |  16 ---
 arch/x86/kernel/cpu/match.c                        |  22 ++++
 arch/x86/kernel/cpu/topology_common.c              |   9 ++
 drivers/cpufreq/intel_pstate.c                     |  14 +--
 include/linux/mod_devicetable.h                    |   2 +
 13 files changed, 166 insertions(+), 179 deletions(-)
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240617-add-cpu-type-4d5e47efc117

Best regards,
-- 
Thanks,
Pawan

[PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Pawan Gupta]

Sometimes it is required to identify the type of a core for taking specific
actions e.g. intel_pstate driver uses the core type to determine CPU
scaling. Also, some CPU vulnerabilities only affect a specific CPU type
e.g. RFDS only affects Intel Atom. For hybrid systems that have variants
P+E, P-only(Core) and E-only(Atom), it gets challenging to identify which
variant is vulnerable to a specific vulnerability, as these variants share
the same family, model and stepping.

Such processors do have CPUID fields that uniquely identify them. Like,
P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE, while P+E
additionally enumerates CPUID.7.HYBRID. Linux does not currently use this
field.

Add a new field cpu_type to struct cpuinfo_topology which can be used to
match a CPU based on its type.

The cpu_type is populated in the below debugfs file:

  # cat /sys/kernel/debug/x86/topo/cpus/N

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

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index cb4f6c513c48..f310a7fb4e00 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -95,6 +95,9 @@ struct cpuinfo_topology {
 	// Core ID relative to the package
 	u32			core_id;
 
+	// CPU-type e.g. performance, efficiency etc.
+	u8			cpu_type;
+
 	// Logical ID mappings
 	u32			logical_pkg_id;
 	u32			logical_die_id;
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index abe3a8f22cbd..b28ad9422afb 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -41,6 +41,14 @@
 /* Mappings between logical cpu number and node number */
 DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map);
 
+#define X86_CPU_TYPE_INTEL_SHIFT	24
+
+enum x86_topo_cpu_type {
+	X86_CPU_TYPE_UNKNOWN		= 0,
+	X86_CPU_TYPE_INTEL_ATOM		= 0x20,
+	X86_CPU_TYPE_INTEL_CORE		= 0x40,
+};
+
 #ifdef CONFIG_DEBUG_PER_CPU_MAPS
 /*
  * override generic percpu implementation of cpu_to_node
@@ -139,6 +147,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu);
 #define topology_logical_die_id(cpu)		(cpu_data(cpu).topo.logical_die_id)
 #define topology_die_id(cpu)			(cpu_data(cpu).topo.die_id)
 #define topology_core_id(cpu)			(cpu_data(cpu).topo.core_id)
+#define topology_cpu_type(cpu)			(cpu_data(cpu).topo.cpu_type)
 #define topology_ppin(cpu)			(cpu_data(cpu).ppin)
 
 #define topology_amd_node_id(cpu)		(cpu_data(cpu).topo.amd_node_id)
diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c
index 3baf3e435834..b1c9bafe6c39 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, "cpu_type:            %x\n", c->topo.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/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
index 9a6069e7133c..be82c8769bb2 100644
--- a/arch/x86/kernel/cpu/topology_common.c
+++ b/arch/x86/kernel/cpu/topology_common.c
@@ -140,6 +140,14 @@ static void parse_topology(struct topo_scan *tscan, bool early)
 	}
 }
 
+static void topo_set_cpu_type(struct cpuinfo_x86 *c)
+{
+	c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
+
+	if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)
+		c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
+}
+
 static void topo_set_ids(struct topo_scan *tscan, bool early)
 {
 	struct cpuinfo_x86 *c = tscan->c;
@@ -190,6 +198,7 @@ void cpu_parse_topology(struct cpuinfo_x86 *c)
 	}
 
 	topo_set_ids(&tscan, false);
+	topo_set_cpu_type(c);
 }
 
 void __init cpu_init_topology(struct cpuinfo_x86 *c)

-- 
2.34.1

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Andrew Cooper]

On 17/06/2024 10:11 am, Pawan Gupta wrote:
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index cb4f6c513c48..f310a7fb4e00 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -95,6 +95,9 @@ struct cpuinfo_topology {
>  	// Core ID relative to the package
>  	u32			core_id;
>  
> +	// CPU-type e.g. performance, efficiency etc.
> +	u8			cpu_type;
> +

End of the structure?  At least that way new additions are less likely
to add more padding.

> diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
> index 9a6069e7133c..be82c8769bb2 100644
> --- a/arch/x86/kernel/cpu/topology_common.c
> +++ b/arch/x86/kernel/cpu/topology_common.c
> @@ -140,6 +140,14 @@ static void parse_topology(struct topo_scan *tscan, bool early)
>  	}
>  }
>  
> +static void topo_set_cpu_type(struct cpuinfo_x86 *c)
> +{
> +	c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
> +
> +	if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)

c->cpuid_level ?

~Andrew

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Pawan Gupta]

On Mon, Jun 17, 2024 at 10:35:15AM +0100, Andrew Cooper wrote:
> On 17/06/2024 10:11 am, Pawan Gupta wrote:
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index cb4f6c513c48..f310a7fb4e00 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -95,6 +95,9 @@ struct cpuinfo_topology {
> >  	// Core ID relative to the package
> >  	u32			core_id;
> >  
> > +	// CPU-type e.g. performance, efficiency etc.
> > +	u8			cpu_type;
> > +
> 
> End of the structure?  At least that way new additions are less likely
> to add more padding.

Right, I will move it to the end of the structure.

> > diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
> > index 9a6069e7133c..be82c8769bb2 100644
> > --- a/arch/x86/kernel/cpu/topology_common.c
> > +++ b/arch/x86/kernel/cpu/topology_common.c
> > @@ -140,6 +140,14 @@ static void parse_topology(struct topo_scan *tscan, bool early)
> >  	}
> >  }
> >  
> > +static void topo_set_cpu_type(struct cpuinfo_x86 *c)
> > +{
> > +	c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
> > +
> > +	if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)
> 
> c->cpuid_level ?

Will do.

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[kernel test robot]

Hi Pawan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]

url:    https://github.com/intel-lab-lkp/linux/commits/Pawan-Gupta/x86-cpu-topology-Add-x86_cpu_type-to-struct-cpuinfo_topology/20240617-172542
base:   83a7eefedc9b56fe7bfeff13b6c7356688ffa670
patch link:    https://lore.kernel.org/r/20240617-add-cpu-type-v1-1-b88998c01e76%40linux.intel.com
patch subject: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology
config: i386-buildonly-randconfig-004-20240617 (https://download.01.org/0day-ci/archive/20240617/202406172104.aOlpCnvb-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240617/202406172104.aOlpCnvb-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406172104.aOlpCnvb-lkp@intel.com/

All errors (new ones prefixed by >>):

>> arch/x86/kernel/cpu/topology_common.c:145:21: error: use of undeclared identifier 'X86_CPU_TYPE_UNKNOWN'
     145 |         c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
         |                            ^
>> arch/x86/kernel/cpu/topology_common.c:148:41: error: use of undeclared identifier 'X86_CPU_TYPE_INTEL_SHIFT'
     148 |                 c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
         |                                                       ^
   2 errors generated.


vim +/X86_CPU_TYPE_UNKNOWN +145 arch/x86/kernel/cpu/topology_common.c

   142	
   143	static void topo_set_cpu_type(struct cpuinfo_x86 *c)
   144	{
 > 145		c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
   146	
   147		if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)
 > 148			c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
   149	}
   150	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[kernel test robot]

Hi Pawan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]

url:    https://github.com/intel-lab-lkp/linux/commits/Pawan-Gupta/x86-cpu-topology-Add-x86_cpu_type-to-struct-cpuinfo_topology/20240617-172542
base:   83a7eefedc9b56fe7bfeff13b6c7356688ffa670
patch link:    https://lore.kernel.org/r/20240617-add-cpu-type-v1-1-b88998c01e76%40linux.intel.com
patch subject: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology
config: i386-buildonly-randconfig-003-20240617 (https://download.01.org/0day-ci/archive/20240617/202406172100.6R91rhbf-lkp@intel.com/config)
compiler: gcc-9 (Ubuntu 9.5.0-4ubuntu2) 9.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240617/202406172100.6R91rhbf-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406172100.6R91rhbf-lkp@intel.com/

All errors (new ones prefixed by >>):

   arch/x86/kernel/cpu/topology_common.c: In function 'topo_set_cpu_type':
>> arch/x86/kernel/cpu/topology_common.c:145:21: error: 'X86_CPU_TYPE_UNKNOWN' undeclared (first use in this function)
     145 |  c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
         |                     ^~~~~~~~~~~~~~~~~~~~
   arch/x86/kernel/cpu/topology_common.c:145:21: note: each undeclared identifier is reported only once for each function it appears in
>> arch/x86/kernel/cpu/topology_common.c:148:41: error: 'X86_CPU_TYPE_INTEL_SHIFT' undeclared (first use in this function)
     148 |   c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
         |                                         ^~~~~~~~~~~~~~~~~~~~~~~~


vim +/X86_CPU_TYPE_UNKNOWN +145 arch/x86/kernel/cpu/topology_common.c

   142	
   143	static void topo_set_cpu_type(struct cpuinfo_x86 *c)
   144	{
 > 145		c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
   146	
   147		if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)
 > 148			c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
   149	}
   150	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Borislav Petkov]

On Mon, Jun 17, 2024 at 02:11:26AM -0700, Pawan Gupta wrote:
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -95,6 +95,9 @@ struct cpuinfo_topology {
>  	// Core ID relative to the package
>  	u32			core_id;
>  
> +	// CPU-type e.g. performance, efficiency etc.
> +	u8			cpu_type;
> +
>  	// Logical ID mappings
>  	u32			logical_pkg_id;
>  	u32			logical_die_id;
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index abe3a8f22cbd..b28ad9422afb 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -41,6 +41,14 @@
>  /* Mappings between logical cpu number and node number */
>  DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map);
>  
> +#define X86_CPU_TYPE_INTEL_SHIFT	24
> +
> +enum x86_topo_cpu_type {
> +	X86_CPU_TYPE_UNKNOWN		= 0,
> +	X86_CPU_TYPE_INTEL_ATOM		= 0x20,
> +	X86_CPU_TYPE_INTEL_CORE		= 0x40,

Can we unify those core types and do our own (our == Linux) defines instead of
using Intels or AMDs?

There will be AMD variants too soon:

https://lore.kernel.org/r/7aad57a98b37fa5893d4fe602d3dcef5c3f755d5.1718606975.git.perry.yuan@amd.com

so can we have generic defines like

PERF_CORE
EFF_CORE
bla_CORE

and so on

?

And then map each vendor's types to the Linux types?

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Pawan Gupta]

On Tue, Jun 18, 2024 at 11:28:01PM +0200, Borislav Petkov wrote:
> On Mon, Jun 17, 2024 at 02:11:26AM -0700, Pawan Gupta wrote:
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -95,6 +95,9 @@ struct cpuinfo_topology {
> >  	// Core ID relative to the package
> >  	u32			core_id;
> >  
> > +	// CPU-type e.g. performance, efficiency etc.
> > +	u8			cpu_type;
> > +
> >  	// Logical ID mappings
> >  	u32			logical_pkg_id;
> >  	u32			logical_die_id;
> > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > index abe3a8f22cbd..b28ad9422afb 100644
> > --- a/arch/x86/include/asm/topology.h
> > +++ b/arch/x86/include/asm/topology.h
> > @@ -41,6 +41,14 @@
> >  /* Mappings between logical cpu number and node number */
> >  DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map);
> >  
> > +#define X86_CPU_TYPE_INTEL_SHIFT	24
> > +
> > +enum x86_topo_cpu_type {
> > +	X86_CPU_TYPE_UNKNOWN		= 0,
> > +	X86_CPU_TYPE_INTEL_ATOM		= 0x20,
> > +	X86_CPU_TYPE_INTEL_CORE		= 0x40,
> 
> Can we unify those core types and do our own (our == Linux) defines instead of
> using Intels or AMDs?

As Dave pointed out in the other email, atleast mitigations have a use case
to match the raw CPU type defined by the vendor. It could get tricky if
ever there will be different types of performance cores, with different
hardware characteristics.

> There will be AMD variants too soon:
> 
> https://lore.kernel.org/r/7aad57a98b37fa5893d4fe602d3dcef5c3f755d5.1718606975.git.perry.yuan@amd.com
> 
> so can we have generic defines like
> 
> PERF_CORE
> EFF_CORE
> bla_CORE
> 
> and so on
> 
> ?
> 
> And then map each vendor's types to the Linux types?

I am no expert, but I do think generic Linux types could also be useful in
future. Hypothetically speaking, these can be used to make better
scheduling decisions. For example, CPU bound processes can be scheduled
more on performance cores and I/O bound on efficiency cores.

To accommodate for that we can name the vendor specific types in this
series as vendor_cpu_type. And if we ever need to add generic types, we can
call them cpu_type?

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Borislav Petkov]

On Tue, Jun 18, 2024 at 08:31:26PM -0700, Pawan Gupta wrote:
> To accommodate for that we can name the vendor specific types in this
> series as vendor_cpu_type. And if we ever need to add generic types, we can
> call them cpu_type?

Yes, then that member you're adding should not just be called "cpu_type" but
either "vendor_cpu_type" or "hw_cpu_type" or whatnot and every vendor can then
put its own values there.

And for the future we could do functions which convert from a vendor CPU type
to a generic one. If we ever decide that we need the generic ones.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Pawan Gupta]

On Thu, Jun 20, 2024 at 05:51:11PM +0200, Borislav Petkov wrote:
> On Tue, Jun 18, 2024 at 08:31:26PM -0700, Pawan Gupta wrote:
> > To accommodate for that we can name the vendor specific types in this
> > series as vendor_cpu_type. And if we ever need to add generic types, we can
> > call them cpu_type?
> 
> Yes, then that member you're adding should not just be called "cpu_type" but
> either "vendor_cpu_type" or "hw_cpu_type" or whatnot and every vendor can then
> put its own values there.

I like hw_cpu_type better, as it leaves room for architecture defined
types as well.

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Mario Limonciello]

On 6/17/2024 04:11, Pawan Gupta wrote:
> Sometimes it is required to identify the type of a core for taking specific
> actions e.g. intel_pstate driver uses the core type to determine CPU
> scaling. Also, some CPU vulnerabilities only affect a specific CPU type
> e.g. RFDS only affects Intel Atom. For hybrid systems that have variants
> P+E, P-only(Core) and E-only(Atom), it gets challenging to identify which
> variant is vulnerable to a specific vulnerability, as these variants share
> the same family, model and stepping.
> 
> Such processors do have CPUID fields that uniquely identify them. Like,
> P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE, while P+E
> additionally enumerates CPUID.7.HYBRID. Linux does not currently use this
> field.
> 
> Add a new field cpu_type to struct cpuinfo_topology which can be used to
> match a CPU based on its type.
> 
> The cpu_type is populated in the below debugfs file:
> 
>    # cat /sys/kernel/debug/x86/topo/cpus/N
> 
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
>   arch/x86/include/asm/processor.h      | 3 +++
>   arch/x86/include/asm/topology.h       | 9 +++++++++
>   arch/x86/kernel/cpu/debugfs.c         | 1 +
>   arch/x86/kernel/cpu/topology_common.c | 9 +++++++++
>   4 files changed, 22 insertions(+)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index cb4f6c513c48..f310a7fb4e00 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -95,6 +95,9 @@ struct cpuinfo_topology {
>   	// Core ID relative to the package
>   	u32			core_id;
>   
> +	// CPU-type e.g. performance, efficiency etc.
> +	u8			cpu_type;
> +
>   	// Logical ID mappings
>   	u32			logical_pkg_id;
>   	u32			logical_die_id;
> diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> index abe3a8f22cbd..b28ad9422afb 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -41,6 +41,14 @@
>   /* Mappings between logical cpu number and node number */
>   DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map);
>   
> +#define X86_CPU_TYPE_INTEL_SHIFT	24
> +
> +enum x86_topo_cpu_type {
> +	X86_CPU_TYPE_UNKNOWN		= 0,
> +	X86_CPU_TYPE_INTEL_ATOM		= 0x20,
> +	X86_CPU_TYPE_INTEL_CORE		= 0x40,
> +};
> +

There is another patch series [1] in flight right now that is trying to 
get CPU types for AMD hetero designs as well.

I think the way you're doing it is a bit better though.

What do you think about having a common enum rather with words that are 
marketing strings?  We could have a monotonically increasing enum then 
too instead of a random bit mask.

Something like:

enum x86_topo_cpu_type {
	X86_CPU_TYPE_UNKNOWN		= 0,
	X86_CPU_TYPE_PERFORMANCE	= 1,
	X86_CPU_TYPE_EFFICIENCY		= 2,
};

Then as additional core types are added for any vendor those can be 
added here with a description of what they are.

The logic for topo_set_cpu_type() below can map out any bit mask and 
shift from a lookup path into this standard enum then.

If you do it this way we can lump the AMD hetero look up stuff into 
topo_set_cpu_type() as another case.

[1] 
https://lore.kernel.org/linux-pm/cover.1718606975.git.perry.yuan@amd.com/T/#mc65457f33331bba0d7d4fef1907d2fef14fc3fd8

>   #ifdef CONFIG_DEBUG_PER_CPU_MAPS
>   /*
>    * override generic percpu implementation of cpu_to_node
> @@ -139,6 +147,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu);
>   #define topology_logical_die_id(cpu)		(cpu_data(cpu).topo.logical_die_id)
>   #define topology_die_id(cpu)			(cpu_data(cpu).topo.die_id)
>   #define topology_core_id(cpu)			(cpu_data(cpu).topo.core_id)
> +#define topology_cpu_type(cpu)			(cpu_data(cpu).topo.cpu_type)
>   #define topology_ppin(cpu)			(cpu_data(cpu).ppin)
>   
>   #define topology_amd_node_id(cpu)		(cpu_data(cpu).topo.amd_node_id)
> diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c
> index 3baf3e435834..b1c9bafe6c39 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, "cpu_type:            %x\n", c->topo.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/topology_common.c b/arch/x86/kernel/cpu/topology_common.c
> index 9a6069e7133c..be82c8769bb2 100644
> --- a/arch/x86/kernel/cpu/topology_common.c
> +++ b/arch/x86/kernel/cpu/topology_common.c
> @@ -140,6 +140,14 @@ static void parse_topology(struct topo_scan *tscan, bool early)
>   	}
>   }
>   
> +static void topo_set_cpu_type(struct cpuinfo_x86 *c)
> +{
> +	c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN;
> +
> +	if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a)
> +		c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT;
> +}
> +
>   static void topo_set_ids(struct topo_scan *tscan, bool early)
>   {
>   	struct cpuinfo_x86 *c = tscan->c;
> @@ -190,6 +198,7 @@ void cpu_parse_topology(struct cpuinfo_x86 *c)
>   	}
>   
>   	topo_set_ids(&tscan, false);
> +	topo_set_cpu_type(c);
>   }
>   
>   void __init cpu_init_topology(struct cpuinfo_x86 *c)
> 

Re: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology

[Dave Hansen]

On 6/18/24 14:33, Mario Limonciello wrote:
>> +enum x86_topo_cpu_type {
>> +    X86_CPU_TYPE_UNKNOWN        = 0,
>> +    X86_CPU_TYPE_INTEL_ATOM        = 0x20,
>> +    X86_CPU_TYPE_INTEL_CORE        = 0x40,
>> +};
>> +
...
> What do you think about having a common enum rather with words that are
> marketing strings? 

They're not really marketing strings.  They really are architectural and
have specific functional meaning just like ->x86_model and ->x86_family.

For instance, we are effectively doing this today:

	if (c->cpu_x86_vfm == INTEL_ALDER_LAKE &&
	    c->cpu_type == X86_CPU_TYPE_INTEL_ATOM)
		setup_force_cpu_bug(FOO);

That check is truly specific to the core being an "ATOM" and not being
an efficient core.  There might be a future non-Atom efficient CPU or a
future non-Core performance CPU.

We very well might have a use in the future to tag a processor as
"efficient" or "performance" in a vendor-neutral manner.  That mechanism
could very well be derived from ->cpu_type.  But I think that's actually
independent from Pawan's series.

[PATCH PATCH 2/9] cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type

[Pawan Gupta]

Intel pstate driver uses hybrid_get_type() to get the cpu-type of a given
CPU. It uses smp_call_function_single() which is sub-optimal and can be
avoided as cpu-type is also available in the per-cpu topology structure.

Use topology_cpu_type() to get the cpu-type.

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 65d3f79104bd..40f5e5b0b45e 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1951,24 +1951,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_cpu_type(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 == X86_CPU_TYPE_INTEL_CORE)
 		return hybrid_scaling_factor;
 
 	/* Use default core scaling for E-cores */
-	if (cpu_type == 0x20)
+	if (cpu_type == X86_CPU_TYPE_INTEL_ATOM)
 		return core_get_scaling();
 
 	/*

-- 
2.34.1

Re: [PATCH PATCH 2/9] cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type

[srinivas pandruvada]

On Mon, 2024-06-17 at 02:11 -0700, Pawan Gupta wrote:
> Intel pstate driver uses hybrid_get_type() to get the cpu-type of a
> given
> CPU. It uses smp_call_function_single() which is sub-optimal and can
> be
> avoided as cpu-type is also available in the per-cpu topology
> structure.
> 
> Use topology_cpu_type() to get the cpu-type.
> 
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@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 65d3f79104bd..40f5e5b0b45e 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1951,24 +1951,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_cpu_type(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 == X86_CPU_TYPE_INTEL_CORE)
>  		return hybrid_scaling_factor;
>  
>  	/* Use default core scaling for E-cores */
> -	if (cpu_type == 0x20)
> +	if (cpu_type == X86_CPU_TYPE_INTEL_ATOM)
>  		return core_get_scaling();
>  
>  	/*
> 

Re: [PATCH PATCH 2/9] cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type

[Pawan Gupta]

On Mon, Jun 17, 2024 at 02:27:02AM -0700, srinivas pandruvada wrote:
> On Mon, 2024-06-17 at 02:11 -0700, Pawan Gupta wrote:
> > Intel pstate driver uses hybrid_get_type() to get the cpu-type of a
> > given
> > CPU. It uses smp_call_function_single() which is sub-optimal and can
> > be
> > avoided as cpu-type is also available in the per-cpu topology
> > structure.
> > 
> > Use topology_cpu_type() to get the cpu-type.
> > 
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Thanks.

Re: [PATCH PATCH 2/9] cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type

[kernel test robot]

Hi Pawan,

kernel test robot noticed the following build errors:

[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]

url:    https://github.com/intel-lab-lkp/linux/commits/Pawan-Gupta/x86-cpu-topology-Add-x86_cpu_type-to-struct-cpuinfo_topology/20240617-172542
base:   83a7eefedc9b56fe7bfeff13b6c7356688ffa670
patch link:    https://lore.kernel.org/r/20240617-add-cpu-type-v1-2-b88998c01e76%40linux.intel.com
patch subject: [PATCH PATCH 2/9] cpufreq: intel_pstate: Use topology_cpu_type() to get cpu-type
config: i386-buildonly-randconfig-001-20240617 (https://download.01.org/0day-ci/archive/20240617/202406172134.ICqkbkNm-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240617/202406172134.ICqkbkNm-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406172134.ICqkbkNm-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/cpufreq/intel_pstate.c: In function 'hwp_get_cpu_scaling':
>> drivers/cpufreq/intel_pstate.c:1959:25: error: 'X86_CPU_TYPE_INTEL_CORE' undeclared (first use in this function)
    1959 |         if (cpu_type == X86_CPU_TYPE_INTEL_CORE)
         |                         ^~~~~~~~~~~~~~~~~~~~~~~
   drivers/cpufreq/intel_pstate.c:1959:25: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/cpufreq/intel_pstate.c:1963:25: error: 'X86_CPU_TYPE_INTEL_ATOM' undeclared (first use in this function)
    1963 |         if (cpu_type == X86_CPU_TYPE_INTEL_ATOM)
         |                         ^~~~~~~~~~~~~~~~~~~~~~~


vim +/X86_CPU_TYPE_INTEL_CORE +1959 drivers/cpufreq/intel_pstate.c

  1953	
  1954	static int hwp_get_cpu_scaling(int cpu)
  1955	{
  1956		u8 cpu_type = topology_cpu_type(cpu);
  1957	
  1958		/* P-cores have a smaller perf level-to-freqency scaling factor. */
> 1959		if (cpu_type == X86_CPU_TYPE_INTEL_CORE)
  1960			return hybrid_scaling_factor;
  1961	
  1962		/* Use default core scaling for E-cores */
> 1963		if (cpu_type == X86_CPU_TYPE_INTEL_ATOM)
  1964			return core_get_scaling();
  1965	
  1966		/*
  1967		 * If reached here, this system is either non-hybrid (like Tiger
  1968		 * Lake) or hybrid-capable (like Alder Lake or Raptor Lake) with
  1969		 * no E cores (in which case CPUID for hybrid support is 0).
  1970		 *
  1971		 * The CPPC nominal_frequency field is 0 for non-hybrid systems,
  1972		 * so the default core scaling will be used for them.
  1973		 */
  1974		return intel_pstate_cppc_get_scaling(cpu);
  1975	}
  1976	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type

[Pawan Gupta]

find_hybrid_pmu_for_cpu() uses get_this_hybrid_cpu_type() to get the CPU
type, but it returns an invalid cpu-type when X86_FEATURE_HYBRID_CPU is not
set. Some hybrid variants do enumerate cpu-type regardless of
X86_FEATURE_HYBRID_CPU.

Replace get_this_hybrid_cpu_type() with topology_cpu_type() to get cpu-type
irrespective of hybrid status. Moreover, get_this_hybrid_cpu_type()
executes the CPUID instruction to get the cpu-type, which is slower than
using the per-cpu value.

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

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 38c1b1f1deaa..8067a735705a 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4753,7 +4753,7 @@ 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();
+	u8 cpu_type = topology_cpu_type(smp_processor_id());
 	int i;
 
 	/*

-- 
2.34.1

Re: [PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type

[Dave Hansen]

On 6/17/24 02:11, Pawan Gupta wrote:
> find_hybrid_pmu_for_cpu() uses get_this_hybrid_cpu_type() to get the CPU
> type, but it returns an invalid cpu-type when X86_FEATURE_HYBRID_CPU is not
> set. Some hybrid variants do enumerate cpu-type regardless of
> X86_FEATURE_HYBRID_CPU.

I'm not fully sure what point this is trying to make.

Is this trying to make the case that get_this_hybrid_cpu_type() and
topology_cpu_type() are equivalent or pointing out a difference?

Re: [PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:50:53AM -0700, Dave Hansen wrote:
> On 6/17/24 02:11, Pawan Gupta wrote:
> > find_hybrid_pmu_for_cpu() uses get_this_hybrid_cpu_type() to get the CPU
> > type, but it returns an invalid cpu-type when X86_FEATURE_HYBRID_CPU is not
> > set. Some hybrid variants do enumerate cpu-type regardless of
> > X86_FEATURE_HYBRID_CPU.
> 
> I'm not fully sure what point this is trying to make.

Sorry it was not clear. I will rephrase it.

> Is this trying to make the case that get_this_hybrid_cpu_type() and
> topology_cpu_type() are equivalent or pointing out a difference?

Pointing out a difference. get_this_hybrid_cpu_type() misses a case when
cpu-type is enumerated regardless of X86_FEATURE_HYBRID_CPU. I don't think
checking for the hybrid feature is necessary here, because there is an
existing fixup for this case:

  static struct x86_hybrid_pmu *find_hybrid_pmu_for_cpu(void)
  {
          u8 cpu_type = topology_cpu_type(smp_processor_id());
          int i;

          /*
           * This is running on a CPU model that is known to have hybrid
           * configurations. But the CPU told us it is not hybrid, shame
           * on it. There should be a fixup function provided for these
           * troublesome CPUs (->get_hybrid_cpu_type).
           */
          if (cpu_type == HYBRID_INTEL_NONE) {
                  if (x86_pmu.get_hybrid_cpu_type)
                          cpu_type = x86_pmu.get_hybrid_cpu_type();
                  else
                          return NULL;
          }

Re: [PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type

[Dave Hansen]

On 6/17/24 11:09, Pawan Gupta wrote:
>> Is this trying to make the case that get_this_hybrid_cpu_type() and
>> topology_cpu_type() are equivalent or pointing out a difference?
> Pointing out a difference. get_this_hybrid_cpu_type() misses a case when
> cpu-type is enumerated regardless of X86_FEATURE_HYBRID_CPU. I don't think
> checking for the hybrid feature is necessary here, because there is an
> existing fixup for this case:

OK, that makes sense.  Could you include that in the changelog, please?

Re: [PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type

[Pawan Gupta]

On Mon, Jun 17, 2024 at 11:17:35AM -0700, Dave Hansen wrote:
> On 6/17/24 11:09, Pawan Gupta wrote:
> >> Is this trying to make the case that get_this_hybrid_cpu_type() and
> >> topology_cpu_type() are equivalent or pointing out a difference?
> > Pointing out a difference. get_this_hybrid_cpu_type() misses a case when
> > cpu-type is enumerated regardless of X86_FEATURE_HYBRID_CPU. I don't think
> > checking for the hybrid feature is necessary here, because there is an
> > existing fixup for this case:
> 
> OK, that makes sense.  Could you include that in the changelog, please?

Sure.

[PATCH PATCH 4/9] x86/cpu: Remove get_this_hybrid_cpu_type()

[Pawan Gupta]

get_this_hybrid_cpu_type() is replaced by topology_cpu_type(). There are no
more users left, remove it.

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 aa30fd8cad7f..20e491c22b98 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);
 #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)
@@ -45,11 +44,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;
-}
 #endif
 #ifdef CONFIG_IA32_FEAT_CTL
 void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fdf3489d92a4..ac6c68a39051 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -1335,19 +1335,3 @@ void __init sld_setup(struct cpuinfo_x86 *c)
 	sld_state_setup();
 	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;
-}

-- 
2.34.1

[PATCH PATCH 5/9] 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 | 104 +++++++++++------------------------
 1 file changed, 31 insertions(+), 73 deletions(-)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index b6325ee30871..6c8f4cf03cae 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_INTEL_FAM6_MODEL - Match vendor INTEL, family 6 and model
@@ -209,8 +182,8 @@
 	X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, INTEL_FAM6_##model, data)
 
 #define X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(model, steppings, data)	\
-	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
-						     steppings, X86_FEATURE_ANY, data)
+	X86_MATCH_CPU(X86_VENDOR_INTEL, 6, INTEL_FAM6_##model,		\
+		      steppings, X86_FEATURE_ANY, data)
 
 /**
  * X86_MATCH_VFM - Match encoded vendor/family/model
@@ -218,15 +191,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
@@ -235,15 +203,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
@@ -252,15 +215,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 PATCH 6/9] 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 cpu-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 | 35 ++++++++++++++++++++++++-----------
 include/linux/mod_devicetable.h      |  2 ++
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index 6c8f4cf03cae..08c2efa6dfdf 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_INTEL_FAM6_MODEL - Match vendor INTEL, family 6 and model
@@ -183,7 +184,7 @@
 
 #define X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(model, steppings, data)	\
 	X86_MATCH_CPU(X86_VENDOR_INTEL, 6, INTEL_FAM6_##model,		\
-		      steppings, X86_FEATURE_ANY, data)
+		      steppings, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
 
 /**
  * X86_MATCH_VFM - Match encoded vendor/family/model
@@ -194,7 +195,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
@@ -206,7 +207,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
@@ -218,7 +219,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 PATCH 7/9] 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..ca15e74596d7 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_cpu - helper function to match the 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_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 c->topo.cpu_type == m->cpu_type;
+}
+
 /**
  * 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_cpu_type(c, m))
+			continue;
 		return m;
 	}
 	return NULL;

-- 
2.34.1

[PATCH PATCH 8/9] 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.

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

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index d4e539d4e158..7e3b09b0f82c 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_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
-	VULNWL_INTEL(INTEL_ATOM_AIRMONT_NP,	NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_AIRMONT_MID,		NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+	VULNWL_INTEL(ATOM_AIRMONT_NP,		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,43 +1232,45 @@ 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_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(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),
+
+	/* Match more than Vendor/Family/Model */
+	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
+	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
 
 	VULNBL_AMD(0x15, RETBLEED),
 	VULNBL_AMD(0x16, RETBLEED),

-- 
2.34.1

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Andrew Cooper]

On 17/06/2024 10:12 am, Pawan Gupta wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index d4e539d4e158..7e3b09b0f82c 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1229,43 +1232,45 @@ 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_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(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),

Take the opportunity to realign and fix this ?

~Andrew

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Pawan Gupta]

On Mon, Jun 17, 2024 at 10:38:32AM +0100, Andrew Cooper wrote:
[...]
> > +	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(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),
> 
> Take the opportunity to realign and fix this ?

I assume by also adding a tab to all the other entries?

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Dave Hansen]

On 6/17/24 02:12, Pawan Gupta wrote:
> No functional change.

It would make me feel a *lot* better if you also dumped the before and
after binaries and made sure they're identical.

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:13:15AM -0700, Dave Hansen wrote:
> On 6/17/24 02:12, Pawan Gupta wrote:
> > No functional change.
> 
> It would make me feel a *lot* better if you also dumped the before and
> after binaries and made sure they're identical.

Right, will do.

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:13:15AM -0700, Dave Hansen wrote:
> On 6/17/24 02:12, Pawan Gupta wrote:
> > No functional change.
> 
> It would make me feel a *lot* better if you also dumped the before and
> after binaries and made sure they're identical.

Verified that they are identical. Adding this dump to the changelog:

$ size vmlinux.before vmlinux.after
text		data		bss		dec		hex	filename
33128289        23039446        19767300        75935035        486ad3b vmlinux.before
33128289        23039446        19767300        75935035        486ad3b vmlinux.after

RE: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Luck, Tony]

> $ size vmlinux.before vmlinux.after
> text		data		bss		dec		hex	filename
> 33128289        23039446        19767300        75935035        486ad3b vmlinux.before
> 33128289        23039446        19767300        75935035        486ad3b vmlinux.after

Same size != same contents.

What if you:

$ cmp -l arch/x86/kernel/cpu/before-common.o arch/x86/kernel/cpu/after-common.o

Or

$ diff <(objdump -d arch/x86/kernel/cpu/before-common.o) <(objdump -d arch/x86/kernel/cpu/after-common.o)

-Tony

Re: [PATCH PATCH 8/9] x86/bugs: Declutter vulnerable CPU list

[Pawan Gupta]

On Tue, Jun 18, 2024 at 12:08:18AM +0000, Luck, Tony wrote:
> > $ size vmlinux.before vmlinux.after
> > text		data		bss		dec		hex	filename
> > 33128289        23039446        19767300        75935035        486ad3b vmlinux.before
> > 33128289        23039446        19767300        75935035        486ad3b vmlinux.after
> 
> Same size != same contents.

Right. I did get that thought, but did not act on it :\

> What if you:
> 
> $ cmp -l arch/x86/kernel/cpu/before-common.o arch/x86/kernel/cpu/after-common.o
> 
> Or
> 
> $ diff <(objdump -d arch/x86/kernel/cpu/before-common.o) <(objdump -d arch/x86/kernel/cpu/after-common.o)

Thanks for pointers. I am not seeing any difference in the disassembly too.

[PATCH PATCH 9/9] 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                                 | 7 +++++--
 2 files changed, 5 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 7e3b09b0f82c..73ec66321758 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1209,6 +1209,9 @@ 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_CPU_TYPE(vfm, cpu_type, issues)	\
+	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
+
 #define VULNBL_AMD(family, blacklist)		\
 	VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
 
@@ -1255,9 +1258,7 @@ 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(ALDERLAKE_L,	RFDS),
-	VULNBL_INTEL(RAPTORLAKE,	RFDS),
 	VULNBL_INTEL(RAPTORLAKE_P,	RFDS),
 	VULNBL_INTEL(RAPTORLAKE_S,	RFDS),
 	VULNBL_INTEL(ATOM_GRACEMONT,	RFDS),
@@ -1271,6 +1272,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
 	/* Match more than Vendor/Family/Model */
 	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
 	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
+	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
+	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
 
 	VULNBL_AMD(0x15, RETBLEED),
 	VULNBL_AMD(0x16, RETBLEED),

-- 
2.34.1

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

[Andrew Cooper]

On 17/06/2024 10:12 am, Pawan Gupta wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 7e3b09b0f82c..73ec66321758 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1209,6 +1209,9 @@ 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_CPU_TYPE(vfm, cpu_type, issues)	\
> +	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
> +
>  #define VULNBL_AMD(family, blacklist)		\
>  	VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
>  
> @@ -1255,9 +1258,7 @@ 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(ALDERLAKE_L,	RFDS),
> -	VULNBL_INTEL(RAPTORLAKE,	RFDS),
>  	VULNBL_INTEL(RAPTORLAKE_P,	RFDS),
>  	VULNBL_INTEL(RAPTORLAKE_S,	RFDS),
>  	VULNBL_INTEL(ATOM_GRACEMONT,	RFDS),
> @@ -1271,6 +1272,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
>  	/* Match more than Vendor/Family/Model */
>  	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
>  	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
> +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),

How does this work?

Being __initconst, this is only evaluated on the BSP.

P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if
there are ATOM APs to bring up later.

~Andrew

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

[Dave Hansen]

On 6/17/24 02:43, Andrew Cooper wrote:
> On 17/06/2024 10:12 am, Pawan Gupta wrote:
>> +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
>> +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> 
> How does this work?
> 
> Being __initconst, this is only evaluated on the BSP.
> 
> P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if
> there are ATOM APs to bring up later.

The X86_CPU_TYPE_* is only used on the boot CPU on non-hybrids.  Hybrids
(independent of the boot CPU type) should be considered vulnerable no
matter what.

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

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:34:22AM -0700, Dave Hansen wrote:
> On 6/17/24 02:43, Andrew Cooper wrote:
> > On 17/06/2024 10:12 am, Pawan Gupta wrote:
> >> +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> >> +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> > 
> > How does this work?
> > 
> > Being __initconst, this is only evaluated on the BSP.
> > 
> > P-only and mixed P/E systems won't see X86_CPU_TYPE_INTEL_ATOM, even if
> > there are ATOM APs to bring up later.
> 
> The X86_CPU_TYPE_* is only used on the boot CPU on non-hybrids.  Hybrids
> (independent of the boot CPU type) should be considered vulnerable no
> matter what.

Yes. This is done in x86_match_cpu_type(), that matches all cpu-types on hybrids:

  static bool x86_match_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id)
  {
     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 c->topo.cpu_type == m->cpu_type;
  }

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

[Dave Hansen]

On 6/17/24 02:12, Pawan Gupta wrote:
> +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues)	\
> +	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
> +
...
>  	/* Match more than Vendor/Family/Model */
>  	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
>  	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
> +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),

Could we tweak this a bit to make it more compact?  For instance, if we
did this:

#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues)	\
		X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm,	\
		X86_CPU_TYPE_INTEL_##cpu_type,		\	
		issues)

We'd end up with entries like this:

	VULNBL_INTEL_TYPE (ALDERLAKE,	ATOM,	RFDS),

I guess "TYPE" is a _bit_ ambiguous.  But it's also pretty patently
obvious what's going on versus something like this:

	VULNBL_INTEL	  (COMETLAKE_L,	MMIO | MMIO_SBDS | RETBLEED...),

Getting rid of the "X86_CPU_TYPE_INTEL_" string in the table is low
hanging fruit.  I don't feel as strongly about changing the new macro name.

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

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:33:13AM -0700, Dave Hansen wrote:
> On 6/17/24 02:12, Pawan Gupta wrote:
> > +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues)	\
> > +	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
> > +
> ...
> >  	/* Match more than Vendor/Family/Model */
> >  	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
> >  	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
> > +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> > +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> 
> Could we tweak this a bit to make it more compact?  For instance, if we
> did this:
> 
> #define VULNBL_INTEL_TYPE(vfm, cpu_type, issues)	\
> 		X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm,	\
> 		X86_CPU_TYPE_INTEL_##cpu_type,		\	
> 		issues)
> 
> We'd end up with entries like this:
> 
> 	VULNBL_INTEL_TYPE (ALDERLAKE,	ATOM,	RFDS),
> 
> I guess "TYPE" is a _bit_ ambiguous.  But it's also pretty patently
> obvious what's going on versus something like this:
> 
> 	VULNBL_INTEL	  (COMETLAKE_L,	MMIO | MMIO_SBDS | RETBLEED...),
> 
> Getting rid of the "X86_CPU_TYPE_INTEL_" string in the table is low
> hanging fruit.  I don't feel as strongly about changing the new macro name.

It makes sense to me, atleast getting rid of X86_CPU_TYPE_INTEL_ in
X86_CPU_TYPE_INTEL_ATOM.

Re: [PATCH 0/9] Add CPU-type to topology

[Brice Goglin]

Le 17/06/2024 à 11:11, Pawan Gupta a écrit :
> 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 adds cpu-type to CPU topology structure and introduces
>    topology_cpu_type() to get the CPU-type.
>
> * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
>    topology_cpu_type().
>
> * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.
>
> * Patch 8 cleans up the affected CPU list.
>
> * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected
>    list.


Hello

Is there still a plan to expose this info in sysfs? Userspace currently 
uses frequencies to guess which cores are E or P. Intel sent some 
patches several years ago [1], but they got abandoned nowhere as far as 
I know. There was also some discussion about using a "capacity" field 
like ARM does, but IIRC Intel didn't like the idea in the end.

Thanks

Brice

[1] https://lkml.org/lkml/2020/10/2/1208

Re: [PATCH 0/9] Add CPU-type to topology

[Pawan Gupta]

On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote:
> Le 17/06/2024 à 11:11, Pawan Gupta a écrit :
> > 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 adds cpu-type to CPU topology structure and introduces
> >    topology_cpu_type() to get the CPU-type.
> > 
> > * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
> >    topology_cpu_type().
> > 
> > * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.
> > 
> > * Patch 8 cleans up the affected CPU list.
> > 
> > * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected
> >    list.
> 
> 
> Hello
> 
> Is there still a plan to expose this info in sysfs?

Sure, if it helps userspace.

> Userspace currently uses frequencies to guess which cores are E or P.
> Intel sent some patches several years ago [1], but they got abandoned
> nowhere as far as I know. There was also some discussion about using a
> "capacity" field like ARM does, but IIRC Intel didn't like the idea in
> the end.

There can be many ways to expose this information in sysfs. Like this ...

> [1] https://lkml.org/lkml/2020/10/2/1208

... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a
subdirectory for each type of CPU. Each subdirectory contains a CPU list
and a CPU map that user space can query.

The other way is to expose the CPU-type in a file:

	/sys/devices/system/cpu/cpuN/type

that could return the CPU-type of the CPU N. Is there a preference?

Re: [PATCH 0/9] Add CPU-type to topology

[srinivas pandruvada]

On Tue, 2024-06-18 at 18:53 -0700, Pawan Gupta wrote:
> On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote:
> > Le 17/06/2024 à 11:11, Pawan Gupta a écrit :
> > > 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 adds cpu-type to CPU topology structure and introduces
> > >    topology_cpu_type() to get the CPU-type.
> > > 
> > > * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
> > >    topology_cpu_type().
> > > 
> > > * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.
> > > 
> > > * Patch 8 cleans up the affected CPU list.
> > > 
> > > * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS
> > > affected
> > >    list.
> > 
> > 
> > Hello
> > 
> > Is there still a plan to expose this info in sysfs?
> 
> Sure, if it helps userspace.
> 
> > Userspace currently uses frequencies to guess which cores are E or
> > P.
> > Intel sent some patches several years ago [1], but they got
> > abandoned
> > nowhere as far as I know. There was also some discussion about
> > using a
> > "capacity" field like ARM does, but IIRC Intel didn't like the idea
> > in
> > the end.
> 
> There can be many ways to expose this information in sysfs. Like this
> ...
> 
> > [1] https://lkml.org/lkml/2020/10/2/1208
> 
> ... exposes /sys/devices/system/cpu/types which, in hybrid parts,
> creates a
> subdirectory for each type of CPU. Each subdirectory contains a CPU
> list
> and a CPU map that user space can query.
> 
> The other way is to expose the CPU-type in a file:
> 
>         /sys/devices/system/cpu/cpuN/type
> 
> that could return the CPU-type of the CPU N. Is there a preference?

But you still have to look at frequency or caches as there are Low
power E-cores which will have same type but different capabilities.

Thanks,
Srinivas

Re: [PATCH 0/9] Add CPU-type to topology

[Brice Goglin]

Le 19/06/2024 à 12:34, srinivas pandruvada a écrit :
> On Tue, 2024-06-18 at 18:53 -0700, Pawan Gupta wrote:
>> On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote:
>>> Le 17/06/2024 à 11:11, Pawan Gupta a écrit :
>>>> 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 adds cpu-type to CPU topology structure and introduces
>>>>     topology_cpu_type() to get the CPU-type.
>>>>
>>>> * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
>>>>     topology_cpu_type().
>>>>
>>>> * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.
>>>>
>>>> * Patch 8 cleans up the affected CPU list.
>>>>
>>>> * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS
>>>> affected
>>>>     list.
>>>
>>> Hello
>>>
>>> Is there still a plan to expose this info in sysfs?
>> Sure, if it helps userspace.
>>
>>> Userspace currently uses frequencies to guess which cores are E or
>>> P.
>>> Intel sent some patches several years ago [1], but they got
>>> abandoned
>>> nowhere as far as I know. There was also some discussion about
>>> using a
>>> "capacity" field like ARM does, but IIRC Intel didn't like the idea
>>> in
>>> the end.
>> There can be many ways to expose this information in sysfs. Like this
>> ...
>>
>>> [1] https://lkml.org/lkml/2020/10/2/1208
>> ... exposes /sys/devices/system/cpu/types which, in hybrid parts,
>> creates a
>> subdirectory for each type of CPU. Each subdirectory contains a CPU
>> list
>> and a CPU map that user space can query.
>>
>> The other way is to expose the CPU-type in a file:
>>
>>          /sys/devices/system/cpu/cpuN/type
>>
>> that could return the CPU-type of the CPU N. Is there a preference?
> But you still have to look at frequency or caches as there are Low
> power E-cores which will have same type but different capabilities.


Good point. From this patch series, I understand that the current kernel 
side doesn't care about these different E-cores. However it might be 
good to expose them as different cpu-types (or better name) to userspace ?

Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?

Brice

Re: [PATCH 0/9] Add CPU-type to topology

[Dave Hansen]

On 6/19/24 14:25, Brice Goglin wrote:
> Good point. From this patch series, I understand that the current kernel
> side doesn't care about these different E-cores. However it might be
> good to expose them as different cpu-types (or better name) to userspace ?
> 
> Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?

The first priority here is getting the kernel to comprehend these types
for architectural purposes: when there are functional differences
between the cores.

Let's get that in place, first.  Then we can discuss the possibility of
new ABI in the area.

Did the ARM folks ever do a sysfs ABI for big.LITTLE?  I don't see
anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu.

Re: [PATCH 0/9] Add CPU-type to topology

[Brice Goglin]

Le 20/06/2024 à 17:06, Dave Hansen a écrit :

> On 6/19/24 14:25, Brice Goglin wrote:
>> Good point. From this patch series, I understand that the current kernel
>> side doesn't care about these different E-cores. However it might be
>> good to expose them as different cpu-types (or better name) to userspace ?
>>
>> Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?
> The first priority here is getting the kernel to comprehend these types
> for architectural purposes: when there are functional differences
> between the cores.
>
> Let's get that in place, first.  Then we can discuss the possibility of
> new ABI in the area.

Agreed.

> Did the ARM folks ever do a sysfs ABI for big.LITTLE?  I don't see
> anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu.

As far as I know, they only have the "capacity" field in sysfs cpu files
that reports a higher number for the equivalent of P-core:

 From testing/sysfs-devices-system-cpu:

What:           /sys/devices/system/cpu/cpuX/cpu_capacity
Date:           December 2016
Contact:        Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description:    information about CPUs heterogeneity.

                 cpu_capacity: capacity of cpuX.

I don't know how it's calculated but I've never seen it report something wrong.
On Android/ARM phones, big cores usually have 1024 and small cores something
between 400 and 500.
Where there are 3 types of cores, they report 1024, 500-800 about ~250.

Brice

Re: [PATCH 0/9] Add CPU-type to topology

[Pawan Gupta]

On Thu, Jun 20, 2024 at 05:22:59PM +0200, Brice Goglin wrote:
> Le 20/06/2024 à 17:06, Dave Hansen a écrit :
> 
> > On 6/19/24 14:25, Brice Goglin wrote:
> > > Good point. From this patch series, I understand that the current kernel
> > > side doesn't care about these different E-cores. However it might be
> > > good to expose them as different cpu-types (or better name) to userspace ?
> > > 
> > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?
> > The first priority here is getting the kernel to comprehend these types
> > for architectural purposes: when there are functional differences
> > between the cores.
> > 
> > Let's get that in place, first.  Then we can discuss the possibility of
> > new ABI in the area.
> 
> Agreed.

Sorry replying late, I was on vacation. Yes, let's leave the ABI for
another series when we have a clear use case.

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Thu, Jun 20, 2024 at 05:22:59PM +0200, Brice Goglin wrote:
> Le 20/06/2024 à 17:06, Dave Hansen a écrit :
> 
> > On 6/19/24 14:25, Brice Goglin wrote:
> > > Good point. From this patch series, I understand that the current kernel
> > > side doesn't care about these different E-cores. However it might be
> > > good to expose them as different cpu-types (or better name) to userspace ?
> > > 
> > > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?
> > The first priority here is getting the kernel to comprehend these types
> > for architectural purposes: when there are functional differences
> > between the cores.
> > 
> > Let's get that in place, first.  Then we can discuss the possibility of
> > new ABI in the area.
> 
> Agreed.
> 
> > Did the ARM folks ever do a sysfs ABI for big.LITTLE?  I don't see
> > anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu.
> 
> As far as I know, they only have the "capacity" field in sysfs cpu files
> that reports a higher number for the equivalent of P-core:
> 
> From testing/sysfs-devices-system-cpu:
> 
> What:           /sys/devices/system/cpu/cpuX/cpu_capacity
> Date:           December 2016
> Contact:        Linux kernel mailing list <linux-kernel@vger.kernel.org>
> Description:    information about CPUs heterogeneity.
> 
>                 cpu_capacity: capacity of cpuX.
> 
> I don't know how it's calculated but I've never seen it report something wrong.
> On Android/ARM phones, big cores usually have 1024 and small cores something
> between 400 and 500.
> Where there are 3 types of cores, they report 1024, 500-800 about ~250.

I *think* this information comes from firmware tables, but you cannot reliably
infer CPU types from capacity (e.g., Intel's Ecores vs Low Power Ecores).

Also, it is not useful to identify "performance" vs "efficient" CPUs.

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Thu, Jun 20, 2024 at 08:06:11AM -0700, Dave Hansen wrote:
> On 6/19/24 14:25, Brice Goglin wrote:
> > Good point. From this patch series, I understand that the current kernel
> > side doesn't care about these different E-cores. However it might be
> > good to expose them as different cpu-types (or better name) to userspace ?
> > 
> > Something like type 0 = P-core, 1 = normal E-core, 2 = low power E-core ?
> 
> The first priority here is getting the kernel to comprehend these types
> for architectural purposes: when there are functional differences
> between the cores.
> 
> Let's get that in place, first.  Then we can discuss the possibility of
> new ABI in the area.
> 
> Did the ARM folks ever do a sysfs ABI for big.LITTLE?  I don't see
> anything obvious in Documentation/ABI/testing/sysfs-devices-system-cpu.
> 

ARM has the interface /sys/devices/system/cpu/cpu0/regs/identification

Here they show the Main ID Register [A]. This register has CPU
identification fields such as architecture and other details. The
architecture can be specified as a number or refer to architecture-specific
features in other registers.

On my DragonBoard 845c, this interface shows different values for different
types of CPUs.

For functionality, there is also a /sys/devices/system/cpu/aarch32_el0. It
lists the CPUs that can 32-bit ARM programs on processors in which only a
subset of CPUs can do it.

ARM gives userspace specific details. This makes more sense to me. Instead
of reading these details, user space would have to infer these details if
a CPU type was given in sysfs.

Having said that, Intel does have a CPUID leaf that gives the CPU type. Such
leaf also has a "Native Model ID". Exposing only the CPU type may not be
sufficient.

[A]. https://developer.arm.com/documentation/ddi0595/2020-12/AArch64-Registers/MIDR-EL1--Main-ID-Register

Re: [PATCH 0/9] Add CPU-type to topology

[Pawan Gupta]

On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote:
> ARM gives userspace specific details. This makes more sense to me. Instead
> of reading these details, user space would have to infer these details if
> a CPU type was given in sysfs.
> 
> Having said that, Intel does have a CPUID leaf that gives the CPU type. Such
> leaf also has a "Native Model ID". Exposing only the CPU type may not be
> sufficient.

Do we know if there are applications that would benefit from this information?

We agreed to leave sysfs for another series. I will be sending v2 soon.

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Thu, Jun 27, 2024 at 06:22:30AM -0700, Pawan Gupta wrote:
> On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote:
> > ARM gives userspace specific details. This makes more sense to me. Instead
> > of reading these details, user space would have to infer these details if
> > a CPU type was given in sysfs.
> > 
> > Having said that, Intel does have a CPUID leaf that gives the CPU type. Such
> > leaf also has a "Native Model ID". Exposing only the CPU type may not be
> > sufficient.
> 
> Do we know if there are applications that would benefit from this information?

Probably not, but exposing it would follow ARM's approach of exposing the
raw details and let user space consume it as it wishes instead of having
kernel give an answer that could probably be imcomplete.

> 
> We agreed to leave sysfs for another series. I will be sending v2 soon.

It is fine, just wanted to express some opinions. :)

Re: [PATCH 0/9] Add CPU-type to topology

[Liang, Kan]

On 2024-06-27 9:22 a.m., Pawan Gupta wrote:
> On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote:
>> ARM gives userspace specific details. This makes more sense to me. Instead
>> of reading these details, user space would have to infer these details if
>> a CPU type was given in sysfs.
>>
>> Having said that, Intel does have a CPUID leaf that gives the CPU type. Such
>> leaf also has a "Native Model ID". Exposing only the CPU type may not be
>> sufficient.
> 
> Do we know if there are applications that would benefit from this information?
> 

Perf should needs it in the kernel to distinguish between different type
of e-cores on ARL-H.

+Dapeng, who is working on ARL-H PMU enabling.

Thanks,
Kan

Re: [PATCH 0/9] Add CPU-type to topology

[Brice Goglin]

Le 27/06/2024 à 15:22, Pawan Gupta a écrit :
> On Thu, Jun 27, 2024 at 05:51:54AM -0700, Ricardo Neri wrote:
>> ARM gives userspace specific details. This makes more sense to me. Instead
>> of reading these details, user space would have to infer these details if
>> a CPU type was given in sysfs.
>>
>> Having said that, Intel does have a CPUID leaf that gives the CPU type. Such
>> leaf also has a "Native Model ID". Exposing only the CPU type may not be
>> sufficient.
> Do we know if there are applications that would benefit from this information?


There are HPC users who want a homogeneous set of cores, ie only P-core, 
or only E-core without the low power ones (because they don't want some 
imbalance between task speed in homogeneous parallel jobs). I've 
received requests from hwloc users running small parallel jobs on their 
desktop/laptop machines, and also from developers of big apps who want 
to debug on their laptop without heterogeneous cores creating imbalance 
that don't exist on servers.

They don't care much about the actual hardware details so far, they 
mostly want an ordered list of set of homogeneous cores (ordered from 
performance -> low-energy).

Brice

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Wed, Jun 19, 2024 at 03:34:46AM -0700, srinivas pandruvada wrote:

[...]

> > 
> > There can be many ways to expose this information in sysfs. Like this
> > ...
> > 
> > > [1] https://lkml.org/lkml/2020/10/2/1208
> > 
> > ... exposes /sys/devices/system/cpu/types which, in hybrid parts,
> > creates a
> > subdirectory for each type of CPU. Each subdirectory contains a CPU
> > list
> > and a CPU map that user space can query.
> > 
> > The other way is to expose the CPU-type in a file:
> > 
> >         /sys/devices/system/cpu/cpuN/type
> > 
> > that could return the CPU-type of the CPU N. Is there a preference?
> 
> But you still have to look at frequency or caches as there are Low
> power E-cores which will have same type but different capabilities.

By the way, /sys/devices/system/cpuN/cache is broken on these systems with
low power Ecores. I proposed a patch to fix it here [B]. May I ask for a few
extra reviews and testing? Perhaps this will raise the confidence of the
x86 maintainers? :)

The patchset continues to apply cleanly on v6.10-rc5.

[B]. https://lore.kernel.org/all/20231212222519.12834-5-ricardo.neri-calderon@linux.intel.com/

Re: [PATCH 0/9] Add CPU-type to topology

[Brice Goglin]

Le 19/06/2024 à 03:53, Pawan Gupta a écrit :
> On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote:
>> Le 17/06/2024 à 11:11, Pawan Gupta a écrit :
>>> 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 adds cpu-type to CPU topology structure and introduces
>>>     topology_cpu_type() to get the CPU-type.
>>>
>>> * Patch 2-4 replaces usages of get_this_hybrid_cpu_type() with
>>>     topology_cpu_type().
>>>
>>> * Patch 5-7 Updates CPU-matching infrastructure to use CPU-type.
>>>
>>> * Patch 8 cleans up the affected CPU list.
>>>
>>> * Patch 9 uses the CPU-type to exclude P-only parts from the RFDS affected
>>>     list.
>>
>> Hello
>>
>> Is there still a plan to expose this info in sysfs?
> Sure, if it helps userspace.
>
>> Userspace currently uses frequencies to guess which cores are E or P.
>> Intel sent some patches several years ago [1], but they got abandoned
>> nowhere as far as I know. There was also some discussion about using a
>> "capacity" field like ARM does, but IIRC Intel didn't like the idea in
>> the end.
> There can be many ways to expose this information in sysfs. Like this ...
>
>> [1] https://lkml.org/lkml/2020/10/2/1208
> ... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a
> subdirectory for each type of CPU. Each subdirectory contains a CPU list
> and a CPU map that user space can query.
>
> The other way is to expose the CPU-type in a file:
>
> 	/sys/devices/system/cpu/cpuN/type
>
> that could return the CPU-type of the CPU N. Is there a preference?


I'd vote for the former.

Brice

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Wed, Jun 19, 2024 at 11:22:16PM +0200, Brice Goglin wrote:

[...]

> > There can be many ways to expose this information in sysfs. Like this ...
> > 
> > > [1] https://lkml.org/lkml/2020/10/2/1208
> > ... exposes /sys/devices/system/cpu/types which, in hybrid parts, creates a
> > subdirectory for each type of CPU. Each subdirectory contains a CPU list
> > and a CPU map that user space can query.
> > 
> > The other way is to expose the CPU-type in a file:
> > 
> > 	/sys/devices/system/cpu/cpuN/type
> > 
> > that could return the CPU-type of the CPU N. Is there a preference?
> 
> 
> I'd vote for the former.

+1. With the former you can read all CPUs of a given type in one go whereas
with the latter you have to iterate over all CPUs. By the time you are done
CPUs may have gone offline or online.

Re: [PATCH 0/9] Add CPU-type to topology

[Ricardo Neri]

On Tue, Jun 18, 2024 at 02:49:10PM +0200, Brice Goglin wrote:
> Le 17/06/2024 à 11:11, Pawan Gupta a écrit :

[...]
 
> Hello
> 
> Is there still a plan to expose this info in sysfs? Userspace currently uses
> frequencies to guess which cores are E or P. Intel sent some patches several
> years ago [1], but they got abandoned nowhere as far as I know.

At the time of writing those patches an alternative interface emerged from
perf sysfs. You can read the CPUs of a given type from
/sys/devices/cpu_{core,atom}/cpus .

Yes, this is perf sysfs, but is not obvious from the name and has a list of
CPUs. It meet the need, IMO.