[PATCH 00/74] New Intel CPUID families

[PATCH 00/74] New Intel CPUID families

[Tony Luck]

Q1: Where are all the other parts of this series. I only got 1-3.
A1: There are ~2700 subscribers to LKML. I want to get some feedback
on the approach and naming etc. before spamming everyone with a 74
patch series.

Q2: Can I get the other parts?
A2: Sure. I posted them to patches@lists.linux.dev so you can get them
with:
$ b4 am 20240328090459.242500-tony.luck@intel.com
or get from kernel.org with:
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git new_families

Q3: When are CPUs using new families coming?
A3: Soon-ish. We have some time to get the infrastructure right.

Intel has been using family 6 almost exclusively for many
years. As a result, Linux has built up infrastructure like
X86_MATCH_INTEL_FAM6_MODEL() to make it easy for model specific code to
use the #defines for each Intel CPU model.

But the reign of family 6 is about to end. Intel will begin using non-zero
values for the extended family field in CPUID(1).EAX. The minimal patch
size approach to handle these would be to clone the FAM6 macros. But
that will get messy as these prolifrate. This approach does not have an
elegant solution if a switch() statement needs to choose between CPUs
from different families.

Dave Hansen suggested that a more general cleanup that provides
CPU #defines that encode all of <vendor, family, model> would make
existing code better, and provide infrastructure that makes it trivial
to incorporate new families.

Big picture view is that code like this:

  if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)

can become:

  if (c->x86_vfm == INTEL_ICELAKE_X)

which is:
a)	Simpler
b)	Faster
c)	More resilient (can't forget to check vendor & family along with model)
d)	Code style doesn't change for every new family.

Note that "struct cpuinfo_x86" gains a new xf6_vfm field and the ICELAKE
#define loses the "FAM6_" substring and will be initialized with a macro
that does the bit shuffling to fit X86_VENDOR_INTEL and a family and
model into a "u32":

#define INTEL_ICELAKE_X                 IFM(6, 0x6A) /* Sunny Cove */

New CPUs in other families might look like:

#define INTEL_DOUGLASCOVE		IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT		IFM(73, 0x01) /* Cooper Forest */

Model specific "if" statements then follow the same pattern
regardless of family:

  if (c->x86_vfm == INTEL_DOUGLASCOVE || c->x86_vfm == INTEL_SHELDONMONT) {
  }

If needed these could even appear in the same switch statement:

	switch (c->x86_vfm) {
	case INTEL_ICELAKE_X:
		...
	case INTEL_DOUGLASCOVE:
		...
	case INTEL_SHELDONMONT:
		...
	}

The existing X86_MATCH_INTEL_FAM6_MODEL() can be replaced with a new
X86_MATCH_VFM() macro.

Update can happen in three phases:

1) Add infrastructure macros, new "x86_vfm" field, new CPU #defines

2) Treewide update from old to new (around 70 files at current count)

3) Delete the old INTEL_FAM6 and X86_MATCH_INTEL_FAM6 macros

Tony Luck (74):
  x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
  x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
  x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
  x86/cpu/vfm: Update arch/x86/crypto/poly1305_glue.c
  x86/cpu/vfm: Update arch/x86/crypto/twofish_glue_3way.c
  x86/cpu/vfm: Update arch/x86/events/intel/cstate.c
  x86/cpu/vfm: Update arch/x86/events/intel/lbr.c
  x86/cpu/vfm: Update arch/x86/events/intel/pt.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore_nhmex.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore_snbep.c
  x86/cpu/vfm: Update arch/x86/events/msr.c
  x86/cpu/vfm: Update arch/x86/events/rapl.c
  x86/cpu/vfm: Update arch/x86/kernel/apic/apic.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/aperfmperf.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/bugs.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/common.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/intel_epb.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/match.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/core.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/severity.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/microcode/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/core.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/pseudo_lock.c
  x86/cpu/vfm: Update arch/x86/kernel/smpboot.c
  x86/cpu/vfm: Update arch/x86/kernel/tsc.c
  x86/cpu/vfm: Update arch/x86/kernel/tsc_msr.c
  x86/cpu/vfm: Update arch/x86/kvm/pmu.c
  x86/cpu/vfm: Update arch/x86/kvm/vmx/vmx.c
  x86/cpu/vfm: Update arch/x86/mm/init.c
  x86/cpu/vfm: Update arch/x86/pci/intel_mid_pci.c
  x86/cpu/vfm: Update arch/x86/virt/vmx/tdx/tdx.c
  x86/cpu/vfm: Update drivers/acpi/acpi_lpss.c
  x86/cpu/vfm: Update drivers/acpi/x86/utils.c
  x86/cpu/vfm: Update tpm files
  x86/cpu/vfm: Update drivers/cpufreq/intel_pstate.c
  x86/cpu/vfm: Update drivers/cpufreq/speedstep-centrino.c
  x86/cpu/vfm: Update drivers/edac/i10nm_base.c
  x86/cpu/vfm: Update drivers/edac/pnd2_edac.c
  x86/cpu/vfm: Update drivers/edac/sb_edac.c
  x86/cpu/vfm: Update drivers/edac/skx_base.c
  x86/cpu/vfm: Update drivers/extcon/extcon-axp288.c
  x86/cpu/vfm: Update drivers/hwmon/peci/cputemp.c
  x86/cpu/vfm: Update drivers/idle/intel_idle.c
  x86/cpu/vfm: Update drivers/pci/pci-mid.c
  x86/cpu/vfm: Update drivers/peci/cpu.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/ifs/core.c
  x86/cpu/vfm: Update drivers/platform/x86/intel_ips.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/core.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/pltdrv.c
  x86/cpu/vfm: Update drivers/platform/x86/intel_scu_wdt.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/speed_select_if/isst_if_common.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/debugfs.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/pltdrv.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/turbo_max_3.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
  x86/cpu/vfm: Update drivers/platform/x86/p2sb.c
  x86/cpu/vfm: Update drivers/powercap/intel_rapl_common.c
  x86/cpu/vfm: Update drivers/powercap/intel_rapl_msr.c
  x86/cpu/vfm: Update
    drivers/staging/media/atomisp/include/linux/atomisp_platform.h
  x86/cpu/vfm: Update intel_soc_dts_thermal.c
  x86/cpu/vfm: Update drivers/thermal/intel/intel_tcc_cooling.c
  x86/cpu/vfm: Update sound/soc/intel/avs/boards/es8336.c
  x86/cpu/vfm: Update arch/x86/events/intel/core.c
  x86/cpu/vfm: Update arch/x86/platform/intel-mid/intel-mid.c
  x86/cpu/vfm: Update arch/x86/platform/atom/punit_atom_debug.c
  x86/cpu/vfm: Update arch/x86/events/intel/core.c
  x86/cpu/vfm: Update tools/power/x86/turbostat/turbostat.c
  x86/cpu/vfm: Update arch/x86/boot/cpucheck.c
  x86/cpu/vfm: Delete X86_MATCH_INTEL_FAM6_MODEL[_STEPPING]() macros
  x86/cpu/vfm: Delete all the *_FAM6_ CPU #defines

 .../atomisp/include/linux/atomisp_platform.h  |  26 +--
 include/linux/peci-cpu.h                      |   1 +
 include/linux/platform_data/x86/soc.h         |  12 +-
 arch/x86/include/asm/cpu_device_id.h          | 103 +++++++--
 arch/x86/include/asm/intel-family.h           | 167 +++++++-------
 arch/x86/include/asm/processor.h              |  12 +-
 drivers/char/tpm/tpm.h                        |   1 +
 drivers/char/tpm/tpm_tis_core.h               |   2 +-
 arch/x86/boot/cpucheck.c                      |   2 +-
 arch/x86/crypto/poly1305_glue.c               |   3 +-
 arch/x86/crypto/twofish_glue_3way.c           |  10 +-
 arch/x86/events/intel/core.c                  | 212 +++++++++---------
 arch/x86/events/intel/cstate.c                | 144 ++++++------
 arch/x86/events/intel/lbr.c                   |   3 +-
 arch/x86/events/intel/pt.c                    |  11 +-
 arch/x86/events/intel/uncore.c                | 100 ++++-----
 arch/x86/events/intel/uncore_nhmex.c          |   3 +-
 arch/x86/events/intel/uncore_snbep.c          |   5 +-
 arch/x86/events/msr.c                         | 131 +++++------
 arch/x86/events/rapl.c                        |  84 +++----
 arch/x86/kernel/apic/apic.c                   |  38 ++--
 arch/x86/kernel/cpu/aperfmperf.c              |  17 +-
 arch/x86/kernel/cpu/bugs.c                    |  29 +--
 arch/x86/kernel/cpu/common.c                  | 154 +++++++------
 arch/x86/kernel/cpu/intel.c                   | 115 +++++-----
 arch/x86/kernel/cpu/intel_epb.c               |  12 +-
 arch/x86/kernel/cpu/match.c                   |   5 +-
 arch/x86/kernel/cpu/mce/core.c                |   5 +-
 arch/x86/kernel/cpu/mce/intel.c               |  20 +-
 arch/x86/kernel/cpu/mce/severity.c            |   9 +-
 arch/x86/kernel/cpu/microcode/intel.c         |   4 +-
 arch/x86/kernel/cpu/resctrl/core.c            |   9 +-
 arch/x86/kernel/cpu/resctrl/pseudo_lock.c     |  21 +-
 arch/x86/kernel/smpboot.c                     |   6 +-
 arch/x86/kernel/tsc.c                         |   5 +-
 arch/x86/kernel/tsc_msr.c                     |  14 +-
 arch/x86/kvm/pmu.c                            |   8 +-
 arch/x86/kvm/vmx/vmx.c                        |  20 +-
 arch/x86/mm/init.c                            |  16 +-
 arch/x86/pci/intel_mid_pci.c                  |   4 +-
 arch/x86/platform/atom/punit_atom_debug.c     |  11 +-
 arch/x86/platform/intel-mid/intel-mid.c       |   7 +-
 arch/x86/virt/vmx/tdx/tdx.c                   |   7 +-
 drivers/acpi/acpi_lpss.c                      |   4 +-
 drivers/acpi/x86/utils.c                      |  42 ++--
 drivers/cpufreq/intel_pstate.c                |  90 ++++----
 drivers/cpufreq/speedstep-centrino.c          |   8 +-
 drivers/edac/i10nm_base.c                     |  20 +-
 drivers/edac/pnd2_edac.c                      |   4 +-
 drivers/edac/sb_edac.c                        |  14 +-
 drivers/edac/skx_base.c                       |   2 +-
 drivers/extcon/extcon-axp288.c                |   2 +-
 drivers/hwmon/peci/cputemp.c                  |   7 +-
 drivers/idle/intel_idle.c                     | 116 +++++-----
 drivers/pci/pci-mid.c                         |   4 +-
 drivers/peci/cpu.c                            |  28 +--
 drivers/platform/x86/intel/ifs/core.c         |  15 +-
 drivers/platform/x86/intel/pmc/core.c         |  46 ++--
 drivers/platform/x86/intel/pmc/pltdrv.c       |  16 +-
 .../intel/speed_select_if/isst_if_common.c    |   4 +-
 .../intel/speed_select_if/isst_if_mbox_msr.c  |   2 +-
 .../platform/x86/intel/telemetry/debugfs.c    |   4 +-
 drivers/platform/x86/intel/telemetry/pltdrv.c |   4 +-
 drivers/platform/x86/intel/turbo_max_3.c      |   4 +-
 .../intel/uncore-frequency/uncore-frequency.c |  56 ++---
 drivers/platform/x86/intel_ips.c              |   3 +-
 drivers/platform/x86/intel_scu_wdt.c          |   2 +-
 drivers/platform/x86/p2sb.c                   |   2 +-
 drivers/powercap/intel_rapl_common.c          | 118 +++++-----
 drivers/powercap/intel_rapl_msr.c             |  16 +-
 drivers/thermal/intel/intel_soc_dts_thermal.c |   2 +-
 drivers/thermal/intel/intel_tcc_cooling.c     |  30 +--
 sound/soc/intel/avs/boards/es8336.c           |   7 +-
 tools/power/x86/turbostat/turbostat.c         | 161 +++++++------
 74 files changed, 1258 insertions(+), 1143 deletions(-)


