* [PATCH v6 1/5] x86/cpu: Name CPU matching macro more generically (and shorten)
2025-03-06 7:12 [PATCH v6 0/5] Utilize cpu-type for CPU matching Pawan Gupta
@ 2025-03-06 7:12 ` Pawan Gupta
2025-03-06 7:13 ` [PATCH v6 2/5] x86/cpu: Add cpu_type to struct x86_cpu_id Pawan Gupta
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 7:12 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
To add cpu-type to the existing CPU matching infrastructure, the base macro
X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE need to append _CPU_TYPE. This
makes an already long name longer, and somewhat incomprehensible.
To avoid this, rename the base macro to X86_MATCH_CPU. The macro name
doesn't need to explicitly tell everything that it matches. The arguments
to the macro already hints that.
For consistency, use this base macro to define X86_MATCH_VFM and friends.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/include/asm/cpu_device_id.h | 101 ++++++++++-------------------------
1 file changed, 29 insertions(+), 72 deletions(-)
diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index ba32e0f44cba..bb5acba69bd1 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -57,7 +57,7 @@
#define X86_CPU_ID_FLAG_ENTRY_VALID BIT(0)
/**
- * X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE - Base macro for CPU matching
+ * X86_MATCH_CPU - Base macro for CPU matching
* @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
* The name is expanded to X86_VENDOR_@_vendor
* @_family: The family number or X86_FAMILY_ANY
@@ -74,19 +74,7 @@
* into another macro at the usage site for good reasons, then please
* start this local macro with X86_MATCH to allow easy grepping.
*/
-#define X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
- _steppings, _feature, _data) { \
- .vendor = X86_VENDOR_##_vendor, \
- .family = _family, \
- .model = _model, \
- .steppings = _steppings, \
- .feature = _feature, \
- .flags = X86_CPU_ID_FLAG_ENTRY_VALID, \
- .driver_data = (unsigned long) _data \
-}
-
-#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \
- _steppings, _feature, _data) { \
+#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \
.vendor = _vendor, \
.family = _family, \
.model = _model, \
@@ -106,13 +94,10 @@
* @_data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * The steppings arguments of X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE() is
- * set to wildcards.
*/
-#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \
- X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(vendor, family, model, \
- X86_STEPPING_ANY, feature, data)
+#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \
+ X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \
+ feature, data)
/**
* X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature
@@ -123,13 +108,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
*/
-#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \
- X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, \
- X86_MODEL_ANY, feature, data)
+#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \
+ X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \
+ X86_STEPPING_ANY, feature, data)
/**
* X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature
@@ -139,12 +121,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
*/
-#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \
- X86_MATCH_VENDOR_FAM_FEATURE(vendor, X86_FAMILY_ANY, feature, data)
+#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \
+ X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY, \
+ X86_STEPPING_ANY, feature, data)
/**
* X86_MATCH_FEATURE - Macro for matching a CPU feature
@@ -152,12 +132,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
*/
-#define X86_MATCH_FEATURE(feature, data) \
- X86_MATCH_VENDOR_FEATURE(ANY, feature, data)
+#define X86_MATCH_FEATURE(feature, data) \
+ X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY, \
+ X86_STEPPING_ANY, feature, data)
/**
* X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model
@@ -168,13 +146,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set to wildcards.
*/
-#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \
- X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, \
- X86_FEATURE_ANY, data)
+#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \
+ X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \
+ X86_FEATURE_ANY, data)
/**
* X86_MATCH_VENDOR_FAM - Match vendor and family
@@ -184,12 +159,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is casted to unsigned long internally.
- *
- * All other missing arguments to X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are
- * set of wildcards.
*/
-#define X86_MATCH_VENDOR_FAM(vendor, family, data) \
- X86_MATCH_VENDOR_FAM_MODEL(vendor, family, X86_MODEL_ANY, data)
+#define X86_MATCH_VENDOR_FAM(vendor, family, data) \
+ X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \
+ X86_STEPPING_ANY, X86_FEATURE_ANY, data)
/**
* X86_MATCH_VFM - Match encoded vendor/family/model
@@ -197,15 +170,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is cast to unsigned long internally.
- *
- * Stepping and feature are set to wildcards
*/
-#define X86_MATCH_VFM(vfm, data) \
- X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \
- VFM_VENDOR(vfm), \
- VFM_FAMILY(vfm), \
- VFM_MODEL(vfm), \
- X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+#define X86_MATCH_VFM(vfm, data) \
+ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
+ X86_STEPPING_ANY, X86_FEATURE_ANY, data)
#define __X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins)
/**
@@ -215,16 +183,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is cast to unsigned long internally.
- *
- * feature is set to wildcard
*/
-#define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \
- X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \
- VFM_VENDOR(vfm), \
- VFM_FAMILY(vfm), \
- VFM_MODEL(vfm), \
- __X86_STEPPINGS(min_step, max_step), \
- X86_FEATURE_ANY, data)
+#define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \
+ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
+ __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, data)
/**
* X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
@@ -233,15 +195,10 @@
* @data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
* etc. is cast to unsigned long internally.
- *
- * Steppings is set to wildcard
*/
-#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \
- X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \
- VFM_VENDOR(vfm), \
- VFM_FAMILY(vfm), \
- VFM_MODEL(vfm), \
- X86_STEPPING_ANY, feature, data)
+#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \
+ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
+ X86_STEPPING_ANY, feature, data)
extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
extern bool x86_match_min_microcode_rev(const struct x86_cpu_id *table);
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 2/5] x86/cpu: Add cpu_type to struct x86_cpu_id
2025-03-06 7:12 [PATCH v6 0/5] Utilize cpu-type for CPU matching Pawan Gupta
2025-03-06 7:12 ` [PATCH v6 1/5] x86/cpu: Name CPU matching macro more generically (and shorten) Pawan Gupta
@ 2025-03-06 7:13 ` Pawan Gupta
2025-03-06 7:13 ` [PATCH v6 3/5] x86/cpu: Update x86_match_cpu() to also use cpu-type Pawan Gupta
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 7:13 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
In addition to matching vendor/family/model/feature, for hybrid variants it
is required to also match cpu-type also. For example some CPU
vulnerabilities like RFDS only affects a specific cpu-type.
To be able to also match CPUs based on their type, add a new field cpu_type
to struct x86_cpu_id which is used by the CPU-matching tables. Introduce
X86_CPU_TYPE_ANY for the cases that don't care about the cpu-type.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/include/asm/cpu_device_id.h | 34 ++++++++++++++++++++++++----------
include/linux/mod_devicetable.h | 2 ++
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index bb5acba69bd1..20dd91146e75 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -74,13 +74,14 @@
* into another macro at the usage site for good reasons, then please
* start this local macro with X86_MATCH to allow easy grepping.
*/
-#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \
+#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _cpu_type, _data) { \
.vendor = _vendor, \
.family = _family, \
.model = _model, \
.steppings = _steppings, \
.feature = _feature, \
.flags = X86_CPU_ID_FLAG_ENTRY_VALID, \
+ .cpu_type = _cpu_type, \
.driver_data = (unsigned long) _data \
}
@@ -97,7 +98,7 @@
*/
#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \
X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \
- feature, data)
+ feature, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature
@@ -111,7 +112,7 @@
*/
#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \
X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \
- X86_STEPPING_ANY, feature, data)
+ X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature
@@ -124,7 +125,7 @@
*/
#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \
X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY, \
- X86_STEPPING_ANY, feature, data)
+ X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_FEATURE - Macro for matching a CPU feature
@@ -135,7 +136,7 @@
*/
#define X86_MATCH_FEATURE(feature, data) \
X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY, \
- X86_STEPPING_ANY, feature, data)
+ X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model
@@ -149,7 +150,7 @@
*/
#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \
X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \
- X86_FEATURE_ANY, data)
+ X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VENDOR_FAM - Match vendor and family
@@ -162,7 +163,7 @@
*/
#define X86_MATCH_VENDOR_FAM(vendor, family, data) \
X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \
- X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+ X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VFM - Match encoded vendor/family/model
@@ -173,7 +174,7 @@
*/
#define X86_MATCH_VFM(vfm, data) \
X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
- X86_STEPPING_ANY, X86_FEATURE_ANY, data)
+ X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data)
#define __X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins)
/**
@@ -186,7 +187,8 @@
*/
#define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \
X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
- __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, data)
+ __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, \
+ X86_CPU_TYPE_ANY, data)
/**
* X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature
@@ -198,7 +200,19 @@
*/
#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \
X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
- X86_STEPPING_ANY, feature, data)
+ X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data)
+
+/**
+ * X86_MATCH_VFM_CPU_TYPE - Match encoded vendor/family/model/cpu-type
+ * @vfm: Encoded 8-bits each for vendor, family, model
+ * @cpu_type: CPU type e.g. P-core, E-core on Intel
+ * @data: Driver specific data or NULL. The internal storage
+ * format is unsigned long. The supplied value, pointer
+ * etc. is cast to unsigned long internally.
+ */
+#define X86_MATCH_VFM_CPU_TYPE(vfm, cpu_type, data) \
+ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \
+ X86_STEPPING_ANY, X86_FEATURE_ANY, cpu_type, data)
extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
extern bool x86_match_min_microcode_rev(const struct x86_cpu_id *table);
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index d67614f7b7f1..18e996acb49a 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -692,6 +692,7 @@ struct x86_cpu_id {
__u16 feature; /* bit index */
/* Solely for kernel-internal use: DO NOT EXPORT to userspace! */
__u16 flags;
+ __u8 cpu_type;
kernel_ulong_t driver_data;
};
@@ -703,6 +704,7 @@ struct x86_cpu_id {
#define X86_STEP_MIN 0
#define X86_STEP_MAX 0xf
#define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */
+#define X86_CPU_TYPE_ANY 0
/*
* Generic table type for matching CPU features.
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 3/5] x86/cpu: Update x86_match_cpu() to also use cpu-type
2025-03-06 7:12 [PATCH v6 0/5] Utilize cpu-type for CPU matching Pawan Gupta
2025-03-06 7:12 ` [PATCH v6 1/5] x86/cpu: Name CPU matching macro more generically (and shorten) Pawan Gupta
2025-03-06 7:13 ` [PATCH v6 2/5] x86/cpu: Add cpu_type to struct x86_cpu_id Pawan Gupta
@ 2025-03-06 7:13 ` Pawan Gupta
2025-03-06 7:13 ` [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list Pawan Gupta
2025-03-06 7:13 ` [PATCH v6 5/5] x86/rfds: Exclude P-only parts from the RFDS affected list Pawan Gupta
4 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 7:13 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
Non-hybrid CPU variants that share the same Family/Model could be
differentiated by their cpu-type. x86_match_cpu() currently does not use
cpu-type for CPU matching.
Dave Hansen suggested to use below conditions to match CPU-type:
1. If CPU_TYPE_ANY (the wildcard), then matched
2. If hybrid, then matched
3. If !hybrid, look at the boot CPU and compare the cpu-type to determine
if it is a match.
This special case for hybrid systems allows more compact vulnerability
list. Imagine that "Haswell" CPUs might or might not be hybrid and that
only Atom cores are vulnerable to Meltdown. That means there are three
possibilities:
1. P-core only
2. Atom only
3. Atom + P-core (aka. hybrid)
One might be tempted to code up the vulnerability list like this:
MATCH( HASWELL, X86_FEATURE_HYBRID, MELTDOWN)
MATCH_TYPE(HASWELL, ATOM, MELTDOWN)
Logically, this matches #2 and #3. But that's a little silly. You would
only ask for the "ATOM" match in cases where there *WERE* hybrid cores in
play. You shouldn't have to _also_ ask for hybrid cores explicitly.
In short, assume that processors that enumerate Hybrid==1 have a
vulnerable core type.
Update x86_match_cpu() to also match cpu-type. Also treat hybrid systems as
special, and match them to any cpu-type.
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/kernel/cpu/match.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
index 4f3c65429f82..4b052860b774 100644
--- a/arch/x86/kernel/cpu/match.c
+++ b/arch/x86/kernel/cpu/match.c
@@ -5,6 +5,34 @@
#include <linux/export.h>
#include <linux/slab.h>
+/**
+ * x86_match_vendor_cpu_type - helper function to match the hardware defined
+ * cpu-type for a single entry in the x86_cpu_id
+ * table. Note, this function does not match the
+ * generic cpu-types TOPO_CPU_TYPE_EFFICIENCY and
+ * TOPO_CPU_TYPE_PERFORMANCE.
+ * @c: Pointer to the cpuinfo_x86 structure of the CPU to match.
+ * @m: Pointer to the x86_cpu_id entry to match against.
+ *
+ * Return: true if the cpu-type matches, false otherwise.
+ */
+static bool x86_match_vendor_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m)
+{
+ if (m->cpu_type == X86_CPU_TYPE_ANY)
+ return true;
+
+ /* Hybrid CPUs are special, they are assumed to match all cpu-types */
+ if (boot_cpu_has(X86_FEATURE_HYBRID_CPU))
+ return true;
+
+ if (c->x86_vendor == X86_VENDOR_INTEL)
+ return m->cpu_type == c->topo.intel_type;
+ if (c->x86_vendor == X86_VENDOR_AMD)
+ return m->cpu_type == c->topo.amd_type;
+
+ return false;
+}
+
/**
* x86_match_cpu - match current CPU against an array of x86_cpu_ids
* @match: Pointer to array of x86_cpu_ids. Last entry terminated with
@@ -50,6 +78,8 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
continue;
if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
continue;
+ if (!x86_match_vendor_cpu_type(c, m))
+ continue;
return m;
}
return NULL;
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list
2025-03-06 7:12 [PATCH v6 0/5] Utilize cpu-type for CPU matching Pawan Gupta
` (2 preceding siblings ...)
2025-03-06 7:13 ` [PATCH v6 3/5] x86/cpu: Update x86_match_cpu() to also use cpu-type Pawan Gupta
@ 2025-03-06 7:13 ` Pawan Gupta
2025-03-06 15:18 ` Dave Hansen
2025-03-06 7:13 ` [PATCH v6 5/5] x86/rfds: Exclude P-only parts from the RFDS affected list Pawan Gupta
4 siblings, 1 reply; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 7:13 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
The affected processor table has a lot of repetition and redundant
information that can be omitted for brevity. Like:
VULNBL_INTEL_STEPS(INTEL_IVYBRIDGE, X86_STEP_MAX, SRBDS),
can easily be simplified to:
VULNBL_INTEL(IVYBRIDGE, SRBDS),
Apply this to all the entries in the affected processor table.
No functional change.
Disassembly of cpu_vuln_blacklist:
objdump -j .init.data --disassemble=cpu_vuln_blacklist vmlinux
doesn't show any difference before and after the change.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
arch/x86/kernel/cpu/common.c | 143 ++++++++++++++++++++++---------------------
1 file changed, 73 insertions(+), 70 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 5f81c553e733..9d41f8f7267a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1125,7 +1125,7 @@ static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c)
X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, whitelist)
#define VULNWL_INTEL(vfm, whitelist) \
- X86_MATCH_VFM(vfm, whitelist)
+ X86_MATCH_VFM(INTEL_##vfm, whitelist)
#define VULNWL_AMD(family, whitelist) \
VULNWL(AMD, family, X86_MODEL_ANY, whitelist)
@@ -1142,32 +1142,32 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
VULNWL(VORTEX, 6, X86_MODEL_ANY, NO_SPECULATION),
/* Intel Family 6 */
- VULNWL_INTEL(INTEL_TIGERLAKE, NO_MMIO),
- VULNWL_INTEL(INTEL_TIGERLAKE_L, NO_MMIO),
- VULNWL_INTEL(INTEL_ALDERLAKE, NO_MMIO),
- VULNWL_INTEL(INTEL_ALDERLAKE_L, NO_MMIO),
+ VULNWL_INTEL(TIGERLAKE, NO_MMIO),
+ VULNWL_INTEL(TIGERLAKE_L, NO_MMIO),
+ VULNWL_INTEL(ALDERLAKE, NO_MMIO),
+ VULNWL_INTEL(ALDERLAKE_L, NO_MMIO),
- VULNWL_INTEL(INTEL_ATOM_SALTWELL, NO_SPECULATION | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_SALTWELL_TABLET, NO_SPECULATION | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_SALTWELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_BONNELL, NO_SPECULATION | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_BONNELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SALTWELL, NO_SPECULATION | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SALTWELL_TABLET, NO_SPECULATION | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SALTWELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_BONNELL, NO_SPECULATION | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_BONNELL_MID, NO_SPECULATION | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_SILVERMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_SILVERMONT_D, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_SILVERMONT_MID, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_AIRMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_XEON_PHI_KNL, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_XEON_PHI_KNM, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SILVERMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SILVERMONT_D, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SILVERMONT_MID, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_AIRMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(XEON_PHI_KNL, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(XEON_PHI_KNM, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_CORE_YONAH, NO_SSB),
+ VULNWL_INTEL(CORE_YONAH, NO_SSB),
- VULNWL_INTEL(INTEL_ATOM_SILVERMONT_MID2,NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | MSBDS_ONLY),
- VULNWL_INTEL(INTEL_ATOM_AIRMONT_NP, NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT),
+ VULNWL_INTEL(ATOM_SILVERMONT_MID2, NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | MSBDS_ONLY),
+ VULNWL_INTEL(ATOM_AIRMONT_NP, NO_SSB | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT),
- VULNWL_INTEL(INTEL_ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
- VULNWL_INTEL(INTEL_ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
- VULNWL_INTEL(INTEL_ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_EIBRS_PBRSB),
+ VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
+ VULNWL_INTEL(ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO),
+ VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_EIBRS_PBRSB),
/*
* Technically, swapgs isn't serializing on AMD (despite it previously
@@ -1177,9 +1177,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
* good enough for our purposes.
*/
- VULNWL_INTEL(INTEL_ATOM_TREMONT, NO_EIBRS_PBRSB),
- VULNWL_INTEL(INTEL_ATOM_TREMONT_L, NO_EIBRS_PBRSB),
- VULNWL_INTEL(INTEL_ATOM_TREMONT_D, NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB),
+ VULNWL_INTEL(ATOM_TREMONT, NO_EIBRS_PBRSB),
+ VULNWL_INTEL(ATOM_TREMONT_L, NO_EIBRS_PBRSB),
+ VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB),
/* AMD Family 0xf - 0x12 */
VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
@@ -1200,8 +1200,11 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
#define VULNBL(vendor, family, model, blacklist) \
X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, blacklist)
+#define VULNBL_INTEL(vfm, issues) \
+ VULNBL_INTEL_STEPS(vfm, X86_STEP_MAX, issues)
+
#define VULNBL_INTEL_STEPS(vfm, max_stepping, issues) \
- X86_MATCH_VFM_STEPS(vfm, X86_STEP_MIN, max_stepping, issues)
+ X86_MATCH_VFM_STEPS(INTEL_##vfm, X86_STEP_MIN, max_stepping, issues)
#define VULNBL_AMD(family, blacklist) \
VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
@@ -1226,50 +1229,50 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
#define RFDS BIT(7)
static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
- VULNBL_INTEL_STEPS(INTEL_IVYBRIDGE, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_HASWELL, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_HASWELL_L, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_HASWELL_G, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_HASWELL_X, X86_STEP_MAX, MMIO),
- VULNBL_INTEL_STEPS(INTEL_BROADWELL_D, X86_STEP_MAX, MMIO),
- VULNBL_INTEL_STEPS(INTEL_BROADWELL_G, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_BROADWELL_X, X86_STEP_MAX, MMIO),
- VULNBL_INTEL_STEPS(INTEL_BROADWELL, X86_STEP_MAX, SRBDS),
- VULNBL_INTEL_STEPS(INTEL_SKYLAKE_X, X86_STEP_MAX, MMIO | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_SKYLAKE_L, X86_STEP_MAX, MMIO | RETBLEED | GDS | SRBDS),
- VULNBL_INTEL_STEPS(INTEL_SKYLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS | SRBDS),
- VULNBL_INTEL_STEPS(INTEL_KABYLAKE_L, X86_STEP_MAX, MMIO | RETBLEED | GDS | SRBDS),
- VULNBL_INTEL_STEPS(INTEL_KABYLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS | SRBDS),
- VULNBL_INTEL_STEPS(INTEL_CANNONLAKE_L, X86_STEP_MAX, RETBLEED),
- VULNBL_INTEL_STEPS(INTEL_ICELAKE_L, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_ICELAKE_D, X86_STEP_MAX, MMIO | GDS),
- VULNBL_INTEL_STEPS(INTEL_ICELAKE_X, X86_STEP_MAX, MMIO | GDS),
- VULNBL_INTEL_STEPS(INTEL_COMETLAKE, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_COMETLAKE_L, 0x0, MMIO | RETBLEED),
- VULNBL_INTEL_STEPS(INTEL_COMETLAKE_L, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_TIGERLAKE_L, X86_STEP_MAX, GDS),
- VULNBL_INTEL_STEPS(INTEL_TIGERLAKE, X86_STEP_MAX, GDS),
- VULNBL_INTEL_STEPS(INTEL_LAKEFIELD, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED),
- VULNBL_INTEL_STEPS(INTEL_ROCKETLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS),
- VULNBL_INTEL_STEPS(INTEL_ALDERLAKE, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_P, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_S, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_GRACEMONT, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_TREMONT, X86_STEP_MAX, MMIO | MMIO_SBDS | RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_TREMONT_D, X86_STEP_MAX, MMIO | RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_TREMONT_L, X86_STEP_MAX, MMIO | MMIO_SBDS | RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_GOLDMONT, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_GOLDMONT_D, X86_STEP_MAX, RFDS),
- VULNBL_INTEL_STEPS(INTEL_ATOM_GOLDMONT_PLUS, X86_STEP_MAX, RFDS),
-
- VULNBL_AMD(0x15, RETBLEED),
- VULNBL_AMD(0x16, RETBLEED),
- VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO),
- VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO),
- VULNBL_AMD(0x19, SRSO),
- VULNBL_AMD(0x1a, SRSO),
+ VULNBL_INTEL( IVYBRIDGE, SRBDS),
+ VULNBL_INTEL( HASWELL, SRBDS),
+ VULNBL_INTEL( HASWELL_L, SRBDS),
+ VULNBL_INTEL( HASWELL_G, SRBDS),
+ VULNBL_INTEL( HASWELL_X, MMIO),
+ VULNBL_INTEL( BROADWELL_D, MMIO),
+ VULNBL_INTEL( BROADWELL_G, SRBDS),
+ VULNBL_INTEL( BROADWELL_X, MMIO),
+ VULNBL_INTEL( BROADWELL, SRBDS),
+ VULNBL_INTEL( SKYLAKE_X, MMIO | RETBLEED | GDS),
+ VULNBL_INTEL( SKYLAKE_L, MMIO | RETBLEED | GDS | SRBDS),
+ VULNBL_INTEL( SKYLAKE, MMIO | RETBLEED | GDS | SRBDS),
+ VULNBL_INTEL( KABYLAKE_L, MMIO | RETBLEED | GDS | SRBDS),
+ VULNBL_INTEL( KABYLAKE, MMIO | RETBLEED | GDS | SRBDS),
+ VULNBL_INTEL( CANNONLAKE_L, RETBLEED),
+ VULNBL_INTEL( ICELAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS),
+ VULNBL_INTEL( ICELAKE_D, MMIO | GDS),
+ VULNBL_INTEL( ICELAKE_X, MMIO | GDS),
+ VULNBL_INTEL( COMETLAKE, MMIO | MMIO_SBDS | RETBLEED | GDS),
+ VULNBL_INTEL_STEPS( COMETLAKE_L, 0x0, MMIO | RETBLEED),
+ VULNBL_INTEL( COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS),
+ VULNBL_INTEL( TIGERLAKE_L, GDS),
+ VULNBL_INTEL( TIGERLAKE, GDS),
+ VULNBL_INTEL( LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED),
+ VULNBL_INTEL( ROCKETLAKE, MMIO | RETBLEED | GDS),
+ VULNBL_INTEL( ALDERLAKE, RFDS),
+ VULNBL_INTEL( ALDERLAKE_L, RFDS),
+ VULNBL_INTEL( RAPTORLAKE, RFDS),
+ VULNBL_INTEL( RAPTORLAKE_P, RFDS),
+ VULNBL_INTEL( RAPTORLAKE_S, RFDS),
+ VULNBL_INTEL( ATOM_GRACEMONT, RFDS),
+ VULNBL_INTEL( ATOM_TREMONT, MMIO | MMIO_SBDS | RFDS),
+ VULNBL_INTEL( ATOM_TREMONT_D, MMIO | RFDS),
+ VULNBL_INTEL( ATOM_TREMONT_L, MMIO | MMIO_SBDS | RFDS),
+ VULNBL_INTEL( ATOM_GOLDMONT, RFDS),
+ VULNBL_INTEL( ATOM_GOLDMONT_D, RFDS),
+ VULNBL_INTEL( ATOM_GOLDMONT_PLUS, RFDS),
+
+ VULNBL_AMD( 0x15, RETBLEED),
+ VULNBL_AMD( 0x16, RETBLEED),
+ VULNBL_AMD( 0x17, RETBLEED | SMT_RSB | SRSO),
+ VULNBL_HYGON( 0x18, RETBLEED | SMT_RSB | SRSO),
+ VULNBL_AMD( 0x19, SRSO),
+ VULNBL_AMD( 0x1a, SRSO),
{}
};
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list
2025-03-06 7:13 ` [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list Pawan Gupta
@ 2025-03-06 15:18 ` Dave Hansen
2025-03-06 16:57 ` Pawan Gupta
0 siblings, 1 reply; 10+ messages in thread
From: Dave Hansen @ 2025-03-06 15:18 UTC (permalink / raw)
To: Pawan Gupta, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
On 3/5/25 23:13, Pawan Gupta wrote:
...
> #define VULNWL_INTEL(vfm, whitelist) \
> - X86_MATCH_VFM(vfm, whitelist)
> + X86_MATCH_VFM(INTEL_##vfm, whitelist)
I think the new VFM code may have thrown you off here. Doing HASWELL_X
is not as nice as INTEL_HASWELL_X because, while you can grep for it, it
won't work when you're looking for full identifiers like with ctags or
cscope.
Also, this is just putting the "INTEL" in the macro instead of the VFM.
I'm not sure there's much value in doing:
VULNWL_INTEL(ALDERLAKE_L, ...)
over:
X86_MATCH_VFM(INTEL_ALDERLAKE_L, ...)
Before the 'vfm' stuff, we needed X86_VENDOR_INTEL in there somewhere.
But now that it's built in to INTEL_ALDERLAKE_L, we don't.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list
2025-03-06 15:18 ` Dave Hansen
@ 2025-03-06 16:57 ` Pawan Gupta
2025-03-06 17:03 ` Dave Hansen
0 siblings, 1 reply; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 16:57 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
On Thu, Mar 06, 2025 at 07:18:55AM -0800, Dave Hansen wrote:
> On 3/5/25 23:13, Pawan Gupta wrote:
> ...
> > #define VULNWL_INTEL(vfm, whitelist) \
> > - X86_MATCH_VFM(vfm, whitelist)
> > + X86_MATCH_VFM(INTEL_##vfm, whitelist)
>
> I think the new VFM code may have thrown you off here. Doing HASWELL_X
> is not as nice as INTEL_HASWELL_X because, while you can grep for it, it
> won't work when you're looking for full identifiers like with ctags or
> cscope.
>
> Also, this is just putting the "INTEL" in the macro instead of the VFM.
> I'm not sure there's much value in doing:
>
> VULNWL_INTEL(ALDERLAKE_L, ...)
>
> over:
>
> X86_MATCH_VFM(INTEL_ALDERLAKE_L, ...)
Ahh, right. I will fix that. Thanks for pointing this out.
As one of the goal of the patch is to shorten the macro names and follow
the VULNWL_<> pattern, would it make sense to rename VULNWL_INTEL to:
#define VULNWL_VFM(vfm, whitelist) \
X86_MATCH_VFM(vfm, whitelist)
Then the table would look like:
VULNWL_VFM(INTEL_TIGERLAKE, NO_MMIO),
Simlarly for cpu_vuln_blacklist the macros become:
#define VULNBL_VFM(vfm, issues) \
VULNBL_VFM_STEPS(vfm, X86_STEP_MAX, issues)
#define VULNBL_VFM_STEPS(vfm, max_stepping, issues) \
X86_MATCH_VFM_STEPS(vfm, X86_STEP_MIN, max_stepping, issues)
#define VULNBL_VFM_TYPE(vfm, cpu_type, issues) \
X86_MATCH_VFM_CPU_TYPE(vfm, \
INTEL_CPU_TYPE_##cpu_type, \
issues)
And the table would look like:
VULNBL_VFM(INTEL_COMETLAKE, MMIO | MMIO_SBDS | RETBLEED | GDS),
VULNBL_VFM_STEPS(INTEL_COMETLAKE_L, 0x0, MMIO | RETBLEED),
...
VULNBL_VFM_TYPE(INTEL_ALDERLAKE, ATOM, RFDS),
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list
2025-03-06 16:57 ` Pawan Gupta
@ 2025-03-06 17:03 ` Dave Hansen
2025-03-06 17:20 ` Pawan Gupta
0 siblings, 1 reply; 10+ messages in thread
From: Dave Hansen @ 2025-03-06 17:03 UTC (permalink / raw)
To: Pawan Gupta
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
On 3/6/25 08:57, Pawan Gupta wrote:
> As one of the goal of the patch is to shorten the macro names and follow
> the VULNWL_<> pattern, would it make sense to rename VULNWL_INTEL to:
>
> #define VULNWL_VFM(vfm, whitelist) \
> X86_MATCH_VFM(vfm, whitelist)
I don't think saving 6 characters justifies the extra level of
abstraction personally.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list
2025-03-06 17:03 ` Dave Hansen
@ 2025-03-06 17:20 ` Pawan Gupta
0 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 17:20 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
On Thu, Mar 06, 2025 at 09:03:52AM -0800, Dave Hansen wrote:
> On 3/6/25 08:57, Pawan Gupta wrote:
> > As one of the goal of the patch is to shorten the macro names and follow
> > the VULNWL_<> pattern, would it make sense to rename VULNWL_INTEL to:
> >
> > #define VULNWL_VFM(vfm, whitelist) \
> > X86_MATCH_VFM(vfm, whitelist)
>
> I don't think saving 6 characters justifies the extra level of
> abstraction personally.
Ok, I will stick with X86_MATCH_VFM().
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v6 5/5] x86/rfds: Exclude P-only parts from the RFDS affected list
2025-03-06 7:12 [PATCH v6 0/5] Utilize cpu-type for CPU matching Pawan Gupta
` (3 preceding siblings ...)
2025-03-06 7:13 ` [PATCH v6 4/5] x86/bugs: Declutter vulnerable CPU list Pawan Gupta
@ 2025-03-06 7:13 ` Pawan Gupta
4 siblings, 0 replies; 10+ messages in thread
From: Pawan Gupta @ 2025-03-06 7:13 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
Cc: daniel.sneddon, tony.luck, linux-kernel, linux-pm,
linux-perf-users, Josh Poimboeuf, Srinivas Pandruvada,
Rafael J. Wysocki, Ricardo Neri, Liang, Kan, Andrew Cooper,
Brice Goglin, Mario Limonciello, Perry Yuan, Dapeng Mi
The affected CPU table (cpu_vuln_blacklist) marks Alderlake and Raptorlake
P-only parts affected by RFDS. This is not true because only E-cores are
affected by RFDS. With the current family/model matching it is not possible
to differentiate the unaffected parts, as the affected and unaffected
hybrid variants have the same model number.
Add a cpu-type match as well for such parts so as to exclude P-only parts
being marked as affected.
Note, family/model and cpu-type enumeration could be inaccurate in
virtualized environments. In a guest affected status is decided by RFDS_NO
and RFDS_CLEAR bits exposed by VMMs.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst | 8 --------
arch/x86/kernel/cpu/common.c | 9 +++++++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
index 0585d02b9a6c..ad15417d39f9 100644
--- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
+++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
@@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_:
RAPTORLAKE_S 06_BFH
=================== ============
-As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and
-RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as
-vulnerable in Linux because they share the same family/model with an affected
-part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or
-CPUID.HYBRID. This information could be used to distinguish between the
-affected and unaffected parts, but it is deemed not worth adding complexity as
-the reporting is fixed automatically when these parts enumerate RFDS_NO.
-
Mitigation
==========
Intel released a microcode update that enables software to clear sensitive
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9d41f8f7267a..fa9773207175 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1206,6 +1206,11 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
#define VULNBL_INTEL_STEPS(vfm, max_stepping, issues) \
X86_MATCH_VFM_STEPS(INTEL_##vfm, X86_STEP_MIN, max_stepping, issues)
+#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \
+ X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, \
+ INTEL_CPU_TYPE_##cpu_type, \
+ issues)
+
#define VULNBL_AMD(family, blacklist) \
VULNBL(AMD, family, X86_MODEL_ANY, blacklist)
@@ -1254,9 +1259,9 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
VULNBL_INTEL( TIGERLAKE, GDS),
VULNBL_INTEL( LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED),
VULNBL_INTEL( ROCKETLAKE, MMIO | RETBLEED | GDS),
- VULNBL_INTEL( ALDERLAKE, RFDS),
+ VULNBL_INTEL_TYPE( ALDERLAKE, ATOM, RFDS),
VULNBL_INTEL( ALDERLAKE_L, RFDS),
- VULNBL_INTEL( RAPTORLAKE, RFDS),
+ VULNBL_INTEL_TYPE( RAPTORLAKE, ATOM, RFDS),
VULNBL_INTEL( RAPTORLAKE_P, RFDS),
VULNBL_INTEL( RAPTORLAKE_S, RFDS),
VULNBL_INTEL( ATOM_GRACEMONT, RFDS),
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread