[PATCH v10 0/3] x86: Capability bits fix and required bits sanity check

[PATCH v10 0/3] x86: Capability bits fix and required bits sanity check

[Maciej Wieczor-Retman]

Series aims to fix the inconsistency between the cpuinfo behavior and
the documentation. Specifically the features that are not compiled are
still present in the cpuinfo bitmasks as enabled. This is not in line
with the documentation which specifies that not-compiled features are
not present in /proc/cpuinfo.

Along adding the disabled feature bitmask initializer array, the
complementary required bitmask initializer is also added. It can be used
to provide a sanity check, after the cpu identification is finished, to
make sure every required bit is set in the final bitmask. A warning with
the cpu number and all required bits that were not set is emitted in
case of the sanity check failure.

Before adding the sanity check a small cleanup can be done. Three places
open code an operation that retrieves either a feature string or, if the
string is not present, the feature number in word:bit format. One of
these places also doesn't check whether the string is actually there or
not. The cleanup patch fixes that and simplifies the other two
instances.

Patches are based on v7.0-rc4

Previous patchset versions:
v9: https://lore.kernel.org/all/cover.1773165421.git.m.wieczorretman@pm.me/
v8: https://lore.kernel.org/all/cover.1772453012.git.m.wieczorretman@pm.me/
v7: https://lore.kernel.org/all/cover.1771936214.git.m.wieczorretman@pm.me/
v6: https://lore.kernel.org/all/cover.1771590895.git.m.wieczorretman@pm.me/
v5: https://lore.kernel.org/all/cover.1770908783.git.m.wieczorretman@pm.me/
v4: https://lore.kernel.org/all/20250724125346.2792543-1-maciej.wieczor-retman@intel.com/
v3: https://lore.kernel.org/all/20250724094554.2153919-1-maciej.wieczor-retman@intel.com/
v2: https://lore.kernel.org/all/20250723092250.3411923-1-maciej.wieczor-retman@intel.com/
v1: https://lore.kernel.org/all/20250722074439.4069992-1-maciej.wieczor-retman@intel.com/

Maciej Wieczor-Retman (3):
  x86/cpu: Clear feature bits disabled at compile-time
  x86/cpu: Check if feature string is non-zero
  x86/cpu: Do a sanity check on required feature bits

 arch/x86/include/asm/cpufeature.h  |  4 ++
 arch/x86/kernel/cpu/common.c       | 64 +++++++++++++++++++++++++++---
 arch/x86/kernel/cpu/cpuid-deps.c   | 21 ++--------
 arch/x86/tools/cpufeaturemasks.awk |  6 +++
 4 files changed, 71 insertions(+), 24 deletions(-)

-- 
2.53.0

[PATCH v10 1/3] x86/cpu: Clear feature bits disabled at compile-time

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

If some config options are disabled during compile time, they still are
enumerated in macros that use the x86_capability bitmask - cpu_has() or
this_cpu_has().

The features are also visible in /proc/cpuinfo even though they are not
enabled - which is contrary to what the documentation states about the
file. Examples of such feature flags are lam, fred, sgx, user_shstk and
enqcmd.

Initialize cpu_caps_cleared[] with an autogenerated disabled bitmask.
During CPU init, apply_forced_caps() will clear the corresponding bits
in struct cpuinfo_x86 for each CPU. Thus features disabled at compile
time won't show up in /proc/cpuinfo.

No BUGS are defined to be cleared at compile time, therefore only the
NCAPINTS part of cpu_caps_cleared[] is initialized using the macro. The
NBUGINTS part is set to zero.

Reported-by: Farrah Chen <farrah.chen@intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220348
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
---
Changelog v10:
- Remove examples of feature flags that came from stable kernels.
- Redo the patch message a bit with Sohil's suggestions.
- Add Sohil's Reviewed-by tag.

Changelog v9:
- *_MASK_INITIALIZER -> *_MASK_INIT
- Remove Cc stable.
- Note that the BUGS part of cpu_caps_cleared[] is zeroed.