base-commit: 4cece764965020c22cff7665b18a012006359095
-- 
2.44.0

[PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Tony Luck]

Refactor struct cpuinfo_x86 so that the vendor, family, and model
fields are overlayed in a union with a 32-bit field that combines
all three (together with a one byte reserved field in the upper
byte).

This will make it easy, cheap, and reliable to check all three
values at once.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/processor.h | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 811548f131f4..87115e5d884f 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -108,9 +108,15 @@ struct cpuinfo_topology {
 };
 
 struct cpuinfo_x86 {
-	__u8			x86;		/* CPU family */
-	__u8			x86_vendor;	/* CPU vendor */
-	__u8			x86_model;
+	union {
+		struct {
+			__u8	x86_vendor;	/* CPU vendor */
+			__u8	x86;		/* CPU family */
+			__u8	x86_model;
+			__u8	x86_reserved;
+		};
+		__u32		x86_vfm;	/* combined vendor, family, model */
+	};
 	__u8			x86_stepping;
 #ifdef CONFIG_X86_64
 	/* Number of 4K pages in DTLB/ITLB combined(in pages): */
-- 
2.44.0

[PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values

[Tony Luck]

To avoid adding a slew of new macros for each new Intel CPU family
switch over from providing CPU model number #defines to a new
scheme that encodes vendor, family, and model in a single number.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/cpu_device_id.h | 93 ++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index eb8fcede9e3b..0e98d3fd0d38 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -2,6 +2,39 @@
 #ifndef _ASM_X86_CPU_DEVICE_ID
 #define _ASM_X86_CPU_DEVICE_ID
 
+/*
+ * Can't use <linux/bitfield.h> because it generates expressions that
+ * cannot be used in structure initializers. Bitfield construction
+ * here must match the union in struct cpuinfo_86:
+ *	union {
+ *		struct {
+ *			__u8	x86_vendor;
+ *			__u8	x86;
+ *			__u8	x86_model;
+ *			__u8	x86_reserved;
+ *		};
+ *		__u32		x86_vfm;
+ *	};
+ */
+#define VFM_VENDOR_BIT	0
+#define VFM_FAMILY_BIT	8
+#define VFM_MODEL_BIT	16
+#define VFM_RSVD_BIT	24
+
+#define	VFM_VENDOR_MASK	GENMASK(VFM_FAMILY_BIT - 1, VFM_VENDOR_BIT)
+#define	VFM_FAMILY_MASK	GENMASK(VFM_MODEL_BIT - 1, VFM_FAMILY_BIT)
+#define	VFM_MODEL_MASK	GENMASK(VFM_RSVD_BIT - 1, VFM_MODEL_BIT)
+
+#define VFM_VENDOR(vfm)	(((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
+#define VFM_FAMILY(vfm)	(((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
+#define VFM_MODEL(vfm)	(((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
+
+#define	VFM_MAKE(_vendor, _family, _model) (	\
+	((_vendor) << VFM_VENDOR_BIT) |		\
+	((_family) << VFM_FAMILY_BIT) |		\
+	((_model) << VFM_MODEL_BIT)		\
+)
+
 /*
  * Declare drivers belonging to specific x86 CPUs
  * Similar in spirit to pci_device_id and related PCI functions
@@ -49,6 +82,16 @@
 	.driver_data	= (unsigned long) _data				\
 }
 
+#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
+						    _steppings, _feature, _data) { \
+	.vendor		= _vendor,					\
+	.family		= _family,					\
+	.model		= _model,					\
+	.steppings	= _steppings,					\
+	.feature	= _feature,					\
+	.driver_data	= (unsigned long) _data				\
+}
+
 /**
  * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Macro for CPU matching
  * @_vendor:	The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
@@ -164,6 +207,56 @@
 	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
 						     steppings, X86_FEATURE_ANY, data)
 
+/**
+ * X86_MATCH_VFM - Match encoded vendor/family/model
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
+/**
+ * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @steppings:	Bitmask of steppings to match
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
+/**
+ * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @feature:	A X86_FEATURE bit
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
 /*
  * Match specific microcode revisions.
  *
-- 
2.44.0

[PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h

[Tony Luck]

New CPU #defines encode vendor and family as well as model.

Update the example usage comment in arch/x86/kernel/cpu/match.c

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/intel-family.h | 84 +++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/match.c         |  3 +-
 2 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index d0941f4c2724..f81a851c46dc 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -40,137 +40,221 @@
  * their own names :-(
  */
 
+#define IFM(_fam, _model)	VFM_MAKE(X86_VENDOR_INTEL, _fam, _model)
+
 /* Wildcard match for FAM6 so X86_MATCH_INTEL_FAM6_MODEL(ANY) works */
 #define INTEL_FAM6_ANY			X86_MODEL_ANY
+/* Wildcard match for FAM6 so X86_MATCH_VFM(ANY) works */
+#define INTEL_ANY			IFM(X86_FAMILY_ANY, X86_MODEL_ANY)
 
 #define INTEL_FAM6_CORE_YONAH		0x0E
+#define INTEL_CORE_YONAH		IFM(6, 0x0E)
 
 #define INTEL_FAM6_CORE2_MEROM		0x0F
+#define INTEL_CORE2_MEROM		IFM(6, 0x0F)
 #define INTEL_FAM6_CORE2_MEROM_L	0x16
+#define INTEL_CORE2_MEROM_L		IFM(6, 0x16)
 #define INTEL_FAM6_CORE2_PENRYN		0x17
+#define INTEL_CORE2_PENRYN		IFM(6, 0x17)
 #define INTEL_FAM6_CORE2_DUNNINGTON	0x1D
+#define INTEL_CORE2_DUNNINGTON		IFM(6, 0x1D)
 
 #define INTEL_FAM6_NEHALEM		0x1E
+#define INTEL_NEHALEM			IFM(6, 0x1E)
 #define INTEL_FAM6_NEHALEM_G		0x1F /* Auburndale / Havendale */
+#define INTEL_NEHALEM_G			IFM(6, 0x1F) /* Auburndale / Havendale */
 #define INTEL_FAM6_NEHALEM_EP		0x1A
+#define INTEL_NEHALEM_EP		IFM(6, 0x1A)
 #define INTEL_FAM6_NEHALEM_EX		0x2E
+#define INTEL_NEHALEM_EX		IFM(6, 0x2E)
 
 #define INTEL_FAM6_WESTMERE		0x25
+#define INTEL_WESTMERE			IFM(6, 0x25)
 #define INTEL_FAM6_WESTMERE_EP		0x2C
+#define INTEL_WESTMERE_EP		IFM(6, 0x2C)
 #define INTEL_FAM6_WESTMERE_EX		0x2F
+#define INTEL_WESTMERE_EX		IFM(6, 0x2F)
 
 #define INTEL_FAM6_SANDYBRIDGE		0x2A
+#define INTEL_SANDYBRIDGE		IFM(6, 0x2A)
 #define INTEL_FAM6_SANDYBRIDGE_X	0x2D
+#define INTEL_SANDYBRIDGE_X		IFM(6, 0x2D)
 #define INTEL_FAM6_IVYBRIDGE		0x3A
+#define INTEL_IVYBRIDGE			IFM(6, 0x3A)
 #define INTEL_FAM6_IVYBRIDGE_X		0x3E
+#define INTEL_IVYBRIDGE_X		IFM(6, 0x3E)
 
 #define INTEL_FAM6_HASWELL		0x3C
+#define INTEL_HASWELL			IFM(6, 0x3C)
 #define INTEL_FAM6_HASWELL_X		0x3F
+#define INTEL_HASWELL_X			IFM(6, 0x3F)
 #define INTEL_FAM6_HASWELL_L		0x45
+#define INTEL_HASWELL_L			IFM(6, 0x45)
 #define INTEL_FAM6_HASWELL_G		0x46
+#define INTEL_HASWELL_G			IFM(6, 0x46)
 
 #define INTEL_FAM6_BROADWELL		0x3D
+#define INTEL_BROADWELL			IFM(6, 0x3D)
 #define INTEL_FAM6_BROADWELL_G		0x47
+#define INTEL_BROADWELL_G		IFM(6, 0x47)
 #define INTEL_FAM6_BROADWELL_X		0x4F
+#define INTEL_BROADWELL_X		IFM(6, 0x4F)
 #define INTEL_FAM6_BROADWELL_D		0x56
+#define INTEL_BROADWELL_D		IFM(6, 0x56)
 
 #define INTEL_FAM6_SKYLAKE_L		0x4E	/* Sky Lake             */
+#define INTEL_SKYLAKE_L			IFM(6, 0x4E) /* Sky Lake */
 #define INTEL_FAM6_SKYLAKE		0x5E	/* Sky Lake             */
+#define INTEL_SKYLAKE			IFM(6, 0x5E) /* Sky Lake */
 #define INTEL_FAM6_SKYLAKE_X		0x55	/* Sky Lake             */
+#define INTEL_SKYLAKE_X			IFM(6, 0x55) /* Sky Lake */
 /*                 CASCADELAKE_X	0x55	   Sky Lake -- s: 7     */
 /*                 COOPERLAKE_X		0x55	   Sky Lake -- s: 11    */
 
 #define INTEL_FAM6_KABYLAKE_L		0x8E	/* Sky Lake             */
+#define INTEL_KABYLAKE_L		IFM(6, 0x8E) /* Sky Lake */
 /*                 AMBERLAKE_L		0x8E	   Sky Lake -- s: 9     */
 /*                 COFFEELAKE_L		0x8E	   Sky Lake -- s: 10    */
 /*                 WHISKEYLAKE_L	0x8E       Sky Lake -- s: 11,12 */
 
 #define INTEL_FAM6_KABYLAKE		0x9E	/* Sky Lake             */
+#define INTEL_KABYLAKE			IFM(6, 0x9E) /* Sky Lake */
 /*                 COFFEELAKE		0x9E	   Sky Lake -- s: 10-13 */
 
 #define INTEL_FAM6_COMETLAKE		0xA5	/* Sky Lake             */
+#define INTEL_COMETLAKE			IFM(6, 0xA5) /* Sky Lake */
 #define INTEL_FAM6_COMETLAKE_L		0xA6	/* Sky Lake             */
+#define INTEL_COMETLAKE_L		IFM(6, 0xA6) /* Sky Lake */
 
 #define INTEL_FAM6_CANNONLAKE_L		0x66	/* Palm Cove */
+#define INTEL_CANNONLAKE_L		IFM(6, 0x66) /* Palm Cove */
 
 #define INTEL_FAM6_ICELAKE_X		0x6A	/* Sunny Cove */
+#define INTEL_ICELAKE_X			IFM(6, 0x6A) /* Sunny Cove */
 #define INTEL_FAM6_ICELAKE_D		0x6C	/* Sunny Cove */
+#define INTEL_ICELAKE_D			IFM(6, 0x6C) /* Sunny Cove */
 #define INTEL_FAM6_ICELAKE		0x7D	/* Sunny Cove */
+#define INTEL_ICELAKE			IFM(6, 0x7D) /* Sunny Cove */
 #define INTEL_FAM6_ICELAKE_L		0x7E	/* Sunny Cove */
+#define INTEL_ICELAKE_L			IFM(6, 0x7E) /* Sunny Cove */
 #define INTEL_FAM6_ICELAKE_NNPI		0x9D	/* Sunny Cove */
+#define INTEL_ICELAKE_NNPI		IFM(6, 0x9D) /* Sunny Cove */
 
 #define INTEL_FAM6_ROCKETLAKE		0xA7	/* Cypress Cove */
+#define INTEL_ROCKETLAKE		IFM(6, 0xA7) /* Cypress Cove */
 
 #define INTEL_FAM6_TIGERLAKE_L		0x8C	/* Willow Cove */
+#define INTEL_TIGERLAKE_L		IFM(6, 0x8C) /* Willow Cove */
 #define INTEL_FAM6_TIGERLAKE		0x8D	/* Willow Cove */
+#define INTEL_TIGERLAKE			IFM(6, 0x8D) /* Willow Cove */
 
 #define INTEL_FAM6_SAPPHIRERAPIDS_X	0x8F	/* Golden Cove */
+#define INTEL_SAPPHIRERAPIDS_X		IFM(6, 0x8F) /* Golden Cove */
 
 #define INTEL_FAM6_EMERALDRAPIDS_X	0xCF
+#define INTEL_EMERALDRAPIDS_X		IFM(6, 0xCF)
 
 #define INTEL_FAM6_GRANITERAPIDS_X	0xAD
+#define INTEL_GRANITERAPIDS_X		IFM(6, 0xAD)
 #define INTEL_FAM6_GRANITERAPIDS_D	0xAE
+#define INTEL_GRANITERAPIDS_D		IFM(6, 0xAE)
 
 /* "Hybrid" Processors (P-Core/E-Core) */
 
 #define INTEL_FAM6_LAKEFIELD		0x8A	/* Sunny Cove / Tremont */
+#define INTEL_LAKEFIELD			IFM(6, 0x8A) /* Sunny Cove / Tremont */
 
 #define INTEL_FAM6_ALDERLAKE		0x97	/* Golden Cove / Gracemont */
+#define INTEL_ALDERLAKE			IFM(6, 0x97) /* Golden Cove / Gracemont */
 #define INTEL_FAM6_ALDERLAKE_L		0x9A	/* Golden Cove / Gracemont */
+#define INTEL_ALDERLAKE_L		IFM(6, 0x9A) /* Golden Cove / Gracemont */
 
 #define INTEL_FAM6_RAPTORLAKE		0xB7	/* Raptor Cove / Enhanced Gracemont */
+#define INTEL_RAPTORLAKE		IFM(6, 0xB7) /* Raptor Cove / Enhanced Gracemont */
 #define INTEL_FAM6_RAPTORLAKE_P		0xBA
+#define INTEL_RAPTORLAKE_P		IFM(6, 0xBA)
 #define INTEL_FAM6_RAPTORLAKE_S		0xBF
+#define INTEL_RAPTORLAKE_S		IFM(6, 0xBF)
 
 #define INTEL_FAM6_METEORLAKE		0xAC
+#define INTEL_METEORLAKE		IFM(6, 0xAC)
 #define INTEL_FAM6_METEORLAKE_L		0xAA
+#define INTEL_METEORLAKE_L		IFM(6, 0xAA)
 
 #define INTEL_FAM6_ARROWLAKE_H		0xC5
+#define INTEL_ARROWLAKE_H		IFM(6, 0xC5)
 #define INTEL_FAM6_ARROWLAKE		0xC6
+#define INTEL_ARROWLAKE			IFM(6, 0xC6)
 #define INTEL_FAM6_ARROWLAKE_U		0xB5
+#define INTEL_ARROWLAKE_U		IFM(6, 0xB5)
 
 #define INTEL_FAM6_LUNARLAKE_M		0xBD
+#define INTEL_LUNARLAKE_M		IFM(6, 0xBD)
 
 /* "Small Core" Processors (Atom/E-Core) */
 
 #define INTEL_FAM6_ATOM_BONNELL		0x1C /* Diamondville, Pineview */
+#define INTEL_ATOM_BONNELL		IFM(6, 0x1C) /* Diamondville, Pineview */
 #define INTEL_FAM6_ATOM_BONNELL_MID	0x26 /* Silverthorne, Lincroft */
+#define INTEL_ATOM_BONNELL_MID		IFM(6, 0x26) /* Silverthorne, Lincroft */
 
 #define INTEL_FAM6_ATOM_SALTWELL	0x36 /* Cedarview */
+#define INTEL_ATOM_SALTWELL		IFM(6, 0x36) /* Cedarview */
 #define INTEL_FAM6_ATOM_SALTWELL_MID	0x27 /* Penwell */
+#define INTEL_ATOM_SALTWELL_MID		IFM(6, 0x27) /* Penwell */
 #define INTEL_FAM6_ATOM_SALTWELL_TABLET	0x35 /* Cloverview */
+#define INTEL_ATOM_SALTWELL_TABLET	IFM(6, 0x35) /* Cloverview */
 
 #define INTEL_FAM6_ATOM_SILVERMONT	0x37 /* Bay Trail, Valleyview */
+#define INTEL_ATOM_SILVERMONT		IFM(6, 0x37) /* Bay Trail, Valleyview */
 #define INTEL_FAM6_ATOM_SILVERMONT_D	0x4D /* Avaton, Rangely */
+#define INTEL_ATOM_SILVERMONT_D		IFM(6, 0x4D) /* Avaton, Rangely */
 #define INTEL_FAM6_ATOM_SILVERMONT_MID	0x4A /* Merriefield */
+#define INTEL_ATOM_SILVERMONT_MID	IFM(6, 0x4A) /* Merriefield */
 
 #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
+#define INTEL_ATOM_AIRMONT		IFM(6, 0x4C) /* Cherry Trail, Braswell */
 #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
+#define INTEL_ATOM_AIRMONT_MID		IFM(6, 0x5A) /* Moorefield */
 #define INTEL_FAM6_ATOM_AIRMONT_NP	0x75 /* Lightning Mountain */
+#define INTEL_ATOM_AIRMONT_NP		IFM(6, 0x75) /* Lightning Mountain */
 
 #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
+#define INTEL_ATOM_GOLDMONT		IFM(6, 0x5C) /* Apollo Lake */
 #define INTEL_FAM6_ATOM_GOLDMONT_D	0x5F /* Denverton */
+#define INTEL_ATOM_GOLDMONT_D		IFM(6, 0x5F) /* Denverton */
 
 /* Note: the micro-architecture is "Goldmont Plus" */
 #define INTEL_FAM6_ATOM_GOLDMONT_PLUS	0x7A /* Gemini Lake */
+#define INTEL_ATOM_GOLDMONT_PLUS	IFM(6, 0x7A) /* Gemini Lake */
 
 #define INTEL_FAM6_ATOM_TREMONT_D	0x86 /* Jacobsville */
+#define INTEL_ATOM_TREMONT_D		IFM(6, 0x86) /* Jacobsville */
 #define INTEL_FAM6_ATOM_TREMONT		0x96 /* Elkhart Lake */
+#define INTEL_ATOM_TREMONT		IFM(6, 0x96) /* Elkhart Lake */
 #define INTEL_FAM6_ATOM_TREMONT_L	0x9C /* Jasper Lake */
+#define INTEL_ATOM_TREMONT_L		IFM(6, 0x9C) /* Jasper Lake */
 
 #define INTEL_FAM6_ATOM_GRACEMONT	0xBE /* Alderlake N */
+#define INTEL_ATOM_GRACEMONT		IFM(6, 0xBE) /* Alderlake N */
 
 #define INTEL_FAM6_ATOM_CRESTMONT_X	0xAF /* Sierra Forest */
+#define INTEL_ATOM_CRESTMONT_X		IFM(6, 0xAF) /* Sierra Forest */
 #define INTEL_FAM6_ATOM_CRESTMONT	0xB6 /* Grand Ridge */
+#define INTEL_ATOM_CRESTMONT		IFM(6, 0xB6) /* Grand Ridge */
 
 #define INTEL_FAM6_ATOM_DARKMONT_X	0xDD /* Clearwater Forest */
+#define INTEL_ATOM_DARKMONT_X		IFM(6, 0xDD) /* Clearwater Forest */
 
 /* Xeon Phi */
 
 #define INTEL_FAM6_XEON_PHI_KNL		0x57 /* Knights Landing */
+#define INTEL_XEON_PHI_KNL		IFM(6, 0x57) /* Knights Landing */
 #define INTEL_FAM6_XEON_PHI_KNM		0x85 /* Knights Mill */
+#define INTEL_XEON_PHI_KNM		IFM(6, 0x85) /* Knights Mill */
 
 /* Family 5 */
 #define INTEL_FAM5_QUARK_X1000		0x09 /* Quark X1000 SoC */
+#define INTEL_QUARK_X1000		IFM(5, 0x09) /* Quark X1000 SoC */
 
 #endif /* _ASM_X86_INTEL_FAMILY_H */
diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
index ad6776081e60..2243083f0bc2 100644
--- a/arch/x86/kernel/cpu/match.c
+++ b/arch/x86/kernel/cpu/match.c
@@ -17,8 +17,7 @@
  *
  * A typical table entry would be to match a specific CPU
  *
- * X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_BROADWELL,
- *				      X86_FEATURE_ANY, NULL);
+ * X86_MATCH_VFM_FEATURE(INTEL_BROADWELL, X86_FEATURE_ANY, NULL);
  *
  * Fields can be wildcarded with %X86_VENDOR_ANY, %X86_FAMILY_ANY,
  * %X86_MODEL_ANY, %X86_FEATURE_ANY (except for vendor)
