[PATCH v3 00/15] Prepare for new Intel Family numbers

[PATCH v3 00/15] Prepare for new Intel Family numbers

[Sohil Mehta]

---Summary---
Mainstream Intel processors have been using Family 6 for a couple of decades.
This series is an audit of all the arch/x86 Intel Family-model checks to get
ready for the upcoming Family 18 and 19 models. It also converts the last
reamaining Intel x86_model checks to VFM ones.

Patch 1-8 : Include Dave Hansen's Acked-by.
Patch 9-15: Almost ready to merge but don't have review tags yet.

---v3 changes---
* Reordered the patches and moved the Acked ones to the front since they are
  likely to get applied sooner.
* Patches 11 and 14 have a slightly different approach now. 
* Improved commit messages overall.
* Dropped the drivers/ fixes. Will post them separately.

---Previous versions---
Refer the v2 cover letter for more background.

v2: https://lore.kernel.org/lkml/20250211194407.2577252-1-sohil.mehta@intel.com/
RFC-v1: https://lore.kernel.org/lkml/20241220213711.1892696-1-sohil.mehta@intel.com/

Sohil Mehta (15):
  x86/apic: Fix 32-bit APIC initialization for extended Intel Families
  x86/cpu/intel: Fix the movsl alignment preference for extended
    Families
  x86/microcode: Update the Intel processor flag scan check
  x86/mtrr: Modify a x86_model check to an Intel VFM check
  x86/cpu/intel: Replace early Family 6 checks with VFM ones
  x86/cpu/intel: Replace Family 15 checks with VFM ones
  x86/cpu/intel: Replace Family 5 model checks with VFM ones
  x86/acpi/cstate: Improve Intel Family model checks
  x86/smpboot: Remove confusing quirk usage in INIT delay
  x86/smpboot: Fix INIT delay assignment for extended Intel Families
  x86/cpu/intel: Fix fast string initialization for extended Families
  x86/pat: Replace Intel x86_model checks with VFM ones
  x86/cpu/intel: Bound the non-architectural constant_tsc model checks
  perf/x86: Simplify Intel PMU initialization
  perf/x86/p4: Replace Pentium 4 model checks with VFM ones

 arch/x86/events/intel/core.c          | 16 ++++--
 arch/x86/events/intel/p4.c            |  7 +--
 arch/x86/events/intel/p6.c            | 26 ++--------
 arch/x86/include/asm/intel-family.h   | 21 +++++++-
 arch/x86/kernel/acpi/cstate.c         |  8 +--
 arch/x86/kernel/apic/apic.c           |  4 +-
 arch/x86/kernel/cpu/intel.c           | 74 +++++++++++++--------------
 arch/x86/kernel/cpu/microcode/intel.c |  2 +-
 arch/x86/kernel/cpu/mtrr/generic.c    |  4 +-
 arch/x86/kernel/smpboot.c             | 17 +++---
 arch/x86/mm/pat/memtype.c             |  6 +--
 11 files changed, 93 insertions(+), 92 deletions(-)

-- 
2.43.0

[PATCH v3 01/15] x86/apic: Fix 32-bit APIC initialization for extended Intel Families

[Sohil Mehta]

APIC detection is currently limited to a few specific Families and will
not match the upcoming Families >=18.

Extend the check to include all Families 6 or greater. Also convert it
to a VFM check to make it simpler.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: No change
v2: Update commit message to make it more precise
---
 arch/x86/kernel/apic/apic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e893dc6f11c1..4d99bd65faf5 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2014,8 +2014,8 @@ static bool __init detect_init_APIC(void)
 	case X86_VENDOR_HYGON:
 		break;
 	case X86_VENDOR_INTEL:
-		if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
-		    (boot_cpu_data.x86 == 5 && boot_cpu_has(X86_FEATURE_APIC)))
+		if ((boot_cpu_data.x86 == 5 && boot_cpu_has(X86_FEATURE_APIC)) ||
+		    boot_cpu_data.x86_vfm >= INTEL_PENTIUM_PRO)
 			break;
 		goto no_apic;
 	default:
-- 
2.43.0

[PATCH v3 02/15] x86/cpu/intel: Fix the movsl alignment preference for extended Families

[Sohil Mehta]

The alignment preference for 32-bit movsl based bulk memory move has
been 8-byte for a long time. However this preference is only set for
Family 6 and 15 processors.

Use the same preference for upcoming Family numbers 18 and 19. Also, use
a simpler VFM based check instead of switching based on Family numbers.
Refresh the comment to reflect the new check.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack. Improve commit message.
v2: Split the patch into two parts. Update commit message.
---
 arch/x86/kernel/cpu/intel.c | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 3dce22f00dc3..e5f34a90963e 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -449,23 +449,16 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	    (c->x86_stepping < 0x6 || c->x86_stepping == 0xb))
 		set_cpu_bug(c, X86_BUG_11AP);
 
-
 #ifdef CONFIG_X86_INTEL_USERCOPY
 	/*
-	 * Set up the preferred alignment for movsl bulk memory moves
+	 * movsl bulk memory moves can be slow when source and dest are not
+	 * both 8-byte aligned. PII/PIII only like movsl with 8-byte alignment.
+	 *
+	 * Set the preferred alignment for Pentium Pro and newer processors, as
+	 * it has only been tested on these.
 	 */
-	switch (c->x86) {
-	case 4:		/* 486: untested */
-		break;
-	case 5:		/* Old Pentia: untested */
-		break;
-	case 6:		/* PII/PIII only like movsl with 8-byte alignment */
+	if (c->x86_vfm >= INTEL_PENTIUM_PRO)
 		movsl_mask.mask = 7;
-		break;
-	case 15:	/* P4 is OK down to 8-byte alignment */
-		movsl_mask.mask = 7;
-		break;
-	}
 #endif
 
 	intel_smp_check(c);
-- 
2.43.0

[PATCH v3 03/15] x86/microcode: Update the Intel processor flag scan check

[Sohil Mehta]

The Family model check to read the processor flag MSR is misleading and
potentially incorrect. It doesn't consider Family while comparing the
model number. The original check did have a Family number but it got
lost/moved during refactoring.

intel_collect_cpu_info() is called through multiple paths such as early
initialization, CPU hotplug as well as IFS image load. Some of these
flows would be error prone due to the ambiguous check.

Correct the processor flag scan check to use a Family number and update
it to a VFM based one to make it more readable.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack.
v2: Use a VFM check instead of hardcoded numbers.
---
 arch/x86/include/asm/intel-family.h   | 1 +
 arch/x86/kernel/cpu/microcode/intel.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 6d7b04ffc5fd..cccc932d761e 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -46,6 +46,7 @@
 #define INTEL_ANY			IFM(X86_FAMILY_ANY, X86_MODEL_ANY)
 
 #define INTEL_PENTIUM_PRO		IFM(6, 0x01)
+#define INTEL_PENTIUM_III_DESCHUTES	IFM(6, 0x05)
 
 #define INTEL_CORE_YONAH		IFM(6, 0x0E)
 
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index f3d534807d91..819199bc0119 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -74,7 +74,7 @@ void intel_collect_cpu_info(struct cpu_signature *sig)
 	sig->pf = 0;
 	sig->rev = intel_get_microcode_revision();
 