Changelog v6:
- Remove patch message portions that are not just describing the diff.

 arch/x86/kernel/cpu/common.c       | 3 ++-
 arch/x86/tools/cpufeaturemasks.awk | 6 ++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..76339e988304 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -735,7 +735,8 @@ static const char *table_lookup_model(struct cpuinfo_x86 *c)
 }
 
 /* Aligned to unsigned long to avoid split lock in atomic bitmap ops */
-__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
+__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long)) =
+	DISABLED_MASK_INIT;
 __u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/tools/cpufeaturemasks.awk b/arch/x86/tools/cpufeaturemasks.awk
index 173d5bf2d999..9382bd15279a 100755
--- a/arch/x86/tools/cpufeaturemasks.awk
+++ b/arch/x86/tools/cpufeaturemasks.awk
@@ -82,6 +82,12 @@ END {
 		}
 		printf " 0\t\\\n";
 		printf "\t) & (1U << ((x) & 31)))\n\n";
+
+		printf "\n#define %s_MASK_INIT\t\t\t\\", s;
+		printf "\n\t{\t\t\t\t\t\t\\";
+		for (i = 0; i < ncapints; i++)
+			printf "\n\t\t%s_MASK%d,\t\t\t\\", s, i;
+		printf "\n\t}\n\n";
 	}
 
 	printf "#endif /* _ASM_X86_CPUFEATUREMASKS_H */\n";
-- 
2.53.0

[PATCH v10 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

In filter_cpuid_features(), x86_cap_flags[] is read, but it's not verified
whether the string is non-zero which could lead to unwanted output.

In two more places there are open coded paths that try to retrieve a
feature string, and if there isn't one, the feature word and bit are
returned instead.

Add a common helper to fix filter_cpuid_features() as well as clean up
the open coded cases.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v10:
- Reword the patch message a bit.
- Move x86_cap_name() declaration and X86_CAP_BUF_SIZE define to
  asm/cpufeature.h.
- Don't include asm/cpu.h in cpuid-deps.c
- Extend the comment above x86_cap_name to include information on buffer
  size that needs to be prepared before calling the function.
- Remove the likely(), unlikely() calls since this is not a hot path.

Changelog v9:
- 16 -> X86_CAP_BUF_SIZE.
- Add comment to the x86_cap_name().

Changelog v8:
- Move x86_cap_name() declaration from linux/cpu.h to the arch/cpu.h.
  Include arch/cpu.h in the cpuid-deps.c file instead of linux/cpu.h.

Changelog v7:
- sizeof(buf) -> 16
- Rebase onto 7.01-rc1.

Changelog v6:
- Remove parts of the patch message that are redundant and just copy
  what's visible in the diff.
- Redo the helper to use an external char buffer instead of a local
  static string.

 arch/x86/include/asm/cpufeature.h |  4 ++++
 arch/x86/kernel/cpu/common.c      | 32 ++++++++++++++++++++++++++-----
 arch/x86/kernel/cpu/cpuid-deps.c  | 21 +++-----------------
 3 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 3ddc1d33399b..dc1cd44ddd63 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -138,5 +138,9 @@ static __always_inline bool _static_cpu_has(u16 bit)
 #define CPU_FEATURE_TYPEVAL		boot_cpu_data.x86_vendor, boot_cpu_data.x86, \
 					boot_cpu_data.x86_model
 
+#define X86_CAP_BUF_SIZE			16
+
+const char *x86_cap_name(unsigned int bit, char *buf);
+
 #endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) */
 #endif /* _ASM_X86_CPUFEATURE_H */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 76339e988304..0e318f3d56cb 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -678,6 +678,7 @@ cpuid_dependent_features[] = {
 static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
 {
 	const struct cpuid_dependent_feature *df;
+	char feature_buf[X86_CAP_BUF_SIZE];
 
 	for (df = cpuid_dependent_features; df->feature; df++) {
 
@@ -700,7 +701,7 @@ static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
 			continue;
 
 		pr_warn("CPU: CPU feature %s disabled, no CPUID level 0x%x\n",
-			x86_cap_flags[df->feature], df->level);
+			x86_cap_name(df->feature, feature_buf), df->level);
 	}
 }
 