-- 
2.44.0

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Thu, Mar 28, 2024 at 09:37:44AM -0700, Tony Luck wrote:
> Refactor struct cpuinfo_x86 so that the vendor, family, and model
> fields are overlayed in a union with a 32-bit field that combines
> all three (together with a one byte reserved field in the upper
> byte).
> 
> This will make it easy, cheap, and reliable to check all three
> values at once.
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/include/asm/processor.h | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 811548f131f4..87115e5d884f 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -108,9 +108,15 @@ struct cpuinfo_topology {
>  };
>  
>  struct cpuinfo_x86 {
> -	__u8			x86;		/* CPU family */
> -	__u8			x86_vendor;	/* CPU vendor */
> -	__u8			x86_model;
> +	union {
> +		struct {
> +			__u8	x86_vendor;	/* CPU vendor */
> +			__u8	x86;		/* CPU family */
> +			__u8	x86_model;
> +			__u8	x86_reserved;
> +		};
> +		__u32		x86_vfm;	/* combined vendor, family, model */
> +	};
>  	__u8			x86_stepping;

Why are you leaving out stepping?

And since we want to simplify all this, why aren't we replacing all
f/m/s checks by using the whole CPUID(1).EAX u32 instead?

Then the macros need to build that CPUID leaf simply.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Thu, Mar 28, 2024 at 05:48:11PM +0100, Borislav Petkov wrote:
> > +		struct {
> > +			__u8	x86_vendor;	/* CPU vendor */

Looking at this more - you don't really need the vendor to be part of
this as the CPUID leaf ranges should *actually* be disjunct. Actually...

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

>>  	__u8			x86_stepping;
>
> Why are you leaving out stepping?

There are only a handful of places where stepping is significant in CPU model
specific checks (mostly errata and side-channel security stuff). I didn't want to
have to invent new #define names for each stepping. E.g. there are about
three separate steppings of INTEL_SKYLAKE_X out in the wild. It would
be messy to have three #defines and add them in all the stepping independent
code paths.

> And since we want to simplify all this, why aren't we replacing all
> f/m/s checks by using the whole CPUID(1).EAX u32 instead?
>
> Then the macros need to build that CPUID leaf simply.

I could make the raw format of the #define values be CPUID(1).EAX
with the stepping masked out. But then I'd need to add a new field to
the structure instead of overlaying with the vendor/family/model
fields.

-Tony

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

> Looking at this more - you don't really need the vendor to be part of
> this as the CPUID leaf ranges should *actually* be disjunct. Actually...

It's essentially free to do this, and it makes the code more robust. It
becomes impossible to check model without also checking vendor
and family at the same time.

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Thu, Mar 28, 2024 at 04:56:37PM +0000, Luck, Tony wrote:
> I could make the raw format of the #define values be CPUID(1).EAX
> with the stepping masked out. But then I'd need to add a new field to
> the structure instead of overlaying with the vendor/family/model
> fields.

Yes, that would be better. And if you're going to replace our f/m/s
checking with something better, then it better handle the stepping just
like the rest. How it is used now doesn't mean a whole lot for the
future.

And if it is not too important for most checks, you can mask it out with
macros.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Thu, Mar 28, 2024 at 05:00:59PM +0000, Luck, Tony wrote:
> It's essentially free to do this, and it makes the code more robust. It
> becomes impossible to check model without also checking vendor
> and family at the same time.

I see that but if we want to use CPUID(1).EAX, there's no vendor in
there.

And frankly, the x86 vendor is a Linux thing so I wouldn't mind if
checks are

	if (c->x86_vendor  == X86_VENDOR... &&
	    c->cpuid_1_eax == MACRO_BUILD_CPUID_1_EAX(fam, model, stepping))

Anyway, using CPUID(1).EAX is just a suggestion so that we don't have to
invent our own format and convert to and fro.

And that would be advantageous when we convert to dealing with
CPUID(1).EAX values everywhere and we compare them straightaway. We'd
need macros only when we need only some data elements from that leaf.

And since that leaf's layout is commonly known, the conversion errors
should be at a minimum...

I'd say.

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

> And frankly, the x86 vendor is a Linux thing so I wouldn't mind if
> checks are
>
>	if (c->x86_vendor  == X86_VENDOR... &&
>	    c->cpuid_1_eax == MACRO_BUILD_CPUID_1_EAX(fam, model, stepping))

That hurts my eyes compared to:

	if (c->x86_vfm == INTEL_DOUGLASCOVE)

>
> Anyway, using CPUID(1).EAX is just a suggestion so that we don't have to
> invent our own format and convert to and fro.

All the conversion is at compile time to generate the values for the CPU model
name #defines.

> And that would be advantageous when we convert to dealing with
> CPUID(1).EAX values everywhere and we compare them straightaway. We'd
> need macros only when we need only some data elements from that leaf.

It's a humungous amount more code churn. Most of the changes in this set were
achieved with some simple sed scripts (followed by hand massage to adjust TABs
to make things pretty because lengths of strings are different).

Take a look at a few of the patches that implement this change and consider
how they would look based on a CPUID(1).EAX value.

> And since that leaf's layout is commonly known, the conversion errors
> should be at a minimum...
>
> I'd say.

I don't think the format is really that big an issue. Including stepping in the
format adds complexity to a thousand places these checks are made while
only being useful in a few dozen.

-Tony

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

> I don't think the format is really that big an issue. Including stepping in the
> format adds complexity to a thousand places these checks are made while
> only being useful in a few dozen.

Stats to back that up:

$ git grep INTEL_FAM6 | wc -l
876

but some of those are the definitions of the model name macros:
$ git grep INTEL_FAM6 -- arch/x86/include/asm/intel-family.h | wc -l
82

Places using the X86_MATCH_INTEL macros don't show in above count:

$ git grep X86_MATCH_INTEL | wc -l
430

Places that use STEPPINGS:
$ git grep X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS | wc -l
21

or STEPPINGS + FEATURE
$ git grep gg X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE | wc -l
6

$ git grep x86_stepping | wc -l
83

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Thu, Mar 28, 2024 at 06:32:35PM +0000, Luck, Tony wrote:
> I don't think the format is really that big an issue. Including stepping in the
> format adds complexity to a thousand places these checks are made while
> only being useful in a few dozen.

I've figured out what the problem is with steppings - ranges. If you
have a range of steppings which all belong to the same model, then you
have to complicate the checks by either masking out the stepping or use
the X86_STEPPING_ANY thing which forces you to use x86_match_cpu()
instead of a simple integer comparison.

And you should talk to your folks what their plan is for the new
families because if they do a range of model numbers which all belong to
the same CPU model like AMD does, then your simple comparison scheme
goes out the window because it can't really deal with ranges.

Because from looking at your set, I don't see a slick way to check
whether a concrete f/m/s tuple belongs to a range without involved
checking.

For example, models:

                case 0x30 ... 0x4f:
                case 0x60 ... 0x7f:
                case 0x90 ... 0x91:
                case 0xa0 ... 0xaf:

are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had
a patch like that at some point but it didn't go in. But even if I did
that, I'd still need to do x86_match_cpu() instead of the current
X86_FEATURE_ZEN* checks we're doing.

So I don't think I can switch AMD to use that. It looks like the 'V' in
"VFM" could just as well turn into "I".

:-)

I'd say.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Tony Luck]

On Fri, Mar 29, 2024 at 12:40:07PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2024 at 06:32:35PM +0000, Luck, Tony wrote:
> > I don't think the format is really that big an issue. Including stepping in the
> > format adds complexity to a thousand places these checks are made while
> > only being useful in a few dozen.
> 
> I've figured out what the problem is with steppings - ranges. If you
> have a range of steppings which all belong to the same model, then you
> have to complicate the checks by either masking out the stepping or use
> the X86_STEPPING_ANY thing which forces you to use x86_match_cpu()
> instead of a simple integer comparison.

I think you are talking about a range of models that all belong to
the same family (rather than steppings in the same model).

> And you should talk to your folks what their plan is for the new
> families because if they do a range of model numbers which all belong to
> the same CPU model like AMD does, then your simple comparison scheme
> goes out the window because it can't really deal with ranges.

History of Intel model number allocations apparently looks like
we just throw a dart in the general area of a block of unused
model numbers :-)  I will check with the relevent folks, but this
seems unlikely. There's more push (from the Linux community!) to
assign CPUID feature bits for stuff that goes more than 2-3
CPU generations. That leaves the stuff that is different almost
every time (perfomaance counters, power management, EDAC, etc.).