-	if (x86_model(sig->sig) >= 5 || x86_family(sig->sig) > 6) {
+	if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) {
 		unsigned int val[2];
 
 		/* get processor flags from MSR 0x17 */
-- 
2.43.0

[PATCH v3 04/15] x86/mtrr: Modify a x86_model check to an Intel VFM check

[Sohil Mehta]

Simplify one of the last few Intel x86_model checks in arch/x86 by
substituting it with a VFM one.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack.
v2: No change.
---
 arch/x86/kernel/cpu/mtrr/generic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 2fdfda2b60e4..826b8cff33cf 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -12,6 +12,7 @@
 #include <asm/processor-flags.h>
 #include <asm/cacheinfo.h>
 #include <asm/cpufeature.h>
+#include <asm/cpu_device_id.h>
 #include <asm/hypervisor.h>
 #include <asm/mshyperv.h>
 #include <asm/tlbflush.h>
@@ -1025,8 +1026,7 @@ int generic_validate_add_page(unsigned long base, unsigned long size,
 	 * For Intel PPro stepping <= 7
 	 * must be 4 MiB aligned and not touch 0x70000000 -> 0x7003FFFF
 	 */
-	if (mtrr_if == &generic_mtrr_ops && boot_cpu_data.x86 == 6 &&
-	    boot_cpu_data.x86_model == 1 &&
+	if (mtrr_if == &generic_mtrr_ops && boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO &&
 	    boot_cpu_data.x86_stepping <= 7) {
 		if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
 			pr_warn("mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
-- 
2.43.0

[PATCH v3 05/15] x86/cpu/intel: Replace early Family 6 checks with VFM ones

[Sohil Mehta]

Introduce names for some old pentium models and replace the x86_model
checks with VFM ones.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack.
v2: No change
---
 arch/x86/include/asm/intel-family.h |  4 ++++
 arch/x86/kernel/cpu/intel.c         | 11 +++++------
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index cccc932d761e..c1a081585fcb 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -45,8 +45,12 @@
 /* Wildcard match so X86_MATCH_VFM(ANY) works */
 #define INTEL_ANY			IFM(X86_FAMILY_ANY, X86_MODEL_ANY)
 
+/* Family 6 */
 #define INTEL_PENTIUM_PRO		IFM(6, 0x01)
+#define INTEL_PENTIUM_II_KLAMATH	IFM(6, 0x03)
 #define INTEL_PENTIUM_III_DESCHUTES	IFM(6, 0x05)
+#define INTEL_PENTIUM_III_TUALATIN	IFM(6, 0x0B)
+#define INTEL_PENTIUM_M_DOTHAN		IFM(6, 0x0D)
 
 #define INTEL_CORE_YONAH		IFM(6, 0x0E)
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index e5f34a90963e..8e67d1ef4c73 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -195,7 +195,7 @@ void intel_unlock_cpuid_leafs(struct cpuinfo_x86 *c)
 	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
 		return;
 
-	if (c->x86 < 6 || (c->x86 == 6 && c->x86_model < 0xd))
+	if (c->x86_vfm < INTEL_PENTIUM_M_DOTHAN)
 		return;
 
 	/*
@@ -350,9 +350,7 @@ static void bsp_init_intel(struct cpuinfo_x86 *c)
 int ppro_with_ram_bug(void)
 {
 	/* Uses data from early_cpu_detect now */
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-	    boot_cpu_data.x86 == 6 &&
-	    boot_cpu_data.x86_model == 1 &&
+	if (boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO &&
 	    boot_cpu_data.x86_stepping < 8) {
 		pr_info("Pentium Pro with Errata#50 detected. Taking evasive action.\n");
 		return 1;
@@ -413,7 +411,8 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * SEP CPUID bug: Pentium Pro reports SEP but doesn't have it until
 	 * model 3 mask 3
 	 */
-	if ((c->x86<<8 | c->x86_model<<4 | c->x86_stepping) < 0x633)
+	if ((c->x86_vfm == INTEL_PENTIUM_II_KLAMATH && c->x86_stepping < 3) ||
+	    c->x86_vfm < INTEL_PENTIUM_II_KLAMATH)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
@@ -615,7 +614,7 @@ static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size)
 	 * to determine which, so we use a boottime override
 	 * for the 512kb model, and assume 256 otherwise.
 	 */
-	if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
+	if (c->x86_vfm == INTEL_PENTIUM_III_TUALATIN && size == 0)
 		size = 256;
 
 	/*
-- 
2.43.0

[PATCH v3 06/15] x86/cpu/intel: Replace Family 15 checks with VFM ones

[Sohil Mehta]

Introduce names for some old pentium 4 models and replace the x86_model
checks with VFM ones.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack.
v2: No change.
---
 arch/x86/include/asm/intel-family.h | 4 ++++
 arch/x86/kernel/cpu/intel.c         | 6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index c1a081585fcb..f509061b8c7e 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -184,6 +184,10 @@
 /* Family 5 */
 #define INTEL_QUARK_X1000		IFM(5, 0x09) /* Quark X1000 SoC */
 
+/* Family 15 - NetBurst */
+#define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
+#define INTEL_P4_PRESCOTT		IFM(15, 0x03)
+
 /* Family 19 */
 #define INTEL_PANTHERCOVE_X		IFM(19, 0x01) /* Diamond Rapids */
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8e67d1ef4c73..30f3812ba62c 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -256,8 +256,8 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 #endif
 
 	/* CPUID workaround for 0F33/0F34 CPU */
-	if (c->x86 == 0xF && c->x86_model == 0x3
-	    && (c->x86_stepping == 0x3 || c->x86_stepping == 0x4))
+	if (c->x86_vfm == INTEL_P4_PRESCOTT &&
+	    (c->x86_stepping == 0x3 || c->x86_stepping == 0x4))
 		c->x86_phys_bits = 36;
 
 	/*
@@ -430,7 +430,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * P4 Xeon erratum 037 workaround.
 	 * Hardware prefetcher may cause stale data to be loaded into the cache.
 	 */
-	if ((c->x86 == 15) && (c->x86_model == 1) && (c->x86_stepping == 1)) {
+	if (c->x86_vfm == INTEL_P4_WILLAMETTE && c->x86_stepping == 1) {
 		if (msr_set_bit(MSR_IA32_MISC_ENABLE,
 				MSR_IA32_MISC_ENABLE_PREFETCH_DISABLE_BIT) > 0) {
 			pr_info("CPU: C0 stepping P4 Xeon detected.\n");
-- 
2.43.0

[PATCH v3 07/15] x86/cpu/intel: Replace Family 5 model checks with VFM ones

[Sohil Mehta]

Introduce names for some Family 5 models and convert some of the checks
to be VFM based.

Also, to keep the file sorted by family, move Family 5 to the top of the
header file.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Picked up Dave's Ack.
v2: Reorder the Family 5 models to be at the top of the file.
---
 arch/x86/include/asm/intel-family.h |  9 ++++++---
 arch/x86/kernel/cpu/intel.c         | 11 +++++------
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index f509061b8c7e..9e6a13f03f0e 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -45,6 +45,12 @@
 /* Wildcard match so X86_MATCH_VFM(ANY) works */
 #define INTEL_ANY			IFM(X86_FAMILY_ANY, X86_MODEL_ANY)
 
+/* Family 5 */
+#define INTEL_FAM5_START		IFM(5, 0x00) /* Notational marker, also P5 A-step */
+#define INTEL_PENTIUM_75		IFM(5, 0x02) /* P54C */
+#define INTEL_PENTIUM_MMX		IFM(5, 0x04) /* P55C */
+#define INTEL_QUARK_X1000		IFM(5, 0x09) /* Quark X1000 SoC */
+
 /* Family 6 */
 #define INTEL_PENTIUM_PRO		IFM(6, 0x01)
 #define INTEL_PENTIUM_II_KLAMATH	IFM(6, 0x03)
@@ -181,9 +187,6 @@
 #define INTEL_XEON_PHI_KNL		IFM(6, 0x57) /* Knights Landing */
 #define INTEL_XEON_PHI_KNM		IFM(6, 0x85) /* Knights Mill */
 
-/* Family 5 */
-#define INTEL_QUARK_X1000		IFM(5, 0x09) /* Quark X1000 SoC */
-
 /* Family 15 - NetBurst */
 #define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
 #define INTEL_P4_PRESCOTT		IFM(15, 0x03)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 30f3812ba62c..48aad9bcf300 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -367,9 +367,8 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
 	/*
 	 * Mask B, Pentium, but not Pentium MMX
 	 */
-	if (c->x86 == 5 &&
-	    c->x86_stepping >= 1 && c->x86_stepping <= 4 &&
-	    c->x86_model <= 3) {
+	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_PENTIUM_MMX &&
+	    c->x86_stepping >= 1 && c->x86_stepping <= 4) {
 		/*
 		 * Remember we have B step Pentia with bugs
 		 */
@@ -396,7 +395,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * The Quark is also family 5, but does not have the same bug.
 	 */
 	clear_cpu_bug(c, X86_BUG_F00F);
-	if (c->x86 == 5 && c->x86_model < 9) {
+	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
 		static int f00f_workaround_enabled;
 
 		set_cpu_bug(c, X86_BUG_F00F);
@@ -444,7 +443,7 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * integrated APIC (see 11AP erratum in "Pentium Processor
 	 * Specification Update").
 	 */
-	if (boot_cpu_has(X86_FEATURE_APIC) && (c->x86<<8 | c->x86_model<<4) == 0x520 &&
+	if (boot_cpu_has(X86_FEATURE_APIC) && c->x86_vfm == INTEL_PENTIUM_75 &&
 	    (c->x86_stepping < 0x6 || c->x86_stepping == 0xb))
 		set_cpu_bug(c, X86_BUG_11AP);
 
@@ -621,7 +620,7 @@ static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size)
 	 * Intel Quark SoC X1000 contains a 4-way set associative
 	 * 16K cache with a 16 byte cache line and 256 lines per tag
 	 */
-	if ((c->x86 == 5) && (c->x86_model == 9))
+	if (c->x86_vfm == INTEL_QUARK_X1000)
 		size = 16;
 	return size;
 }
-- 
2.43.0

[PATCH v3 08/15] x86/acpi/cstate: Improve Intel Family model checks

[Sohil Mehta]

Update the Intel Family checks to consistently use Family 15 instead of
Family 0xF. Also, get rid of one of last usages of x86_model by using
the new VFM checks.

Update the incorrect comment since the check has changed[1][2] since the
initial commit ee1ca48fae7e ("ACPI: Disable ARB_DISABLE on platforms
where it is not needed").

[1]: commit 3e2ada5867b7 ("ACPI: fix Compaq Evo N800c (Pentium 4m) boot
hang regression") removed the P4 - Family 15.

[2]: commit 03a05ed11529 ("ACPI: Use the ARB_DISABLE for the CPU which
model id is less than 0x0f.") got rid of CORE_YONAH - Family 6, model E.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v3: Pick up Dave's Ack.
v2: Improve commit message.
---
 arch/x86/include/asm/intel-family.h | 3 +++
 arch/x86/kernel/acpi/cstate.c       | 8 ++++----
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 9e6a13f03f0e..deb17c9c21e5 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -187,6 +187,9 @@
 #define INTEL_XEON_PHI_KNL		IFM(6, 0x57) /* Knights Landing */
 #define INTEL_XEON_PHI_KNM		IFM(6, 0x85) /* Knights Mill */
 
+/* Notational marker denoting the last Family 6 model */
+#define INTEL_FAM6_LAST			IFM(6, 0xFF)
+
 /* Family 15 - NetBurst */
 #define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
 #define INTEL_P4_PRESCOTT		IFM(15, 0x03)
diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index 5854f0b8f0f1..444602a0a3dd 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -13,6 +13,7 @@
 #include <linux/sched.h>
 
 #include <acpi/processor.h>
+#include <asm/cpu_device_id.h>
 #include <asm/cpuid.h>
 #include <asm/mwait.h>
 #include <asm/special_insns.h>
@@ -47,12 +48,11 @@ void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
 	/*
 	 * On all recent Intel platforms, ARB_DISABLE is a nop.
 	 * So, set bm_control to zero to indicate that ARB_DISABLE
-	 * is not required while entering C3 type state on
-	 * P4, Core and beyond CPUs
+	 * is not required while entering C3 type state.
 	 */
 	if (c->x86_vendor == X86_VENDOR_INTEL &&
-	    (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
-			flags->bm_control = 0;
+	    (c->x86 > 15 || (c->x86_vfm >= INTEL_CORE2_MEROM && c->x86_vfm <= INTEL_FAM6_LAST)))
+		flags->bm_control = 0;
 
 	if (c->x86_vendor == X86_VENDOR_CENTAUR) {
 		if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
-- 
2.43.0

Re: [PATCH v3 08/15] x86/acpi/cstate: Improve Intel Family model checks

[Rafael J. Wysocki]

On Wed, Feb 19, 2025 at 8:29 PM Sohil Mehta <sohil.mehta@intel.com> wrote:
>
> Update the Intel Family checks to consistently use Family 15 instead of
> Family 0xF. Also, get rid of one of last usages of x86_model by using
> the new VFM checks.
>
> Update the incorrect comment since the check has changed[1][2] since the
> initial commit ee1ca48fae7e ("ACPI: Disable ARB_DISABLE on platforms
> where it is not needed").
>
> [1]: commit 3e2ada5867b7 ("ACPI: fix Compaq Evo N800c (Pentium 4m) boot
> hang regression") removed the P4 - Family 15.
>
> [2]: commit 03a05ed11529 ("ACPI: Use the ARB_DISABLE for the CPU which
> model id is less than 0x0f.") got rid of CORE_YONAH - Family 6, model E.
>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

and I'm assuming that this series will go in via x86.

Thanks!

> ---
> v3: Pick up Dave's Ack.
> v2: Improve commit message.
> ---
>  arch/x86/include/asm/intel-family.h | 3 +++
>  arch/x86/kernel/acpi/cstate.c       | 8 ++++----
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> index 9e6a13f03f0e..deb17c9c21e5 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -187,6 +187,9 @@
>  #define INTEL_XEON_PHI_KNL             IFM(6, 0x57) /* Knights Landing */
>  #define INTEL_XEON_PHI_KNM             IFM(6, 0x85) /* Knights Mill */
>
> +/* Notational marker denoting the last Family 6 model */
> +#define INTEL_FAM6_LAST                        IFM(6, 0xFF)
> +
>  /* Family 15 - NetBurst */
>  #define INTEL_P4_WILLAMETTE            IFM(15, 0x01) /* Also Xeon Foster */
>  #define INTEL_P4_PRESCOTT              IFM(15, 0x03)
> diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
> index 5854f0b8f0f1..444602a0a3dd 100644
> --- a/arch/x86/kernel/acpi/cstate.c
> +++ b/arch/x86/kernel/acpi/cstate.c
> @@ -13,6 +13,7 @@
>  #include <linux/sched.h>
>
>  #include <acpi/processor.h>
> +#include <asm/cpu_device_id.h>
>  #include <asm/cpuid.h>
>  #include <asm/mwait.h>
>  #include <asm/special_insns.h>
> @@ -47,12 +48,11 @@ void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
>         /*
>          * On all recent Intel platforms, ARB_DISABLE is a nop.
>          * So, set bm_control to zero to indicate that ARB_DISABLE
> -        * is not required while entering C3 type state on
> -        * P4, Core and beyond CPUs
> +        * is not required while entering C3 type state.
>          */
>         if (c->x86_vendor == X86_VENDOR_INTEL &&
> -           (c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
> -                       flags->bm_control = 0;
> +           (c->x86 > 15 || (c->x86_vfm >= INTEL_CORE2_MEROM && c->x86_vfm <= INTEL_FAM6_LAST)))
> +               flags->bm_control = 0;
>
>         if (c->x86_vendor == X86_VENDOR_CENTAUR) {
>                 if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
> --
> 2.43.0
>

[PATCH v3 09/15] x86/smpboot: Remove confusing quirk usage in INIT delay

[Sohil Mehta]

Very old multiprocessor systems required a 10 msec delay between
asserting and de-asserting INIT but modern processors do not require
this delay.

Over time the usage of the "quirk" wording while setting the INIT delay
has become misleading. The code comments suggest that modern processors
need to be quirked, which clears the default init_udelay of 10 msec,
while legacy processors don't need the quirk and continue to use the
default init_udelay.

With a lot more modern processors, the wording should be inverted if at
all needed. Instead, simplify the comments and the code by getting rid
of "quirk" usage altogether and clarifying the following:

Old legacy processors -> Set the "legacy" 10 msec delay
Modern processors     -> Do not set any delay

No functional change.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Improve commit message
v2: New patch
---
 arch/x86/kernel/smpboot.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index c10850ae6f09..eb91ed0f2a06 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -654,10 +654,9 @@ static void impress_friends(void)
  * But that slows boot and resume on modern processors, which include
  * many cores and don't require that delay.
  *
- * Cmdline "init_cpu_udelay=" is available to over-ride this delay.
- * Modern processor families are quirked to remove the delay entirely.
+ * Cmdline "cpu_init_udelay=" is available to override this delay.
  */
-#define UDELAY_10MS_DEFAULT 10000
+#define UDELAY_10MS_LEGACY 10000
 
 static unsigned int init_udelay = UINT_MAX;
 
@@ -669,7 +668,7 @@ static int __init cpu_init_udelay(char *str)
 }
 early_param("cpu_init_udelay", cpu_init_udelay);
 
-static void __init smp_quirk_init_udelay(void)
+static void __init smp_set_init_udelay(void)
 {
 	/* if cmdline changed it from default, leave it alone */
 	if (init_udelay != UINT_MAX)
@@ -683,7 +682,7 @@ static void __init smp_quirk_init_udelay(void)
 		return;
 	}
 	/* else, use legacy delay */
-	init_udelay = UDELAY_10MS_DEFAULT;
+	init_udelay = UDELAY_10MS_LEGACY;
 }
 
 /*
@@ -1094,7 +1093,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
 
 	uv_system_init();
 
-	smp_quirk_init_udelay();
+	smp_set_init_udelay();
 
 	speculative_store_bypass_ht_init();
 
-- 
2.43.0

[PATCH v3 10/15] x86/smpboot: Fix INIT delay assignment for extended Intel Families

[Sohil Mehta]

Some old crusty CPUs need an extra delay that slows down booting. See
the comment above 'init_udelay' for details. Newer CPUs don't need the
delay.

Right now, for Intel, Family 6 and only Family 6 skips the delay. That
leaves out both the Family 15 (Pentium 4s) and brand new Family 18/19
models.

The omission of Family 15 (Pentium 4s) seems like an oversight and 18/19
do not need the delay.

Skip the delay on all Intel processors Family 6 and beyond.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Improve commit message
v2: Make the changelog more precise
---
 arch/x86/kernel/smpboot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index eb91ed0f2a06..57e7b6441384 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -675,9 +675,9 @@ static void __init smp_set_init_udelay(void)
 		return;
 
 	/* if modern processor, use no delay */
-	if (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 == 6)) ||
-	    ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) && (boot_cpu_data.x86 >= 0x18)) ||
-	    ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86 >= 0xF))) {
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && boot_cpu_data.x86_vfm >= INTEL_PENTIUM_PRO) ||
+	    (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON && boot_cpu_data.x86 >= 0x18) ||
+	    (boot_cpu_data.x86_vendor == X86_VENDOR_AMD   && boot_cpu_data.x86 >= 0xF)) {
 		init_udelay = 0;
 		return;
 	}
-- 
2.43.0

[PATCH v3 11/15] x86/cpu/intel: Fix fast string initialization for extended Families

[Sohil Mehta]

X86_FEATURE_REP_GOOD is a linux defined feature flag to track whether
fast string operations should be used for copy_page(). It is also used
as a second alternative for clear_page() if enhanced fast string
operations (ERMS) are not available.

X86_FEATURE_ERMS is an Intel-specific hardware-defined feature flag that
tracks hardware support for Enhanced Fast strings.  It is used to track
whether Fast strings should be used for similar memory copy and memory
clearing operations.

On top of these, there is a FAST_STRING enable bit in the
IA32_MISC_ENABLE MSR. It is typically controlled by the BIOS to provide
a hint to the hardware and the OS on whether fast string operations are
preferred.

commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced REP
MOVSB/STOSB") introduced a mechanism to honor the BIOS preference for
fast string operations and clear the above feature flags if needed.
Unfortunately, the current initialization code for Intel to set and
clear these bits is confusing at best and likely incorrect.

X86_FEATURE_REP_GOOD is cleared in early_init_intel() if
MISC_ENABLE.FAST_STRING is 0. But it gets set later on unconditionally
for all Family 6 processors in init_intel(). This not only overrides the
BIOS preference but also contradicts the earlier check.

Fix this by combining the related checks and always relying on the BIOS
provided preference for fast string operations. This simplification
makes sure the upcoming Intel Family 18 and 19 models are covered as
well.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Combine the REP_GOOD checks to one place.
    Improve code comments.

v2: Separate out the REP_GOOD (copy page) specific change into a
    separate commit.
---
 arch/x86/kernel/cpu/intel.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 48aad9bcf300..fc68561d9f92 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -298,12 +298,19 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_PAT);
 
 	/*
-	 * If fast string is not enabled in IA32_MISC_ENABLE for any reason,
-	 * clear the fast string and enhanced fast string CPU capabilities.
+	 * Modern CPUs are generally expected to have a sane fast string
+	 * implementation. However, BIOSes typically have a knob to tweak
+	 * the architectural MISC_ENABLE.FAST_STRING enable bit.
+	 *
+	 * Adhere to the preference and program the linux-defined fast
+	 * string flag and enhanced fast string capabilities accordingly.
 	 */
-	if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
+	if (c->x86_vfm >= INTEL_PENTIUM_M_DOTHAN) {
 		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
-		if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING)) {
+		if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) {
+			/* X86_FEATURE_ERMS is set based on CPUID */
+			set_cpu_cap(c, X86_FEATURE_REP_GOOD);
+		} else {
 			pr_info("Disabled fast string operations\n");
 			setup_clear_cpu_cap(X86_FEATURE_REP_GOOD);
 			setup_clear_cpu_cap(X86_FEATURE_ERMS);
@@ -554,8 +561,6 @@ static void init_intel(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
 	if (c->x86 == 15)
 		c->x86_cache_alignment = c->x86_clflush_size * 2;
-	if (c->x86 == 6)
-		set_cpu_cap(c, X86_FEATURE_REP_GOOD);
 #else
 	/*
 	 * Names for the Pentium II/Celeron processors
-- 
2.43.0

[PATCH v3 12/15] x86/pat: Replace Intel x86_model checks with VFM ones

[Sohil Mehta]

Introduce markers and names for some Family 6 and Family 15 models and
replace x86_model checks with VFM ones.

Since the VFM checks are closed ended and only applicable to Intel, get
rid of the explicit Intel vendor check as well.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Get rid of the Intel vendor check.
v2: Get rid of the INTEL_FAM15_START IFM(15, 0x00) define.
---
 arch/x86/include/asm/intel-family.h | 1 +
 arch/x86/mm/pat/memtype.c           | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index deb17c9c21e5..6621d796bb3d 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -193,6 +193,7 @@
 /* Family 15 - NetBurst */
 #define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
 #define INTEL_P4_PRESCOTT		IFM(15, 0x03)
+#define INTEL_P4_CEDARMILL		IFM(15, 0x06) /* Also Xeon Dempsey */
 
 /* Family 19 */
 #define INTEL_PANTHERCOVE_X		IFM(19, 0x01) /* Diamond Rapids */
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index feb8cc6a12bf..e40861c9cb90 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -43,6 +43,7 @@
 #include <linux/fs.h>
 #include <linux/rbtree.h>
 
+#include <asm/cpu_device_id.h>
 #include <asm/cacheflush.h>
 #include <asm/cacheinfo.h>
 #include <asm/processor.h>
@@ -290,9 +291,8 @@ void __init pat_bp_init(void)
 		return;
 	}
 
-	if ((c->x86_vendor == X86_VENDOR_INTEL) &&
-	    (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
-	     ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
+	if ((c->x86_vfm >= INTEL_PENTIUM_PRO   && c->x86_vfm <= INTEL_PENTIUM_M_DOTHAN) ||
+	    (c->x86_vfm >= INTEL_P4_WILLAMETTE && c->x86_vfm <= INTEL_P4_CEDARMILL)) {
 		/*
 		 * PAT support with the lower four entries. Intel Pentium 2,
 		 * 3, M, and 4 are affected by PAT errata, which makes the
-- 
2.43.0

[PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[Sohil Mehta]

X86_FEATURE_CONSTANT_TSC is a Linux-defined, synthesized feature flag.
It is used across several vendors. Intel CPUs will set the feature when
the architectural CPUID.80000007.EDX[1] bit is set. There are also some
Intel CPUs that have the X86_FEATURE_CONSTANT_TSC behavior but don't
enumerate it with the architectural bit.  Those currently have a model
range check.

Today, virtually all of the CPUs that have the CPUID bit *also* match
the "model >= 0x0e" check. This is confusing. Instead of an open-ended
check, pick some models (INTEL_IVYBRIDGE and P4_WILLAMETTE) as the end
of goofy CPUs that should enumerate the bit but don't.  These models are
relatively arbitrary but conservative pick for this.

This makes it obvious that later CPUs (like Family 18+) no longer need
to synthesize X86_FEATURE_CONSTANT_TSC.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Make the non-architectural model checks more explicit.
    Improve commit message.

v2: No change.
---
 arch/x86/kernel/cpu/intel.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fc68561d9f92..4fbc5465ca67 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -210,10 +210,6 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 {
 	u64 misc_enable;
 
-	if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
-		(c->x86 == 0x6 && c->x86_model >= 0x0e))
-		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
-
 	if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64))
 		c->microcode = intel_get_microcode_revision();
 
@@ -266,10 +262,16 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 	 *
 	 * It is also reliable across cores and sockets. (but not across
 	 * cabinets - we turn it off in that case explicitly.)
+	 *
+	 * Use a model-specific check for some older CPUs that have invariant
+	 * TSC but may not report it architecturally via 8000_0007.
 	 */
 	if (c->x86_power & (1 << 8)) {
 		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
 		set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
+	} else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) ||
+		   (c->x86_vfm >= INTEL_CORE_YONAH  && c->x86_vfm <= INTEL_IVYBRIDGE)) {
+		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
 	}
 
 	/* Penwell and Cloverview have the TSC which doesn't sleep on S3 */
-- 
2.43.0

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3876 bytes --]

On Wed, 2025-02-19 at 18:41 +0000, Sohil Mehta wrote:
> X86_FEATURE_CONSTANT_TSC is a Linux-defined, synthesized feature flag.
> It is used across several vendors. Intel CPUs will set the feature when
> the architectural CPUID.80000007.EDX[1] bit is set. There are also some
> Intel CPUs that have the X86_FEATURE_CONSTANT_TSC behavior but don't
> enumerate it with the architectural bit.  Those currently have a model
> range check.
> 
> Today, virtually all of the CPUs that have the CPUID bit *also* match
> the "model >= 0x0e" check. This is confusing. Instead of an open-ended
> check, pick some models (INTEL_IVYBRIDGE and P4_WILLAMETTE) as the end
> of goofy CPUs that should enumerate the bit but don't.  These models are
> relatively arbitrary but conservative pick for this.
> 
> This makes it obvious that later CPUs (like Family 18+) no longer need
> to synthesize X86_FEATURE_CONSTANT_TSC.
> 
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> v3: Make the non-architectural model checks more explicit.
>     Improve commit message.
> 
> v2: No change.
> ---
>  arch/x86/kernel/cpu/intel.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index fc68561d9f92..4fbc5465ca67 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -210,10 +210,6 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>  {
>  	u64 misc_enable;
>  
> -	if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> -		(c->x86 == 0x6 && c->x86_model >= 0x0e))
> -		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
> -
>  	if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64))
>  		c->microcode = intel_get_microcode_revision();
>  
> @@ -266,10 +262,16 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>  	 *
>  	 * It is also reliable across cores and sockets. (but not across
>  	 * cabinets - we turn it off in that case explicitly.)
> +	 *
> +	 * Use a model-specific check for some older CPUs that have invariant
> +	 * TSC but may not report it architecturally via 8000_0007.
>  	 */
>  	if (c->x86_power & (1 << 8)) {
>  		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
>  		set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
> +	} else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) ||
> +		   (c->x86_vfm >= INTEL_CORE_YONAH  && c->x86_vfm <= INTEL_IVYBRIDGE)) {
> +		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
>  	}
>  
>  	/* Penwell and Cloverview have the TSC which doesn't sleep on S3 */

Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
explicitly append ',+invtsc' to the existing '-cpu host' on its command
line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.

For reasons I also don't understand, for a Xen (in qemu/kvm) guest this
results in about a four-second delay when bringing up each vCPU.
Timestamps added to QEMU's stdout because the kernel's own timestamps
are lying...

1755781767: [    0.489434] smp: Bringing up secondary CPUs ...
1755781767: [    0.489434] installing Xen timer for CPU 1
1755781767: [    0.489434] smpboot: x86: Booting SMP configuration:
1755781767: [    0.489434] .... node  #0, CPUs:          #1
1755781767: [    0.489434] installing Xen timer for CPU 2
1755781767: [    0.489434]    #2
1755781767: [    0.489434] installing Xen timer for CPU 3
1755781767: [    0.489434]    #3
1755781771: [    0.489434] cpu 1 spinlock event irq 45
1755781775: [    0.544262] cpu 2 spinlock event irq 46
1755781779: [    0.604306] cpu 3 spinlock event irq 47
1755781779: [    0.604792] smp: Brought up 1 node, 4 CPUs
1755781779: [    0.604792] smpboot: Total of 4 processors activated (1034118.38 BogoMIPS)




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[Sohil Mehta]

On 8/21/2025 6:15 AM, David Woodhouse wrote:

> Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
> unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
> explicitly append ',+invtsc' to the existing '-cpu host' on its command
> line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.
> 

Haswell should have X86_FEATURE_CONSTANT_TSC, so I would have expected
the guest bit to be set. Until now, X86_FEATURE_CONSTANT_TSC was set
based on the Family-model instead of the CPUID enumeration which may
have hid the issue.

From my initial look at the QEMU implementation, this seems intentional.

QEMU considers Invariant TSC as un-migratable which prevents it from
being exposed to migratable guests (default).
target/i386/cpu.c:
[FEAT_8000_0007_EDX]
         .unmigratable_flags = CPUID_APM_INVTSC,

Can you please try '-cpu host,migratable=off'?

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[Sohil Mehta]

On 8/21/2025 12:34 PM, Sohil Mehta wrote:
> On 8/21/2025 6:15 AM, David Woodhouse wrote:
> 
>> Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
>> unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
>> explicitly append ',+invtsc' to the existing '-cpu host' on its command
>> line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.
>>
> 
> Haswell should have X86_FEATURE_CONSTANT_TSC, so I would have expected
> the guest bit to be set. Until now, X86_FEATURE_CONSTANT_TSC was set
> based on the Family-model instead of the CPUID enumeration which may
> have hid the issue.
> 

Correction:
s/instead/as well as

> From my initial look at the QEMU implementation, this seems intentional.
> 
> QEMU considers Invariant TSC as un-migratable which prevents it from
> being exposed to migratable guests (default).
> target/i386/cpu.c:
> [FEAT_8000_0007_EDX]
>          .unmigratable_flags = CPUID_APM_INVTSC,
> 
> Can you please try '-cpu host,migratable=off'?

This is mainly to verify. If confirmed, I am not sure what the long term
solution should be.

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

On Thu, 2025-08-21 at 12:43 -0700, Sohil Mehta wrote:
> On 8/21/2025 12:34 PM, Sohil Mehta wrote:
> > On 8/21/2025 6:15 AM, David Woodhouse wrote:
> > 
> > > Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
> > > unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
> > > explicitly append ',+invtsc' to the existing '-cpu host' on its command
> > > line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.
> > > 
> > 
> > Haswell should have X86_FEATURE_CONSTANT_TSC, so I would have expected
> > the guest bit to be set. Until now, X86_FEATURE_CONSTANT_TSC was set
> > based on the Family-model instead of the CPUID enumeration which may
> > have hid the issue.
> > 
> 
> Correction:
> s/instead/as well as
> 
> > From my initial look at the QEMU implementation, this seems intentional.
> > 
> > QEMU considers Invariant TSC as un-migratable which prevents it from
> > being exposed to migratable guests (default).
> > target/i386/cpu.c:
> > [FEAT_8000_0007_EDX]
> >          .unmigratable_flags = CPUID_APM_INVTSC,
> > 
> > Can you please try '-cpu host,migratable=off'?
> 
> This is mainly to verify. If confirmed, I am not sure what the long term
> solution should be.

Yes, explicitly turning it on with -cpu host,+invtsc does work.

I've been looking into why it takes a Xen guest four seconds per vCPU
in this case, but not a KVM guest.

When running as a KVM guest, Linux will infer the TSC frequency from
the KVM clock — or better still, from CPUID; see
https://lore.kernel.org/all/20250816101308.2594298-1-dwmw2@infradead.org
and/or
https://lore.kernel.org/all/20250227021855.3257188-36-seanjc@google.com

As a Xen guest though, Linux doesn't do that. This patch in the guest
should make it work without recalibrating the TSC for each vCPU...

--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -489,7 +489,15 @@ static void xen_setup_vsyscall_time_info(void)
  */
 static int __init xen_tsc_safe_clocksource(void)
 {
-       u32 eax, ebx, ecx, edx;
+       u32 eax, ebx, ecx, edx;
+       u64 lpj;
+
+       /* Leaf 4, sub-leaf 0 (0x40000x03) */
+       cpuid_count(xen_cpuid_base() + 3, 0, &eax, &ebx, &ecx, &edx);
+
+       lpj = ((u64)ecx * 1000);
+       do_div(lpj, HZ);
+       preset_lpj = lpj;
 
        if (!(boot_cpu_has(X86_FEATURE_CONSTANT_TSC)))
                return 0;
@@ -500,9 +508,6 @@ static int __init xen_tsc_safe_clocksource(void)
        if (check_tsc_unstable())
                return 0;
 
-       /* Leaf 4, sub-leaf 0 (0x40000x03) */
-       cpuid_count(xen_cpuid_base() + 3, 0, &eax, &ebx, &ecx, &edx);
-
        return ebx == XEN_CPUID_TSC_MODE_NEVER_EMULATE;
 }
 

... but then I got slightly distracted by the question of why I was
getting *nonsense* in those values, and why KVM is 'correcting' EAX in
subleaf 2 which is supposed to be the *host* TSC, not ECX in subleaf
zero...

Under the Fedora 6.13.8-200 kernel I'm fairly sure the guest was seeing
values in subleaf 0 ECX/EDX that *should* have been in subleaf 1
ECX/EDX, and that problem went away when I rebooted the host into a
mainline kernel. Will have to go back and retest that part...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[Xiaoyao Li]

On 8/22/2025 3:43 AM, Sohil Mehta wrote:
> On 8/21/2025 12:34 PM, Sohil Mehta wrote:
>> On 8/21/2025 6:15 AM, David Woodhouse wrote:
>>
>>> Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
>>> unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
>>> explicitly append ',+invtsc' to the existing '-cpu host' on its command
>>> line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.
>>>
>>
>> Haswell should have X86_FEATURE_CONSTANT_TSC, so I would have expected
>> the guest bit to be set. Until now, X86_FEATURE_CONSTANT_TSC was set
>> based on the Family-model instead of the CPUID enumeration which may
>> have hid the issue.
>>
> 
> Correction:
> s/instead/as well as
> 
>>  From my initial look at the QEMU implementation, this seems intentional.
>>
>> QEMU considers Invariant TSC as un-migratable which prevents it from
>> being exposed to migratable guests (default).
>> target/i386/cpu.c:
>> [FEAT_8000_0007_EDX]
>>           .unmigratable_flags = CPUID_APM_INVTSC,
>>
>> Can you please try '-cpu host,migratable=off'?
> 
> This is mainly to verify. If confirmed, I am not sure what the long term
> solution should be.

yeah. It's the intentional behavior of QEMU.

Invariant TSC is ummigratable unless users explicitly configures the TSC 
frequency, e.g., "-cpu host,tsc-frequency=xxx". Because the TSC 
frequency is by default the host's frequency if no "tsc-frequency" 
specified, and it will change when the VM is migrated to a host with a 
different TSC frequency.

It's the specific behavior/rule of QEMU. We just need to keep it in 
mind. If we want to expose invariant TSC to the guest with QEMU's "-cpu 
host", we can either:
1) explicitly configure the "tsc-frequency", or
2) explicitly turn off "migratable"

Re: [PATCH v3 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc model checks

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2025 bytes --]

On 8/21/25 21:46, Xiaoyao Li wrote:
> On 8/22/2025 3:43 AM, Sohil Mehta wrote:
>> On 8/21/2025 12:34 PM, Sohil Mehta wrote:
>>> On 8/21/2025 6:15 AM, David Woodhouse wrote:
>>>
>>>> Hm. My test host is INTEL_HASWELL_X (0x63f). For reasons which are
>>>> unclear to me, QEMU doesn't set bit 8 of 0x80000007 EDX unless I
>>>> explicitly append ',+invtsc' to the existing '-cpu host' on its command
>>>> line. So now my guest doesn't think it has X86_FEATURE_CONSTANT_TSC.
>>>>
>>>
>>> Haswell should have X86_FEATURE_CONSTANT_TSC, so I would have expected
>>> the guest bit to be set. Until now, X86_FEATURE_CONSTANT_TSC was set
>>> based on the Family-model instead of the CPUID enumeration which may
>>> have hid the issue.
>>>
>>
>> Correction:
>> s/instead/as well as
>>
>>>  From my initial look at the QEMU implementation, this seems intentional.
>>>
>>> QEMU considers Invariant TSC as un-migratable which prevents it from
>>> being exposed to migratable guests (default).
>>> target/i386/cpu.c:
>>> [FEAT_8000_0007_EDX]
>>>           .unmigratable_flags = CPUID_APM_INVTSC,
>>>
>>> Can you please try '-cpu host,migratable=off'?
>>
>> This is mainly to verify. If confirmed, I am not sure what the long term
>> solution should be.
> 
> yeah. It's the intentional behavior of QEMU.
> 
> Invariant TSC is ummigratable unless users explicitly configures the TSC 
> frequency, e.g., "-cpu host,tsc-frequency=xxx". Because the TSC 
> frequency is by default the host's frequency if no "tsc-frequency" 
> specified, and it will change when the VM is migrated to a host with a 
> different TSC frequency.
> 
> It's the specific behavior/rule of QEMU. We just need to keep it in 
> mind. If we want to expose invariant TSC to the guest with QEMU's "-cpu 
> host", we can either:
> 1) explicitly configure the "tsc-frequency", or
> 2) explicitly turn off "migratable"

Could the TSC frequency be included in the migration stream?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v3 14/15] perf/x86: Simplify Intel PMU initialization

[Sohil Mehta]

Architectural Perfmon was introduced on the Family 6 "Core" processors
starting with Yonah. Processors before Yonah need their own customized
PMU initialization.

p6_pmu_init() is expected to provide that initialization for early
Family 6 processors. But, due to the unrestricted call to p6_pmu_init(),
it could get called for any Family 6 processor if the architectural
perfmon feature is disabled on that processor.

To simplify, restrict the call to p6_pmu_init() to early Family 6
processors that do not have architectural perfmon support. As a result,
the "unsupported" console print becomes practically unreachable because
all the released P6 processors are covered by the switch cases.

Move the console print to a common location where it can cover all
modern processors that do not have architectural perfmon support.

Also, use this opportunity to get rid of the unnecessary switch cases in
p6_pmu_init().  Only the Pentium Pro processor needs a quirk, and the
rest of the processors do not need any special handling. The gaps in the
case numbers are only due to no processor with those model numbers being
released.

Converting to a VFM based check gets rid of one last few Intel x86_model
comparisons.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: Restrict calling p6_pmu_init() to only when needed.
    Move the console print to a common location.

v2: No change.
---
 arch/x86/events/intel/core.c | 16 +++++++++++-----
 arch/x86/events/intel/p6.c   | 26 +++-----------------------
 2 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 7601196d1d18..c645d8c8ab87 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -6466,16 +6466,22 @@ __init int intel_pmu_init(void)
 	char *name;
 	struct x86_hybrid_pmu *pmu;
 
+	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
 	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
 		switch (boot_cpu_data.x86) {
-		case 0x6:
-			return p6_pmu_init();
-		case 0xb:
+		case 6:
+			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
+				return p6_pmu_init();
+			break;
+		case 11:
 			return knc_pmu_init();
-		case 0xf:
+		case 15:
 			return p4_pmu_init();
+		default:
+			pr_cont("unsupported CPU family %d model %d ",
+				boot_cpu_data.x86, boot_cpu_data.x86_model);
+			return -ENODEV;
 		}
-		return -ENODEV;
 	}
 
 	/*
diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c
index a6cffb4f4ef5..65b45e9d7016 100644
--- a/arch/x86/events/intel/p6.c
+++ b/arch/x86/events/intel/p6.c
@@ -2,6 +2,8 @@
 #include <linux/perf_event.h>
 #include <linux/types.h>
 
+#include <asm/cpu_device_id.h>
+
 #include "../perf_event.h"
 
 /*
@@ -248,30 +250,8 @@ __init int p6_pmu_init(void)
 {
 	x86_pmu = p6_pmu;
 
-	switch (boot_cpu_data.x86_model) {
-	case  1: /* Pentium Pro */
+	if (boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO)
 		x86_add_quirk(p6_pmu_rdpmc_quirk);