@@ -1637,6 +1638,7 @@ static inline bool parse_set_clear_cpuid(char *arg, bool set)
 
 	while (arg) {
 		bool found __maybe_unused = false;
+		char name_buf[X86_CAP_BUF_SIZE];
 		unsigned int bit;
 
 		opt = strsep(&arg, ",");
@@ -1657,10 +1659,7 @@ static inline bool parse_set_clear_cpuid(char *arg, bool set)
 					setup_clear_cpu_cap(bit);
 				}
 				/* empty-string, i.e., ""-defined feature flags */
-				if (!x86_cap_flags[bit])
-					pr_cont(" %d:%d\n", bit >> 5, bit & 31);
-				else
-					pr_cont(" %s\n", x86_cap_flags[bit]);
+				pr_cont(" %s\n", x86_cap_name(bit, name_buf));
 
 				taint++;
 			}
@@ -1983,6 +1982,29 @@ static void generic_identify(struct cpuinfo_x86 *c)
 #endif
 }
 
+/*
+ * Return the feature "name" if available, otherwise return the
+ * X86_FEATURE_* numerals to make it easier to identify the feature.
+ * Callers of this function need to pass a char * buffer of size
+ * X86_CAP_BUF_SIZE.
+ */
+const char *x86_cap_name(unsigned int bit, char *buf)
+{
+	unsigned int word = bit >> 5;
+	const char *name = NULL;
+
+	if (word < NCAPINTS)
+		name = x86_cap_flags[bit];
+	else if (word < NCAPINTS + NBUGINTS)
+		name = x86_bug_flags[bit - 32 * NCAPINTS];
+
+	if (name)
+		return name;
+
+	snprintf(buf, X86_CAP_BUF_SIZE, "%u:%u", word, bit & 31);
+	return buf;
+}
+
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 146f6f8b0650..5002f496d095 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -156,24 +156,9 @@ void setup_clear_cpu_cap(unsigned int feature)
 	do_clear_cpu_cap(NULL, feature);
 }
 
-/*
- * Return the feature "name" if available, otherwise return
- * the X86_FEATURE_* numerals to make it easier to identify
- * the feature.
- */
-static const char *x86_feature_name(unsigned int feature, char *buf)
-{
-	if (x86_cap_flags[feature])
-		return x86_cap_flags[feature];
-
-	snprintf(buf, 16, "%d*32+%2d", feature / 32, feature % 32);
-
-	return buf;
-}
-
 void check_cpufeature_deps(struct cpuinfo_x86 *c)
 {
-	char feature_buf[16], depends_buf[16];
+	char feature_buf[X86_CAP_BUF_SIZE], depends_buf[X86_CAP_BUF_SIZE];
 	const struct cpuid_dep *d;
 
 	for (d = cpuid_deps; d->feature; d++) {
@@ -185,8 +170,8 @@ void check_cpufeature_deps(struct cpuinfo_x86 *c)
 			 */
 			pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n",
 				     smp_processor_id(),
-				     x86_feature_name(d->feature, feature_buf),
-				     x86_feature_name(d->depends, depends_buf));
+				     x86_cap_name(d->feature, feature_buf),
+				     x86_cap_name(d->depends, depends_buf));
 		}
 	}
 }
-- 
2.53.0

Re: [PATCH v10 2/3] x86/cpu: Check if feature string is non-zero

[Sohil Mehta]

On 3/17/2026 1:00 PM, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> In filter_cpuid_features(), x86_cap_flags[] is read, but it's not verified
> whether the string is non-zero which could lead to unwanted output.
> 
> In two more places there are open coded paths that try to retrieve a
> feature string, and if there isn't one, the feature word and bit are
> returned instead.
> 
> Add a common helper to fix filter_cpuid_features() as well as clean up
> the open coded cases.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---

Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>

Re: [PATCH v10 2/3] x86/cpu: Check if feature string is non-zero

[Pawan Gupta]