> Because from looking at your set, I don't see a slick way to check
> whether a concrete f/m/s tuple belongs to a range without involved
> checking.
> 
> For example, models:
> 
>                 case 0x30 ... 0x4f:
>                 case 0x60 ... 0x7f:
>                 case 0x90 ... 0x91:
>                 case 0xa0 ... 0xaf:
> 
> are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had

I'm glad I don't have to keep track of groups of hex numbers like that.

> a patch like that at some point but it didn't go in. But even if I did
> that, I'd still need to do x86_match_cpu() instead of the current
> X86_FEATURE_ZEN* checks we're doing.

My patch doesn't help with this, but doesn't prevent you from doing
a switch (c->x86_model).  If that list of model number ranges shows
up more than twice you could add a helper that converts that list to
a #define AMD_ZEN2 to make the code clearer.

> So I don't think I can switch AMD to use that. It looks like the 'V' in
> "VFM" could just as well turn into "I".

Patch 3 includes:

#define IFM(_fam, _model)      VFM_MAKE(X86_VENDOR_INTEL, _fam, _model)

as a helper to build model numbers in <asm/intel-family.h>
> 
> :-)
> 
> I'd say.

So keep the "V" in the common code. Maybe one of the other x86
vendors will want to have #define names for their CPU models
some day.

Thanks for digging into this.

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Fri, Mar 29, 2024 at 09:46:25AM -0700, Tony Luck wrote:
> I think you are talking about a range of models that all belong to
> the same family (rather than steppings in the same model).

Either. Depending on what you're tracking. If the majority of your
feature tests want to determine whether you're running on the same set
of hw features which belong to a model determined by a single or
multiple model numbers, then you need to track that.

On Intel you have a single model number determining that set of hw
features.

On AMD you have s range of model numbers and there can be differences
too.

Seldom we pay attention to steppings but it is not unheard of. We have
had an incremented stepping denoting a hw bug fix in the past.

> History of Intel model number allocations apparently looks like
> we just throw a dart in the general area of a block of unused
> model numbers :-)

Don't say that. The guy who's assigning the numbers and keeps track of
what he's given to which team, will be mad at you. :-P

> I'm glad I don't have to keep track of groups of hex numbers like that.

Depends on how you model it. Setting a X86_FEATURE_ZEN<n> for each works
like a charm.

> My patch doesn't help with this, but doesn't prevent you from doing
> a switch (c->x86_model).  If that list of model number ranges shows
> up more than twice you could add a helper that converts that list to
> a #define AMD_ZEN2 to make the code clearer.

Haven't needed such stunts yet and I hope I won't ever.

> So keep the "V" in the common code. Maybe one of the other x86
> vendors will want to have #define names for their CPU models
> some day.

Right.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Tony Luck]

On Fri, Mar 29, 2024 at 12:40:07PM +0100, Borislav Petkov wrote:
> Because from looking at your set, I don't see a slick way to check
> whether a concrete f/m/s tuple belongs to a range without involved
> checking.
> 
> For example, models:
> 
>                 case 0x30 ... 0x4f:
>                 case 0x60 ... 0x7f:
>                 case 0x90 ... 0x91:
>                 case 0xa0 ... 0xaf:
> 
> are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had
> a patch like that at some point but it didn't go in. But even if I did
> that, I'd still need to do x86_match_cpu() instead of the current
> X86_FEATURE_ZEN* checks we're doing.

I realized the problem with ranges is the order I put the bits into the
x86_vfm field. If I swap around to put the vendor in high bits, family
in the middle, model in low bits like this:

struct cpuinfo_x86 {
        union {
                struct {
                        __u8    x86_model;
                        __u8    x86;            /* CPU family */
                        __u8    x86_vendor;     /* CPU vendor */
                        __u8    x86_reserved;
                };
                __u32           x86_vfm;        /* combined vendor, family, model */
        };

Then ranges of models within (or across) familiies can work.  E.g. the
AMD Zen generation checking could be changed from:


	/* Figure out Zen generations: */
	switch (c->x86) {
	case 0x17:
		switch (c->x86_model) {
		case 0x00 ... 0x2f:
		case 0x50 ... 0x5f:
			setup_force_cpu_cap(X86_FEATURE_ZEN1);
			break;
		case 0x30 ... 0x4f:
		case 0x60 ... 0x7f:
		case 0x90 ... 0x91:
		case 0xa0 ... 0xaf:
			setup_force_cpu_cap(X86_FEATURE_ZEN2);
			break;
		default:
			goto warn;
		}
		break;

	case 0x19:
		switch (c->x86_model) {
		case 0x00 ... 0x0f:
		case 0x20 ... 0x5f:
			setup_force_cpu_cap(X86_FEATURE_ZEN3);
			break;
		case 0x10 ... 0x1f:
		case 0x60 ... 0xaf:
			setup_force_cpu_cap(X86_FEATURE_ZEN4);
			break;
		default:
			goto warn;
		}
		break;

	case 0x1a:
		switch (c->x86_model) {
		case 0x00 ... 0x0f:
		case 0x20 ... 0x2f:
		case 0x40 ... 0x4f:
		case 0x70 ... 0x7f:
			setup_force_cpu_cap(X86_FEATURE_ZEN5);
			break;
		default:
			goto warn;
		}
		break;

	default:
		break;
	}

to:

	/* Figure out Zen generations: */
	switch (c->x86_vfm) {
	case AFM(0x17, 0x00) ... AFM(0x17, 0x2f):
	case AFM(0x17, 0x50) ... AFM(0x17, 0x5f):
		setup_force_cpu_cap(X86_FEATURE_ZEN1);
		break;
	case AFM(0x17, 0x30) ... AFM(0x17, 0x4f):
	case AFM(0x17, 0x60) ... AFM(0x17, 0x7f):
	case AFM(0x17, 0x90) ... AFM(0x17, 0x91):
	case AFM(0x17, 0xa0) ... AFM(0x17, 0xaf):
		setup_force_cpu_cap(X86_FEATURE_ZEN2);
		break;
	case AFM(0x19, 0x00) ... AFM(0x19, 0x0f):
	case AFM(0x19, 0x20) ... AFM(0x19, 0x5f):
		setup_force_cpu_cap(X86_FEATURE_ZEN3);
		break;
	case AFM(0x19, 0x10) ... AFM(0x19, 0x1f):
	case AFM(0x19, 0x60) ... AFM(0x19, 0xaf):
		setup_force_cpu_cap(X86_FEATURE_ZEN4);
		break;
	case AFM(0x1a, 0x00) ... AFM(0x1a, 0x0f):
	case AFM(0x1a, 0x20) ... AFM(0x1a, 0x2f):
	case AFM(0x1a, 0x40) ... AFM(0x1a, 0x4f):
	case AFM(0x1a, 0x70) ... AFM(0x1a, 0x7f):
		setup_force_cpu_cap(X86_FEATURE_ZEN5);
		break;
	default:
		goto warn;
	}


That's more visually more compact, but maybe not any more readable.
But you would have the *option* to do this.

I'll post V2 of parts 1 & 2 with the re-ordered fields. None of the rest
of the patches need to change.

-Tony

[PATCH v2 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Tony Luck]

Refactor struct cpuinfo_x86 so that the vendor, family, and model
fields are overlayed in a union with a 32-bit field that combines
all three (together with a one byte reserved field in the upper
byte).

This will make it easy, cheap, and reliable to check all three
values at once.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/processor.h | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 811548f131f4..4c5d166aa473 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -108,9 +108,15 @@ struct cpuinfo_topology {
 };
 
 struct cpuinfo_x86 {
-	__u8			x86;		/* CPU family */
-	__u8			x86_vendor;	/* CPU vendor */
-	__u8			x86_model;
+	union {
+		struct {
+			__u8	x86_model;
+			__u8	x86;		/* CPU family */
+			__u8	x86_vendor;	/* CPU vendor */
+			__u8	x86_reserved;
+		};
+		__u32		x86_vfm;	/* combined vendor, family, model */
+	};
 	__u8			x86_stepping;
 #ifdef CONFIG_X86_64
 	/* Number of 4K pages in DTLB/ITLB combined(in pages): */
-- 
2.44.0

[PATCH v2 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values

[Tony Luck]

To avoid adding a slew of new macros for each new Intel CPU family
switch over from providing CPU model number #defines to a new
scheme that encodes vendor, family, and model in a single number.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/include/asm/cpu_device_id.h | 93 ++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index eb8fcede9e3b..b8a86c227d65 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -2,6 +2,39 @@
 #ifndef _ASM_X86_CPU_DEVICE_ID
 #define _ASM_X86_CPU_DEVICE_ID
 
+/*
+ * Can't use <linux/bitfield.h> because it generates expressions that
+ * cannot be used in structure initializers. Bitfield construction
+ * here must match the union in struct cpuinfo_86:
+ *	union {
+ *		struct {
+ *			__u8	x86_model;
+ *			__u8	x86;
+ *			__u8	x86_vendor;
+ *			__u8	x86_reserved;
+ *		};
+ *		__u32		x86_vfm;
+ *	};
+ */
+#define VFM_MODEL_BIT	0
+#define VFM_FAMILY_BIT	8
+#define VFM_VENDOR_BIT	16
+#define VFM_RSVD_BIT	24
+
+#define	VFM_MODEL_MASK	GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
+#define	VFM_FAMILY_MASK	GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
+#define	VFM_VENDOR_MASK	GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
+
+#define VFM_MODEL(vfm)	(((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
+#define VFM_FAMILY(vfm)	(((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
+#define VFM_VENDOR(vfm)	(((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
+
+#define	VFM_MAKE(_vendor, _family, _model) (	\
+	((_model) << VFM_MODEL_BIT) |		\
+	((_family) << VFM_FAMILY_BIT) |		\
+	((_vendor) << VFM_VENDOR_BIT)		\
+)
+
 /*
  * Declare drivers belonging to specific x86 CPUs
  * Similar in spirit to pci_device_id and related PCI functions
@@ -49,6 +82,16 @@
 	.driver_data	= (unsigned long) _data				\
 }
 
+#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
+						    _steppings, _feature, _data) { \
+	.vendor		= _vendor,					\
+	.family		= _family,					\
+	.model		= _model,					\
+	.steppings	= _steppings,					\
+	.feature	= _feature,					\
+	.driver_data	= (unsigned long) _data				\
+}
+
 /**
  * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Macro for CPU matching
  * @_vendor:	The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
@@ -164,6 +207,56 @@
 	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
 						     steppings, X86_FEATURE_ANY, data)
 
+/**
+ * X86_MATCH_VFM - Match encoded vendor/family/model
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
+/**
+ * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @steppings:	Bitmask of steppings to match
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
+/**
+ * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
+ * @vfm:	Encoded 8-bits each for vendor, family, model
+ * @feature:	A X86_FEATURE bit
+ * @data:	Driver specific data or NULL. The internal storage
+ *		format is unsigned long. The supplied value, pointer
+ *		etc. is casted 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)
+
 /*
  * Match specific microcode revisions.
  *
-- 
2.44.0

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Mon, Apr 01, 2024 at 11:18:57AM -0700, Tony Luck wrote:
> That's more visually more compact, but maybe not any more readable.

Yap, I see it the same way.

> But you would have the *option* to do this.

Thanks, yeah, in case we ever get to cross that bridge...

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

>> That's more visually more compact, but maybe not any more readable.
>
> Yap, I see it the same way.
>
> But you would have the *option* to do this.
>
> Thanks, yeah, in case we ever get to cross that bridge...

Boris,

So are parts 1-3 ready for TIP? If they get added I can start collecting
reviews for parts 4-72.

73 and 74 are the cleanup to delete bits that are no longer needed.

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Mon, Apr 08, 2024 at 04:20:36PM +0000, Luck, Tony wrote:
> So are parts 1-3 ready for TIP? If they get added I can start collecting
> reviews for parts 4-72.

I'd like for tglx to have a look at this first too.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v2 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Thomas Gleixner]

On Mon, Apr 01 2024 at 11:23, Tony Luck wrote:

> Refactor struct cpuinfo_x86 so that the vendor, family, and model
> fields are overlayed in a union with a 32-bit field that combines
> all three (together with a one byte reserved field in the upper
> byte).
>
> This will make it easy, cheap, and reliable to check all three
> values at once.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

> ---
>  arch/x86/include/asm/processor.h | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 811548f131f4..4c5d166aa473 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -108,9 +108,15 @@ struct cpuinfo_topology {
>  };
>  
>  struct cpuinfo_x86 {
> -	__u8			x86;		/* CPU family */
> -	__u8			x86_vendor;	/* CPU vendor */
> -	__u8			x86_model;
> +	union {
> +		struct {
> +			__u8	x86_model;
> +			__u8	x86;		/* CPU family */
> +			__u8	x86_vendor;	/* CPU vendor */
> +			__u8	x86_reserved;
> +		};
> +		__u32		x86_vfm;	/* combined vendor, family, model */
> +	};
>  	__u8			x86_stepping;
>  #ifdef CONFIG_X86_64
>  	/* Number of 4K pages in DTLB/ITLB combined(in pages): */

Re: [PATCH v2 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values

[Thomas Gleixner]

On Mon, Apr 01 2024 at 11:24, Tony Luck wrote:
> To avoid adding a slew of new macros for each new Intel CPU family
> switch over from providing CPU model number #defines to a new
> scheme that encodes vendor, family, and model in a single number.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

Re: [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h

[Thomas Gleixner]

On Thu, Mar 28 2024 at 09:37, Tony Luck wrote:

> New CPU #defines encode vendor and family as well as model.
>
> Update the example usage comment in arch/x86/kernel/cpu/match.c
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Tony Luck]

On Tue, Apr 09, 2024 at 10:22:17AM +0200, Borislav Petkov wrote:
> On Mon, Apr 08, 2024 at 04:20:36PM +0000, Luck, Tony wrote:
> > So are parts 1-3 ready for TIP? If they get added I can start collecting
> > reviews for parts 4-72.
> 
> I'd like for tglx to have a look at this first too.

Boris,

Thomas gave his Reviewed-by for parts 1-3

Link: https://lore.kernel.org/all/871q7e7lfu.ffs@tglx/
Link: https://lore.kernel.org/all/87y19m66tu.ffs@tglx/
Link: https://lore.kernel.org/all/87v84q66sn.ffs@tglx/

Is there anyone else that needs a quick poke to look at these?

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Tue, Apr 16, 2024 at 11:16:05AM -0700, Tony Luck wrote:
> Thomas gave his Reviewed-by for parts 1-3
> 
> Link: https://lore.kernel.org/all/871q7e7lfu.ffs@tglx/
> Link: https://lore.kernel.org/all/87y19m66tu.ffs@tglx/
> Link: https://lore.kernel.org/all/87v84q66sn.ffs@tglx/
> 
> Is there anyone else that needs a quick poke to look at these?

I don't think so.

Aren't you going to send the whole set first though?

Or what is the merge strategy here?

Thx.

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

>> Is there anyone else that needs a quick poke to look at these?
>
> I don't think so.
>
> Aren't you going to send the whole set first though?
>
> Or what is the merge strategy here?

I thought to get the first three into TIP, and thus into linux-next. Then I'd
start posting patches to the individual files to their respective maintainers.

Only about half are arch/x86. The rest are scattered around the tree.

But if you'd like to see the whole series in one big mail thread, I can
post it all.

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Tue, Apr 16, 2024 at 06:37:18PM +0000, Luck, Tony wrote:
> I thought to get the first three into TIP, and thus into linux-next. Then I'd
> start posting patches to the individual files to their respective maintainers.
> 
> Only about half are arch/x86. The rest are scattered around the tree.

If you do that, people would have to merge the tip branch which has them
before they apply them in their tree.

Alternatively, we can take the arch/x86 parts and once 6.10 releases,
the other maintainers will have them in tree and thus not need the
cross-tree merges.

> But if you'd like to see the whole series in one big mail thread, I can
> post it all.

Or you can post the whole series and we can take it all through tip once
the other maintainers ack the respective patch for their area. Which
sounds like the simplest solution to me...

Thx.

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

> Alternatively, we can take the arch/x86 parts and once 6.10 releases,
> the other maintainers will have them in tree and thus not need the
> cross-tree merges.

I did a bit of this. I moved all the arch/x86 patches up to immediately follow
the three prep patches. So you can pick through parts 0004..0039 and apply
any that look good to you (there is no ordering requirement among these).
Bounce anything that needs extra work back to me.

> Or you can post the whole series and we can take it all through tip once
> the other maintainers ack the respective patch for their area. Which
> sounds like the simplest solution to me...

Also a bit of this. Parts 0040..0072 are posted to whomever get_maintainer.pl
said might be interested. So may see some reviews coming in for these.

Parts 0073..0074 are the cleanup to delete the old macros. They can only
be applied after everything else has been merged.

-Tony

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Sean Christopherson]

On Tue, Apr 16, 2024, Tony Luck wrote:
> > Alternatively, we can take the arch/x86 parts and once 6.10 releases,
> > the other maintainers will have them in tree and thus not need the
> > cross-tree merges.
> 
> I did a bit of this. I moved all the arch/x86 patches up to immediately follow
> the three prep patches. So you can pick through parts 0004..0039 and apply
> any that look good to you (there is no ordering requirement among these).
> Bounce anything that needs extra work back to me.

There are two KVM changes hiding in there, but they're obviously quite trivial
and can to through tip, I don't expect any conflicts.

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Borislav Petkov]

On Wed, Apr 17, 2024 at 12:02:21PM -0700, Sean Christopherson wrote:
> There are two KVM changes hiding in there, but they're obviously quite trivial
> and can to through tip, I don't expect any conflicts.

Yeah, the plan is to queue it all through tip as that would be a lot
less conflicts and cross-tree issues so you acking them is what I was
hoping to get.

So thanks. :-)

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86

[Luck, Tony]

> On Apr 17, 2024, at 12:43, Borislav Petkov <bp@alien8.de> wrote:
> 
> On Wed, Apr 17, 2024 at 12:02:21PM -0700, Sean Christopherson wrote:
>> There are two KVM changes hiding in there, but they're obviously quite trivial
>> and can to through tip, I don't expect any conflicts.
> 
> Yeah, the plan is to queue it all through tip as that would be a lot
> less conflicts and cross-tree issues so you acking them is what I was
> hoping to get.
> 
> So thanks. :-)

There’s general (justified) grumbling about
my auto-generated Subject lines. So I’ll make
a pass through the whole series to make the
initial tag match each subsystem convention. 
Also make it generally more useful. I.e. like this
for most of the arch/x86 patches:

Subject: x86/cpu: Use new Intel CPU model #defines

Perhaps all the pieces with Reviewed or Acked
tags can go into tip tree next week?

-Tony

[PATCH 00/74] New Intel CPUID families

[Tony Luck]

Q1: Where are all the other parts of this series. I only got 1-3.
A1: There are ~2700 subscribers to LKML. I want to get some feedback
on the approach and naming etc. before spamming everyone with a 74
patch series.

Q2: Can I get the other parts?
A2: Sure. I posted them to patches@lists.linux.dev so you can get them
with:
$ b4 am 20240328090459.242500-tony.luck@intel.com
or get from kernel.org with:
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git new_families

Q3: When are CPUs using new families coming?
A3: Soon-ish. We have some time to get the infrastructure right.

Intel has been using family 6 almost exclusively for many
years. As a result, Linux has built up infrastructure like
X86_MATCH_INTEL_FAM6_MODEL() to make it easy for model specific code to
use the #defines for each Intel CPU model.

But the reign of family 6 is about to end. Intel will begin using non-zero
values for the extended family field in CPUID(1).EAX. The minimal patch
size approach to handle these would be to clone the FAM6 macros. But
that will get messy as these prolifrate. This approach does not have an
elegant solution if a switch() statement needs to choose between CPUs
from different families.

Dave Hansen suggested that a more general cleanup that provides
CPU #defines that encode all of <vendor, family, model> would make
existing code better, and provide infrastructure that makes it trivial
to incorporate new families.

Big picture view is that code like this:

  if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)

can become:

  if (c->x86_vfm == INTEL_ICELAKE_X)

which is:
a)	Simpler
b)	Faster
c)	More resilient (can't forget to check vendor & family along with model)
d)	Code style doesn't change for every new family.

Note that "struct cpuinfo_x86" gains a new xf6_vfm field and the ICELAKE
#define loses the "FAM6_" substring and will be initialized with a macro
that does the bit shuffling to fit X86_VENDOR_INTEL and a family and
model into a "u32":

#define INTEL_ICELAKE_X                 IFM(6, 0x6A) /* Sunny Cove */

New CPUs in other families might look like:

#define INTEL_DOUGLASCOVE		IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT		IFM(73, 0x01) /* Cooper Forest */

Model specific "if" statements then follow the same pattern
regardless of family:

  if (c->x86_vfm == INTEL_DOUGLASCOVE || c->x86_vfm == INTEL_SHELDONMONT) {
  }

If needed these could even appear in the same switch statement:

	switch (c->x86_vfm) {
	case INTEL_ICELAKE_X:
		...
	case INTEL_DOUGLASCOVE:
		...
	case INTEL_SHELDONMONT:
		...
	}

The existing X86_MATCH_INTEL_FAM6_MODEL() can be replaced with a new
X86_MATCH_VFM() macro.

Update can happen in three phases:

1) Add infrastructure macros, new "x86_vfm" field, new CPU #defines

2) Treewide update from old to new (around 70 files at current count)

3) Delete the old INTEL_FAM6 and X86_MATCH_INTEL_FAM6 macros