-		break;
-
-	case  3: /* Pentium II - Klamath */
-	case  5: /* Pentium II - Deschutes */
-	case  6: /* Pentium II - Mendocino */
-		break;
-
-	case  7: /* Pentium III - Katmai */
-	case  8: /* Pentium III - Coppermine */
-	case 10: /* Pentium III Xeon */
-	case 11: /* Pentium III - Tualatin */
-		break;
-
-	case  9: /* Pentium M - Banias */
-	case 13: /* Pentium M - Dothan */
-		break;
-
-	default:
-		pr_cont("unsupported p6 CPU model %d ", boot_cpu_data.x86_model);
-		return -ENODEV;
-	}
 
 	memcpy(hw_cache_event_ids, p6_hw_cache_event_ids,
 		sizeof(hw_cache_event_ids));
-- 
2.43.0

Re: [PATCH v3 14/15] perf/x86: Simplify Intel PMU initialization

[Liang, Kan]

On 2025-02-19 1:41 p.m., Sohil Mehta wrote:
> Architectural Perfmon was introduced on the Family 6 "Core" processors
> starting with Yonah. Processors before Yonah need their own customized
> PMU initialization.
> 
> p6_pmu_init() is expected to provide that initialization for early
> Family 6 processors. But, due to the unrestricted call to p6_pmu_init(),
> it could get called for any Family 6 processor if the architectural
> perfmon feature is disabled on that processor.
> 
> To simplify, restrict the call to p6_pmu_init() to early Family 6
> processors that do not have architectural perfmon support. As a result,
> the "unsupported" console print becomes practically unreachable because
> all the released P6 processors are covered by the switch cases.
> 
> Move the console print to a common location where it can cover all
> modern processors that do not have architectural perfmon support.
> 
> Also, use this opportunity to get rid of the unnecessary switch cases in
> p6_pmu_init().  Only the Pentium Pro processor needs a quirk, and the
> rest of the processors do not need any special handling. The gaps in the
> case numbers are only due to no processor with those model numbers being
> released.
> 
> Converting to a VFM based check gets rid of one last few Intel x86_model
> comparisons.
> 
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> v3: Restrict calling p6_pmu_init() to only when needed.
>     Move the console print to a common location.
> 
> v2: No change.
> ---
>  arch/x86/events/intel/core.c | 16 +++++++++++-----
>  arch/x86/events/intel/p6.c   | 26 +++-----------------------
>  2 files changed, 14 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 7601196d1d18..c645d8c8ab87 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -6466,16 +6466,22 @@ __init int intel_pmu_init(void)
>  	char *name;
>  	struct x86_hybrid_pmu *pmu;
>  
> +	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
>  	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
>  		switch (boot_cpu_data.x86) {
> -		case 0x6:
> -			return p6_pmu_init();
> -		case 0xb:
> +		case 6:
> +			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
> +				return p6_pmu_init();
> +			break;

We may need a return -ENODEV here.

I think it's possible that some weird hypervisor doesn't enumerate the
ARCH_PERFMON for a modern CPU. Perf should not touch the leaf 10 if the
ARCH_PERFMON is not supported.

Thanks,
Kan

> +		case 11:
>  			return knc_pmu_init();
> -		case 0xf:
> +		case 15:
>  			return p4_pmu_init();
> +		default:
> +			pr_cont("unsupported CPU family %d model %d ",
> +				boot_cpu_data.x86, boot_cpu_data.x86_model);
> +			return -ENODEV;
>  		}
> -		return -ENODEV;
>  	}
>  
>  	/*
> diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c
> index a6cffb4f4ef5..65b45e9d7016 100644
> --- a/arch/x86/events/intel/p6.c
> +++ b/arch/x86/events/intel/p6.c
> @@ -2,6 +2,8 @@
>  #include <linux/perf_event.h>
>  #include <linux/types.h>
>  
> +#include <asm/cpu_device_id.h>
> +
>  #include "../perf_event.h"
>  
>  /*
> @@ -248,30 +250,8 @@ __init int p6_pmu_init(void)
>  {
>  	x86_pmu = p6_pmu;
>  
> -	switch (boot_cpu_data.x86_model) {
> -	case  1: /* Pentium Pro */
> +	if (boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO)
>  		x86_add_quirk(p6_pmu_rdpmc_quirk);
> -		break;
> -
> -	case  3: /* Pentium II - Klamath */
> -	case  5: /* Pentium II - Deschutes */
> -	case  6: /* Pentium II - Mendocino */
> -		break;
> -
> -	case  7: /* Pentium III - Katmai */
> -	case  8: /* Pentium III - Coppermine */
> -	case 10: /* Pentium III Xeon */
> -	case 11: /* Pentium III - Tualatin */
> -		break;
> -
> -	case  9: /* Pentium M - Banias */
> -	case 13: /* Pentium M - Dothan */
> -		break;
> -
> -	default:
> -		pr_cont("unsupported p6 CPU model %d ", boot_cpu_data.x86_model);
> -		return -ENODEV;
> -	}
>  
>  	memcpy(hw_cache_event_ids, p6_hw_cache_event_ids,
>  		sizeof(hw_cache_event_ids));