On Tue, Mar 17, 2026 at 08:00:16PM +0000, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> In filter_cpuid_features(), x86_cap_flags[] is read, but it's not verified
> whether the string is non-zero which could lead to unwanted output.
> 
> In two more places there are open coded paths that try to retrieve a
> feature string, and if there isn't one, the feature word and bit are
> returned instead.
> 
> Add a common helper to fix filter_cpuid_features() as well as clean up
> the open coded cases.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> ---
> Changelog v10:
> - Reword the patch message a bit.
> - Move x86_cap_name() declaration and X86_CAP_BUF_SIZE define to
>   asm/cpufeature.h.
> - Don't include asm/cpu.h in cpuid-deps.c
> - Extend the comment above x86_cap_name to include information on buffer
>   size that needs to be prepared before calling the function.
> - Remove the likely(), unlikely() calls since this is not a hot path.
> 
> Changelog v9:
> - 16 -> X86_CAP_BUF_SIZE.
> - Add comment to the x86_cap_name().
> 
> Changelog v8:
> - Move x86_cap_name() declaration from linux/cpu.h to the arch/cpu.h.
>   Include arch/cpu.h in the cpuid-deps.c file instead of linux/cpu.h.
> 
> Changelog v7:
> - sizeof(buf) -> 16
> - Rebase onto 7.01-rc1.
> 
> Changelog v6:
> - Remove parts of the patch message that are redundant and just copy
>   what's visible in the diff.
> - Redo the helper to use an external char buffer instead of a local
>   static string.
> 
>  arch/x86/include/asm/cpufeature.h |  4 ++++
>  arch/x86/kernel/cpu/common.c      | 32 ++++++++++++++++++++++++++-----
>  arch/x86/kernel/cpu/cpuid-deps.c  | 21 +++-----------------
>  3 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index 3ddc1d33399b..dc1cd44ddd63 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -138,5 +138,9 @@ static __always_inline bool _static_cpu_has(u16 bit)
>  #define CPU_FEATURE_TYPEVAL		boot_cpu_data.x86_vendor, boot_cpu_data.x86, \
>  					boot_cpu_data.x86_model
>  
> +#define X86_CAP_BUF_SIZE			16

This can get rid of the extra tab.

Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

Re: [PATCH v10 2/3] x86/cpu: Check if feature string is non-zero

[Maciej Wieczor-Retman]

On 2026-03-18 at 16:41:58 -0700, Pawan Gupta wrote:
>On Tue, Mar 17, 2026 at 08:00:16PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> 
>> In filter_cpuid_features(), x86_cap_flags[] is read, but it's not verified
>> whether the string is non-zero which could lead to unwanted output.
>> 
>> In two more places there are open coded paths that try to retrieve a
>> feature string, and if there isn't one, the feature word and bit are
>> returned instead.
>> 
>> Add a common helper to fix filter_cpuid_features() as well as clean up
>> the open coded cases.
>> 
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> ---
>> Changelog v10:
>> - Reword the patch message a bit.
>> - Move x86_cap_name() declaration and X86_CAP_BUF_SIZE define to
>>   asm/cpufeature.h.
>> - Don't include asm/cpu.h in cpuid-deps.c
>> - Extend the comment above x86_cap_name to include information on buffer
>>   size that needs to be prepared before calling the function.
>> - Remove the likely(), unlikely() calls since this is not a hot path.
>> 
>> Changelog v9:
>> - 16 -> X86_CAP_BUF_SIZE.
>> - Add comment to the x86_cap_name().
>> 
>> Changelog v8:
>> - Move x86_cap_name() declaration from linux/cpu.h to the arch/cpu.h.
>>   Include arch/cpu.h in the cpuid-deps.c file instead of linux/cpu.h.
>> 
>> Changelog v7:
>> - sizeof(buf) -> 16
>> - Rebase onto 7.01-rc1.
>> 
>> Changelog v6:
>> - Remove parts of the patch message that are redundant and just copy
>>   what's visible in the diff.
>> - Redo the helper to use an external char buffer instead of a local
>>   static string.
>> 
>>  arch/x86/include/asm/cpufeature.h |  4 ++++
>>  arch/x86/kernel/cpu/common.c      | 32 ++++++++++++++++++++++++++-----
>>  arch/x86/kernel/cpu/cpuid-deps.c  | 21 +++-----------------
>>  3 files changed, 34 insertions(+), 23 deletions(-)
>> 
>> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
>> index 3ddc1d33399b..dc1cd44ddd63 100644
>> --- a/arch/x86/include/asm/cpufeature.h
>> +++ b/arch/x86/include/asm/cpufeature.h
>> @@ -138,5 +138,9 @@ static __always_inline bool _static_cpu_has(u16 bit)
>>  #define CPU_FEATURE_TYPEVAL		boot_cpu_data.x86_vendor, boot_cpu_data.x86, \
>>  					boot_cpu_data.x86_model
>>  
>> +#define X86_CAP_BUF_SIZE			16
>
>This can get rid of the extra tab.
>
>Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