Tony Luck (74):
  x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
  x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
  x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
  x86/cpu/vfm: Update arch/x86/crypto/poly1305_glue.c
  x86/cpu/vfm: Update arch/x86/crypto/twofish_glue_3way.c
  x86/cpu/vfm: Update arch/x86/events/intel/cstate.c
  x86/cpu/vfm: Update arch/x86/events/intel/lbr.c
  x86/cpu/vfm: Update arch/x86/events/intel/pt.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore_nhmex.c
  x86/cpu/vfm: Update arch/x86/events/intel/uncore_snbep.c
  x86/cpu/vfm: Update arch/x86/events/msr.c
  x86/cpu/vfm: Update arch/x86/events/rapl.c
  x86/cpu/vfm: Update arch/x86/kernel/apic/apic.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/aperfmperf.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/bugs.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/common.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/intel_epb.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/match.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/core.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/severity.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/microcode/intel.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/core.c
  x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/pseudo_lock.c
  x86/cpu/vfm: Update arch/x86/kernel/smpboot.c
  x86/cpu/vfm: Update arch/x86/kernel/tsc.c
  x86/cpu/vfm: Update arch/x86/kernel/tsc_msr.c
  x86/cpu/vfm: Update arch/x86/kvm/pmu.c
  x86/cpu/vfm: Update arch/x86/kvm/vmx/vmx.c
  x86/cpu/vfm: Update arch/x86/mm/init.c
  x86/cpu/vfm: Update arch/x86/pci/intel_mid_pci.c
  x86/cpu/vfm: Update arch/x86/virt/vmx/tdx/tdx.c
  x86/cpu/vfm: Update drivers/acpi/acpi_lpss.c
  x86/cpu/vfm: Update drivers/acpi/x86/utils.c
  x86/cpu/vfm: Update tpm files
  x86/cpu/vfm: Update drivers/cpufreq/intel_pstate.c
  x86/cpu/vfm: Update drivers/cpufreq/speedstep-centrino.c
  x86/cpu/vfm: Update drivers/edac/i10nm_base.c
  x86/cpu/vfm: Update drivers/edac/pnd2_edac.c
  x86/cpu/vfm: Update drivers/edac/sb_edac.c
  x86/cpu/vfm: Update drivers/edac/skx_base.c
  x86/cpu/vfm: Update drivers/extcon/extcon-axp288.c
  x86/cpu/vfm: Update drivers/hwmon/peci/cputemp.c
  x86/cpu/vfm: Update drivers/idle/intel_idle.c
  x86/cpu/vfm: Update drivers/pci/pci-mid.c
  x86/cpu/vfm: Update drivers/peci/cpu.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/ifs/core.c
  x86/cpu/vfm: Update drivers/platform/x86/intel_ips.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/core.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/pltdrv.c
  x86/cpu/vfm: Update drivers/platform/x86/intel_scu_wdt.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/speed_select_if/isst_if_common.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/debugfs.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/pltdrv.c
  x86/cpu/vfm: Update drivers/platform/x86/intel/turbo_max_3.c
  x86/cpu/vfm: Update
    drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
  x86/cpu/vfm: Update drivers/platform/x86/p2sb.c
  x86/cpu/vfm: Update drivers/powercap/intel_rapl_common.c
  x86/cpu/vfm: Update drivers/powercap/intel_rapl_msr.c
  x86/cpu/vfm: Update
    drivers/staging/media/atomisp/include/linux/atomisp_platform.h
  x86/cpu/vfm: Update intel_soc_dts_thermal.c
  x86/cpu/vfm: Update drivers/thermal/intel/intel_tcc_cooling.c
  x86/cpu/vfm: Update sound/soc/intel/avs/boards/es8336.c
  x86/cpu/vfm: Update arch/x86/events/intel/core.c
  x86/cpu/vfm: Update arch/x86/platform/intel-mid/intel-mid.c
  x86/cpu/vfm: Update arch/x86/platform/atom/punit_atom_debug.c
  x86/cpu/vfm: Update arch/x86/events/intel/core.c
  x86/cpu/vfm: Update tools/power/x86/turbostat/turbostat.c
  x86/cpu/vfm: Update arch/x86/boot/cpucheck.c
  x86/cpu/vfm: Delete X86_MATCH_INTEL_FAM6_MODEL[_STEPPING]() macros
  x86/cpu/vfm: Delete all the *_FAM6_ CPU #defines

 .../atomisp/include/linux/atomisp_platform.h  |  26 +--
 include/linux/peci-cpu.h                      |   1 +
 include/linux/platform_data/x86/soc.h         |  12 +-
 arch/x86/include/asm/cpu_device_id.h          | 103 +++++++--
 arch/x86/include/asm/intel-family.h           | 167 +++++++-------
 arch/x86/include/asm/processor.h              |  12 +-
 drivers/char/tpm/tpm.h                        |   1 +
 drivers/char/tpm/tpm_tis_core.h               |   2 +-
 arch/x86/boot/cpucheck.c                      |   2 +-
 arch/x86/crypto/poly1305_glue.c               |   3 +-
 arch/x86/crypto/twofish_glue_3way.c           |  10 +-
 arch/x86/events/intel/core.c                  | 212 +++++++++---------
 arch/x86/events/intel/cstate.c                | 144 ++++++------
 arch/x86/events/intel/lbr.c                   |   3 +-
 arch/x86/events/intel/pt.c                    |  11 +-
 arch/x86/events/intel/uncore.c                | 100 ++++-----
 arch/x86/events/intel/uncore_nhmex.c          |   3 +-
 arch/x86/events/intel/uncore_snbep.c          |   5 +-
 arch/x86/events/msr.c                         | 131 +++++------
 arch/x86/events/rapl.c                        |  84 +++----
 arch/x86/kernel/apic/apic.c                   |  38 ++--
 arch/x86/kernel/cpu/aperfmperf.c              |  17 +-
 arch/x86/kernel/cpu/bugs.c                    |  29 +--
 arch/x86/kernel/cpu/common.c                  | 154 +++++++------
 arch/x86/kernel/cpu/intel.c                   | 115 +++++-----
 arch/x86/kernel/cpu/intel_epb.c               |  12 +-
 arch/x86/kernel/cpu/match.c                   |   5 +-
 arch/x86/kernel/cpu/mce/core.c                |   5 +-
 arch/x86/kernel/cpu/mce/intel.c               |  20 +-
 arch/x86/kernel/cpu/mce/severity.c            |   9 +-
 arch/x86/kernel/cpu/microcode/intel.c         |   4 +-
 arch/x86/kernel/cpu/resctrl/core.c            |   9 +-
 arch/x86/kernel/cpu/resctrl/pseudo_lock.c     |  21 +-
 arch/x86/kernel/smpboot.c                     |   6 +-
 arch/x86/kernel/tsc.c                         |   5 +-
 arch/x86/kernel/tsc_msr.c                     |  14 +-
 arch/x86/kvm/pmu.c                            |   8 +-
 arch/x86/kvm/vmx/vmx.c                        |  20 +-
 arch/x86/mm/init.c                            |  16 +-
 arch/x86/pci/intel_mid_pci.c                  |   4 +-
 arch/x86/platform/atom/punit_atom_debug.c     |  11 +-
 arch/x86/platform/intel-mid/intel-mid.c       |   7 +-
 arch/x86/virt/vmx/tdx/tdx.c                   |   7 +-
 drivers/acpi/acpi_lpss.c                      |   4 +-
 drivers/acpi/x86/utils.c                      |  42 ++--
 drivers/cpufreq/intel_pstate.c                |  90 ++++----
 drivers/cpufreq/speedstep-centrino.c          |   8 +-
 drivers/edac/i10nm_base.c                     |  20 +-
 drivers/edac/pnd2_edac.c                      |   4 +-
 drivers/edac/sb_edac.c                        |  14 +-
 drivers/edac/skx_base.c                       |   2 +-
 drivers/extcon/extcon-axp288.c                |   2 +-
 drivers/hwmon/peci/cputemp.c                  |   7 +-
 drivers/idle/intel_idle.c                     | 116 +++++-----
 drivers/pci/pci-mid.c                         |   4 +-
 drivers/peci/cpu.c                            |  28 +--
 drivers/platform/x86/intel/ifs/core.c         |  15 +-
 drivers/platform/x86/intel/pmc/core.c         |  46 ++--
 drivers/platform/x86/intel/pmc/pltdrv.c       |  16 +-
 .../intel/speed_select_if/isst_if_common.c    |   4 +-
 .../intel/speed_select_if/isst_if_mbox_msr.c  |   2 +-
 .../platform/x86/intel/telemetry/debugfs.c    |   4 +-
 drivers/platform/x86/intel/telemetry/pltdrv.c |   4 +-
 drivers/platform/x86/intel/turbo_max_3.c      |   4 +-
 .../intel/uncore-frequency/uncore-frequency.c |  56 ++---
 drivers/platform/x86/intel_ips.c              |   3 +-
 drivers/platform/x86/intel_scu_wdt.c          |   2 +-
 drivers/platform/x86/p2sb.c                   |   2 +-
 drivers/powercap/intel_rapl_common.c          | 118 +++++-----
 drivers/powercap/intel_rapl_msr.c             |  16 +-
 drivers/thermal/intel/intel_soc_dts_thermal.c |   2 +-
 drivers/thermal/intel/intel_tcc_cooling.c     |  30 +--
 sound/soc/intel/avs/boards/es8336.c           |   7 +-
 tools/power/x86/turbostat/turbostat.c         | 161 +++++++------
 74 files changed, 1258 insertions(+), 1143 deletions(-)


base-commit: 4cece764965020c22cff7665b18a012006359095
-- 
2.44.0