Re: [PATCH v3 14/15] perf/x86: Simplify Intel PMU initialization

[Sohil Mehta]

On 2/19/2025 12:10 PM, Liang, Kan wrote:
> 
> 
> On 2025-02-19 1:41 p.m., Sohil Mehta wrote:
>> Architectural Perfmon was introduced on the Family 6 "Core" processors
>> starting with Yonah. Processors before Yonah need their own customized
>> PMU initialization.
>>
>> p6_pmu_init() is expected to provide that initialization for early
>> Family 6 processors. But, due to the unrestricted call to p6_pmu_init(),
>> it could get called for any Family 6 processor if the architectural
>> perfmon feature is disabled on that processor.
>>
>> To simplify, restrict the call to p6_pmu_init() to early Family 6
>> processors that do not have architectural perfmon support. As a result,
>> the "unsupported" console print becomes practically unreachable because
>> all the released P6 processors are covered by the switch cases.
>>
>> Move the console print to a common location where it can cover all
>> modern processors that do not have architectural perfmon support.
>>
>> Also, use this opportunity to get rid of the unnecessary switch cases in
>> p6_pmu_init().  Only the Pentium Pro processor needs a quirk, and the
>> rest of the processors do not need any special handling. The gaps in the
>> case numbers are only due to no processor with those model numbers being
>> released.
>>
>> Converting to a VFM based check gets rid of one last few Intel x86_model
>> comparisons.
>>
>> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
>> ---
>> v3: Restrict calling p6_pmu_init() to only when needed.
>>     Move the console print to a common location.
>>
>> v2: No change.
>> ---
>>  arch/x86/events/intel/core.c | 16 +++++++++++-----
>>  arch/x86/events/intel/p6.c   | 26 +++-----------------------
>>  2 files changed, 14 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 7601196d1d18..c645d8c8ab87 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -6466,16 +6466,22 @@ __init int intel_pmu_init(void)
>>  	char *name;
>>  	struct x86_hybrid_pmu *pmu;
>>  
>> +	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
>>  	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
>>  		switch (boot_cpu_data.x86) {
>> -		case 0x6:
>> -			return p6_pmu_init();
>> -		case 0xb:
>> +		case 6:
>> +			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
>> +				return p6_pmu_init();
>> +			break;
> 
> We may need a return -ENODEV here.
> 

That makes sense. See below.

> I think it's possible that some weird hypervisor doesn't enumerate the
> ARCH_PERFMON for a modern CPU. Perf should not touch the leaf 10 if the
> ARCH_PERFMON is not supported.
> 
> Thanks,
> Kan
> 
>> +		case 11:
>>  			return knc_pmu_init();
>> -		case 0xf:
>> +		case 15:
>>  			return p4_pmu_init();
>> +		default:
>> +			pr_cont("unsupported CPU family %d model %d ",
>> +				boot_cpu_data.x86, boot_cpu_data.x86_model);
>> +			return -ENODEV;
>>  		}
>> -		return -ENODEV;
>>  	}
>>  


How about moving the default case out of the switch statement as shown?
That would make sure that the unsupported print would also get included
with the -ENODEV.

	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
		switch (boot_cpu_data.x86) {
		case 6:
			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
				return p6_pmu_init();
			break;
		case 11:
			return knc_pmu_init();
		case 15:
			return p4_pmu_init();
		}

		pr_cont("unsupported CPU family %d model %d ",
			boot_cpu_data.x86, boot_cpu_data.x86_model);
		return -ENODEV;
	}

Re: [PATCH v3 14/15] perf/x86: Simplify Intel PMU initialization

[Liang, Kan]

On 2025-02-19 3:31 p.m., Sohil Mehta wrote:
> On 2/19/2025 12:10 PM, Liang, Kan wrote:
>>
>>
>> On 2025-02-19 1:41 p.m., Sohil Mehta wrote:
>>> Architectural Perfmon was introduced on the Family 6 "Core" processors
>>> starting with Yonah. Processors before Yonah need their own customized
>>> PMU initialization.
>>>
>>> p6_pmu_init() is expected to provide that initialization for early
>>> Family 6 processors. But, due to the unrestricted call to p6_pmu_init(),
>>> it could get called for any Family 6 processor if the architectural
>>> perfmon feature is disabled on that processor.
>>>
>>> To simplify, restrict the call to p6_pmu_init() to early Family 6
>>> processors that do not have architectural perfmon support. As a result,
>>> the "unsupported" console print becomes practically unreachable because
>>> all the released P6 processors are covered by the switch cases.
>>>
>>> Move the console print to a common location where it can cover all
>>> modern processors that do not have architectural perfmon support.
>>>
>>> Also, use this opportunity to get rid of the unnecessary switch cases in
>>> p6_pmu_init().  Only the Pentium Pro processor needs a quirk, and the
>>> rest of the processors do not need any special handling. The gaps in the
>>> case numbers are only due to no processor with those model numbers being
>>> released.
>>>
>>> Converting to a VFM based check gets rid of one last few Intel x86_model
>>> comparisons.
>>>
>>> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
>>> ---
>>> v3: Restrict calling p6_pmu_init() to only when needed.
>>>     Move the console print to a common location.
>>>
>>> v2: No change.
>>> ---
>>>  arch/x86/events/intel/core.c | 16 +++++++++++-----
>>>  arch/x86/events/intel/p6.c   | 26 +++-----------------------
>>>  2 files changed, 14 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>>> index 7601196d1d18..c645d8c8ab87 100644
>>> --- a/arch/x86/events/intel/core.c
>>> +++ b/arch/x86/events/intel/core.c
>>> @@ -6466,16 +6466,22 @@ __init int intel_pmu_init(void)
>>>  	char *name;
>>>  	struct x86_hybrid_pmu *pmu;
>>>  
>>> +	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
>>>  	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
>>>  		switch (boot_cpu_data.x86) {
>>> -		case 0x6:
>>> -			return p6_pmu_init();
>>> -		case 0xb:
>>> +		case 6:
>>> +			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
>>> +				return p6_pmu_init();
>>> +			break;
>>
>> We may need a return -ENODEV here.
>>
> 
> That makes sense. See below.
> 
>> I think it's possible that some weird hypervisor doesn't enumerate the
>> ARCH_PERFMON for a modern CPU. Perf should not touch the leaf 10 if the
>> ARCH_PERFMON is not supported.
>>
>> Thanks,
>> Kan
>>
>>> +		case 11:
>>>  			return knc_pmu_init();
>>> -		case 0xf:
>>> +		case 15:
>>>  			return p4_pmu_init();
>>> +		default:
>>> +			pr_cont("unsupported CPU family %d model %d ",
>>> +				boot_cpu_data.x86, boot_cpu_data.x86_model);
>>> +			return -ENODEV;
>>>  		}
>>> -		return -ENODEV;
>>>  	}
>>>  
> 
> 
> How about moving the default case out of the switch statement as shown?
> That would make sure that the unsupported print would also get included
> with the -ENODEV.
> 
> 	/* Architectural Perfmon was introduced starting with INTEL_CORE_YONAH */
> 	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
> 		switch (boot_cpu_data.x86) {
> 		case 6:
> 			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
> 				return p6_pmu_init();
> 			break;
> 		case 11:
> 			return knc_pmu_init();
> 		case 15:
> 			return p4_pmu_init();
> 		}
> 
> 		pr_cont("unsupported CPU family %d model %d ",
> 			boot_cpu_data.x86, boot_cpu_data.x86_model);
> 		return -ENODEV;
> 	}