Thanks, I'll delete that extra tab.

-- 
Kind regards
Maciej Wieczór-Retman

[PATCH v10 3/3] x86/cpu: Do a sanity check on required feature bits

[Maciej Wieczor-Retman]

From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

After CPU identification concludes, do a sanity check by comparing the
final x86_capability bitmask with the pre-defined required feature bits.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
Changelog v10:
- Shorten the comment before the sanity check.
- cpu -> CPU in the warning.
- NCAPINTS << 5 -> NCAPINTS * 32

Changelog v9:
- REQUIRED_MASK_INITIALIZER -> REQUIRED_MASK_INIT
- Redo the comments.
- Fix reverse xmas order.
- Inside for_each_set_bit: (void *) -> (unsigned long *).
- 16 -> X86_CAP_BUF_SIZE.

Changelog v6:
- Add Peter's acked-by tag.
- Rename patch subject to imperative form.
- Add a char buffer to the x86_cap_name() call.

 arch/x86/kernel/cpu/common.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 0e318f3d56cb..badf86a26e24 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2005,6 +2005,33 @@ const char *x86_cap_name(unsigned int bit, char *buf)
 	return buf;
 }
 
+/*
+ * As a sanity check compare the final x86_capability bitmask with the initial
+ * predefined required feature bits.
+ */
+static void verify_required_features(const struct cpuinfo_x86 *c)
+{
+	u32 missing[NCAPINTS] = REQUIRED_MASK_INIT;
+	char cap_buf[X86_CAP_BUF_SIZE];
+	unsigned int i;
+	u32 error = 0;
+
+	for (i = 0; i < NCAPINTS; i++) {
+		missing[i] &= ~c->x86_capability[i];
+		error |= missing[i];
+	}
+
+	if (!error)
+		return;
+
+	/* At least one required feature is missing */
+	pr_warn("CPU %d: missing required feature(s):", c->cpu_index);
+	for_each_set_bit(i, (unsigned long *)missing, NCAPINTS * 32)
+		pr_cont(" %s", x86_cap_name(i, cap_buf));
+	pr_cont("\n");
+	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+}
+
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
@@ -2134,6 +2161,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 	mcheck_cpu_init(c);
 
 	numa_add_cpu(smp_processor_id());