It looks good to me.

With the above change,

Reviewed-by: Kan Liang <kan.liang@linux.intel.com>

Thanks,
Kan

[PATCH v3.1 14/15] perf/x86: Simplify Intel PMU initialization

[Sohil Mehta]

Architectural Perfmon was introduced on the Family 6 "Core" processors
starting with Yonah. Processors before Yonah need their own customized
PMU initialization.

p6_pmu_init() is expected to provide that initialization for early
Family 6 processors. But, currently, it could get called for any Family
6 processor if the architectural perfmon feature is disabled on that
processor. To simplify, restrict the P6 PMU initialization to early
Family 6 processors that do not have architectural perfmon support and
truly need the special handling.

As a result, the "unsupported" console print becomes practically
unreachable because all the released P6 processors are covered by the
switch cases. Move the console print to a common location where it can
cover all modern processors (including Family >15) that may not have
architectural perfmon support enumerated.

Also, use this opportunity to get rid of the unnecessary switch cases in
P6 initialization. Only the Pentium Pro processor needs a quirk, and the
rest of the processors do not need any special handling. The gaps in the
case numbers are only due to no processor with those model numbers being
released.

Use decimal numbers for Intel Family numbers. Also, convert one of the
last few Intel x86_model comparison to a VFM based one.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
---
Sending an updated version for this one since it's the only one with a
change. This would make it feasible to pickup the entire patchset in
this cycle if desired.