+
+	verify_required_features(c);
 }
 
 /*
-- 
2.53.0

Re: [PATCH v10 3/3] x86/cpu: Do a sanity check on required feature bits

[Sohil Mehta]

On 3/17/2026 1:00 PM, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> After CPU identification concludes, do a sanity check by comparing the
> final x86_capability bitmask with the pre-defined required feature bits.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> ---

A minor concern below. Other than that,

Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>


>  
> +/*
> + * As a sanity check compare the final x86_capability bitmask with the initial
> + * predefined required feature bits.
> + */
> +static void verify_required_features(const struct cpuinfo_x86 *c)
> +{
> +	u32 missing[NCAPINTS] = REQUIRED_MASK_INIT;
> +	char cap_buf[X86_CAP_BUF_SIZE];
> +	unsigned int i;
> +	u32 error = 0;
> +
> +	for (i = 0; i < NCAPINTS; i++) {
> +		missing[i] &= ~c->x86_capability[i];
> +		error |= missing[i];
> +	}
> +
> +	if (!error)
> +		return;
> +
> +	/* At least one required feature is missing */
> +	pr_warn("CPU %d: missing required feature(s):", c->cpu_index);
> +	for_each_set_bit(i, (unsigned long *)missing, NCAPINTS * 32)
> +		pr_cont(" %s", x86_cap_name(i, cap_buf));
> +	pr_cont("\n");

Could multiple APs run into this concurrently? I am wondering if there
is some risk of garbled output because of the pr_warn()/pr_cont()
combination.

Though, I don't have an easy fix if it is an issue.

> +	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> +}
> +
>  /*
>   * This does the hard work of actually picking apart the CPU stuff...
>   */
> @@ -2134,6 +2161,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>  	mcheck_cpu_init(c);
>  
>  	numa_add_cpu(smp_processor_id());
> +
> +	verify_required_features(c);
>  }
>  
>  /*

Re: [PATCH v10 3/3] x86/cpu: Do a sanity check on required feature bits

[Maciej Wieczor-Retman]

On 2026-03-17 at 13:43:54 -0700, Sohil Mehta wrote:
>On 3/17/2026 1:00 PM, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> 
>> After CPU identification concludes, do a sanity check by comparing the
>> final x86_capability bitmask with the pre-defined required feature bits.
>> 
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>> ---
>
>A minor concern below. Other than that,
>
>Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>

Thanks :)

>
>>  
>> +/*
>> + * As a sanity check compare the final x86_capability bitmask with the initial
>> + * predefined required feature bits.
>> + */
>> +static void verify_required_features(const struct cpuinfo_x86 *c)
>> +{
>> +	u32 missing[NCAPINTS] = REQUIRED_MASK_INIT;
>> +	char cap_buf[X86_CAP_BUF_SIZE];
>> +	unsigned int i;
>> +	u32 error = 0;
>> +
>> +	for (i = 0; i < NCAPINTS; i++) {
>> +		missing[i] &= ~c->x86_capability[i];
>> +		error |= missing[i];
>> +	}
>> +
>> +	if (!error)
>> +		return;
>> +
>> +	/* At least one required feature is missing */
>> +	pr_warn("CPU %d: missing required feature(s):", c->cpu_index);
>> +	for_each_set_bit(i, (unsigned long *)missing, NCAPINTS * 32)
>> +		pr_cont(" %s", x86_cap_name(i, cap_buf));
>> +	pr_cont("\n");
>
>Could multiple APs run into this concurrently? I am wondering if there
>is some risk of garbled output because of the pr_warn()/pr_cont()
>combination.

Just tested it on 224 CPU Xeon, basically I cleared a bunch of required features
from the x86_capability[] on all but the boot cpu. The warning output was serial
and no race conditions or mangled strings were observed.

Not sure if it can go wrong in any other way.

>Though, I don't have an easy fix if it is an issue.
>

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v10 3/3] x86/cpu: Do a sanity check on required feature bits

[Pawan Gupta]

On Tue, Mar 17, 2026 at 08:00:22PM +0000, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> After CPU identification concludes, do a sanity check by comparing the
> final x86_capability bitmask with the pre-defined required feature bits.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>

Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

Re: [PATCH v10 3/3] x86/cpu: Do a sanity check on required feature bits

[Maciej Wieczor-Retman]

On 2026-03-18 at 17:02:51 -0700, Pawan Gupta wrote:
>On Tue, Mar 17, 2026 at 08:00:22PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> 
>> After CPU identification concludes, do a sanity check by comparing the
>> final x86_capability bitmask with the pre-defined required feature bits.
>> 
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>
>Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

Thanks for looking at the patches!

From a bot review that Sohil showed me I realized there is one thing to fix in
this patch, namely possible unaligned access in for_each_set_bit(). So I
probably should clear the tags from this patch for the next version.

-- 
Kind regards
Maciej Wieczór-Retman