v3.1: Move the default case outside of the switch.
      Pickup the Reviewed-by tag from Kan Liang.

v3: Restrict calling p6_pmu_init() to only when needed.
    Move the console print to a common location.

v2: No change.
---
 arch/x86/events/intel/core.c | 14 ++++++++++----
 arch/x86/events/intel/p6.c   | 26 +++-----------------------
 2 files changed, 13 insertions(+), 27 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 7601196d1d18..ef59643a9d23 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -6466,15 +6466,21 @@ __init int intel_pmu_init(void)
 	char *name;
 	struct x86_hybrid_pmu *pmu;
 
+	/* Architectural Perfmon was introduced starting with Core "Yonah" */
 	if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
 		switch (boot_cpu_data.x86) {
-		case 0x6:
-			return p6_pmu_init();
-		case 0xb:
+		case 6:
+			if (boot_cpu_data.x86_vfm < INTEL_CORE_YONAH)
+				return p6_pmu_init();
+			break;
+		case 11:
 			return knc_pmu_init();
-		case 0xf:
+		case 15:
 			return p4_pmu_init();
 		}
+
+		pr_cont("unsupported CPU family %d model %d ",
+			boot_cpu_data.x86, boot_cpu_data.x86_model);
 		return -ENODEV;
 	}
 
diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c
index a6cffb4f4ef5..65b45e9d7016 100644
--- a/arch/x86/events/intel/p6.c
+++ b/arch/x86/events/intel/p6.c
@@ -2,6 +2,8 @@
 #include <linux/perf_event.h>
 #include <linux/types.h>
 
+#include <asm/cpu_device_id.h>
+
 #include "../perf_event.h"
 
 /*
@@ -248,30 +250,8 @@ __init int p6_pmu_init(void)
 {
 	x86_pmu = p6_pmu;
 
-	switch (boot_cpu_data.x86_model) {
-	case  1: /* Pentium Pro */
+	if (boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO)
 		x86_add_quirk(p6_pmu_rdpmc_quirk);
-		break;
-
-	case  3: /* Pentium II - Klamath */
-	case  5: /* Pentium II - Deschutes */
-	case  6: /* Pentium II - Mendocino */
-		break;
-
-	case  7: /* Pentium III - Katmai */
-	case  8: /* Pentium III - Coppermine */
-	case 10: /* Pentium III Xeon */
-	case 11: /* Pentium III - Tualatin */
-		break;
-
-	case  9: /* Pentium M - Banias */
-	case 13: /* Pentium M - Dothan */
-		break;
-
-	default:
-		pr_cont("unsupported p6 CPU model %d ", boot_cpu_data.x86_model);
-		return -ENODEV;
-	}
 
 	memcpy(hw_cache_event_ids, p6_hw_cache_event_ids,
 		sizeof(hw_cache_event_ids));
-- 
2.43.0

[PATCH v3 15/15] perf/x86/p4: Replace Pentium 4 model checks with VFM ones

[Sohil Mehta]

Introduce names for some old pentium 4 models and replace x86_model
checks with VFM ones.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v3: No change.
v2: No change.
---
 arch/x86/events/intel/p4.c          | 7 ++++---
 arch/x86/include/asm/intel-family.h | 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
index 844bc4fc4724..fb726c6fc6e7 100644
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -10,6 +10,7 @@
 #include <linux/perf_event.h>
 
 #include <asm/perf_event_p4.h>
+#include <asm/cpu_device_id.h>
 #include <asm/hardirq.h>
 #include <asm/apic.h>
 
@@ -732,9 +733,9 @@ static bool p4_event_match_cpu_model(unsigned int event_idx)
 {
 	/* INSTR_COMPLETED event only exist for model 3, 4, 6 (Prescott) */
 	if (event_idx == P4_EVENT_INSTR_COMPLETED) {
-		if (boot_cpu_data.x86_model != 3 &&
-			boot_cpu_data.x86_model != 4 &&
-			boot_cpu_data.x86_model != 6)
+		if (boot_cpu_data.x86_vfm != INTEL_P4_PRESCOTT &&
+		    boot_cpu_data.x86_vfm != INTEL_P4_PRESCOTT_2M &&
+		    boot_cpu_data.x86_vfm != INTEL_P4_CEDARMILL)
 			return false;
 	}
 
diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index 6621d796bb3d..89cb545d521b 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -193,6 +193,7 @@
 /* Family 15 - NetBurst */
 #define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
 #define INTEL_P4_PRESCOTT		IFM(15, 0x03)
+#define INTEL_P4_PRESCOTT_2M		IFM(15, 0x04)
 #define INTEL_P4_CEDARMILL		IFM(15, 0x06) /* Also Xeon Dempsey */
 
 /* Family 19 */
-- 
2.43.0

Re: [PATCH v3 15/15] perf/x86/p4: Replace Pentium 4 model checks with VFM ones

[Liang, Kan]

On 2025-02-19 1:41 p.m., Sohil Mehta wrote:
> Introduce names for some old pentium 4 models and replace x86_model
> checks with VFM ones.
> 
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>


Reviewed-by: Kan Liang <kan.liang@linux.intel.com>

Thanks,
Kan

> ---
> v3: No change.
> v2: No change.
> ---
>  arch/x86/events/intel/p4.c          | 7 ++++---
>  arch/x86/include/asm/intel-family.h | 1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
> index 844bc4fc4724..fb726c6fc6e7 100644
> --- a/arch/x86/events/intel/p4.c
> +++ b/arch/x86/events/intel/p4.c
> @@ -10,6 +10,7 @@
>  #include <linux/perf_event.h>
>  
>  #include <asm/perf_event_p4.h>
> +#include <asm/cpu_device_id.h>
>  #include <asm/hardirq.h>
>  #include <asm/apic.h>
>  
> @@ -732,9 +733,9 @@ static bool p4_event_match_cpu_model(unsigned int event_idx)
>  {
>  	/* INSTR_COMPLETED event only exist for model 3, 4, 6 (Prescott) */
>  	if (event_idx == P4_EVENT_INSTR_COMPLETED) {
> -		if (boot_cpu_data.x86_model != 3 &&
> -			boot_cpu_data.x86_model != 4 &&
> -			boot_cpu_data.x86_model != 6)
> +		if (boot_cpu_data.x86_vfm != INTEL_P4_PRESCOTT &&
> +		    boot_cpu_data.x86_vfm != INTEL_P4_PRESCOTT_2M &&
> +		    boot_cpu_data.x86_vfm != INTEL_P4_CEDARMILL)
>  			return false;
>  	}
>  
> diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
> index 6621d796bb3d..89cb545d521b 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -193,6 +193,7 @@
>  /* Family 15 - NetBurst */
>  #define INTEL_P4_WILLAMETTE		IFM(15, 0x01) /* Also Xeon Foster */
>  #define INTEL_P4_PRESCOTT		IFM(15, 0x03)
> +#define INTEL_P4_PRESCOTT_2M		IFM(15, 0x04)
>  #define INTEL_P4_CEDARMILL		IFM(15, 0x06) /* Also Xeon Dempsey */
>  
>  /* Family 19 */

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Sohil Mehta]

On 2/19/2025 10:41 AM, Sohil Mehta wrote:
> ---Summary---
> Mainstream Intel processors have been using Family 6 for a couple of decades.
> This series is an audit of all the arch/x86 Intel Family-model checks to get
> ready for the upcoming Family 18 and 19 models. It also converts the last
> reamaining Intel x86_model checks to VFM ones.
> 
> Patch 1-8 : Include Dave Hansen's Acked-by.
> Patch 9-15: Almost ready to merge but don't have review tags yet.
> 

Is there any additional feedback?

Most patches have review tags now or are simple enough that they might
not need one. Patch 11 can probably use another look.

Patch 14 is the only one that has a minor change. Seeking additional
input before spinning another revision.

> ---v3 changes---
> * Reordered the patches and moved the Acked ones to the front since they are
>   likely to get applied sooner.
> * Patches 11 and 14 have a slightly different approach now. 
> * Improved commit messages overall.
> * Dropped the drivers/ fixes. Will post them separately.
> 
> ---Previous versions---
> Refer the v2 cover letter for more background.
> 
> v2: https://lore.kernel.org/lkml/20250211194407.2577252-1-sohil.mehta@intel.com/
> RFC-v1: https://lore.kernel.org/lkml/20241220213711.1892696-1-sohil.mehta@intel.com/
> 
> Sohil Mehta (15):
>   x86/apic: Fix 32-bit APIC initialization for extended Intel Families
>   x86/cpu/intel: Fix the movsl alignment preference for extended
>     Families
>   x86/microcode: Update the Intel processor flag scan check
>   x86/mtrr: Modify a x86_model check to an Intel VFM check
>   x86/cpu/intel: Replace early Family 6 checks with VFM ones
>   x86/cpu/intel: Replace Family 15 checks with VFM ones
>   x86/cpu/intel: Replace Family 5 model checks with VFM ones
>   x86/acpi/cstate: Improve Intel Family model checks
>   x86/smpboot: Remove confusing quirk usage in INIT delay
>   x86/smpboot: Fix INIT delay assignment for extended Intel Families
>   x86/cpu/intel: Fix fast string initialization for extended Families
>   x86/pat: Replace Intel x86_model checks with VFM ones
>   x86/cpu/intel: Bound the non-architectural constant_tsc model checks
>   perf/x86: Simplify Intel PMU initialization
>   perf/x86/p4: Replace Pentium 4 model checks with VFM ones
> 

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Ingo Molnar]

* Sohil Mehta <sohil.mehta@intel.com> wrote:

> On 2/19/2025 10:41 AM, Sohil Mehta wrote:
> > ---Summary---
> > Mainstream Intel processors have been using Family 6 for a couple of decades.
> > This series is an audit of all the arch/x86 Intel Family-model checks to get
> > ready for the upcoming Family 18 and 19 models. It also converts the last
> > reamaining Intel x86_model checks to VFM ones.
> > 
> > Patch 1-8 : Include Dave Hansen's Acked-by.
> > Patch 9-15: Almost ready to merge but don't have review tags yet.
> > 
> 
> Is there any additional feedback?

Looks mostly good to me.

> Most patches have review tags now or are simple enough that they might
> not need one. Patch 11 can probably use another look.

LGTM, but I've extended the Cc: list to make more people aware.

(I did the same for some of the other patches that could use extra eyes.)

> Patch 14 is the only one that has a minor change. Seeking additional
> input before spinning another revision.

I've applied the first 13 patches to tip:x86/cpu to help move this 
along. I fixed a handful of typos, but haven't noticed any functional 
problems so far, so unless there's problems in -next this might be OK
for the merge window. (Famous last words.)

Thanks,

	Ingo

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Sohil Mehta]

On 3/18/2025 11:35 AM, Ingo Molnar wrote:

>> Most patches have review tags now or are simple enough that they might
>> not need one. Patch 11 can probably use another look.
> 
> LGTM, but I've extended the Cc: list to make more people aware.
> 
> (I did the same for some of the other patches that could use extra eyes.)
> 

Appreciate it.

>> Patch 14 is the only one that has a minor change. Seeking additional
>> input before spinning another revision.
> 
> I've applied the first 13 patches to tip:x86/cpu to help move this 
> along. I fixed a handful of typos, but haven't noticed any functional 
> problems so far, so unless there's problems in -next this might be OK
> for the merge window. (Famous last words.)
> 

Many thanks.. Fingers crossed!

-Sohil

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Ingo Molnar]

* Sohil Mehta <sohil.mehta@intel.com> wrote:

> > I've applied the first 13 patches to tip:x86/cpu to help move this 
> > along. I fixed a handful of typos, but haven't noticed any 
> > functional problems so far, so unless there's problems in -next 
> > this might be OK for the merge window. (Famous last words.)
> > 
> 
> Many thanks.. Fingers crossed!

You are welcome, and please send the remaining patches in a day or so, 
on top of tip:x86/cpu.

Thanks,

	Ingo

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Sohil Mehta]

On 3/18/2025 1:13 PM, Ingo Molnar wrote:
> 
> * Sohil Mehta <sohil.mehta@intel.com> wrote:
> 
>>> I've applied the first 13 patches to tip:x86/cpu to help move this 
>>> along. I fixed a handful of typos, but haven't noticed any 
>>> functional problems so far, so unless there's problems in -next 
>>> this might be OK for the merge window. (Famous last words.)
>>>
>>
>> Many thanks.. Fingers crossed!
> 
> You are welcome, and please send the remaining patches in a day or so, 
> on top of tip:x86/cpu.
> 

Sent the v4 series with the couple of leftover patches. When sent, the
patches were based on tip:x86/cpu, but that seems to have been merged
into x86/core. I have verified that patches apply cleanly on updated
tip:x86/core as well.

Sohil

Re: [PATCH v3 00/15] Prepare for new Intel Family numbers

[Ingo Molnar]

* Sohil Mehta <sohil.mehta@intel.com> wrote:

> On 3/18/2025 1:13 PM, Ingo Molnar wrote:
> > 
> > * Sohil Mehta <sohil.mehta@intel.com> wrote:
> > 
> >>> I've applied the first 13 patches to tip:x86/cpu to help move this 
> >>> along. I fixed a handful of typos, but haven't noticed any 
> >>> functional problems so far, so unless there's problems in -next 
> >>> this might be OK for the merge window. (Famous last words.)
> >>>
> >>
> >> Many thanks.. Fingers crossed!
> > 
> > You are welcome, and please send the remaining patches in a day or so, 
> > on top of tip:x86/cpu.
> > 
> 
> Sent the v4 series with the couple of leftover patches. When sent, the
> patches were based on tip:x86/cpu, but that seems to have been merged
> into x86/core.

Correct, we had to back out a broken patch, and a rebase of a number of 
patches, including yours, was the cleanest option. It should be the 
same tree content-wise.

> I have verified that patches apply cleanly on updated tip:x86/core as 
> well.

Thank you!

	Ingo