[PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[PATCH v12 0/4] 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. While currently not a problem (all the features in the checked list
have corresponding strings) it may cause a failure if more entries are
added. The cleanup patch fixes that and simplifies the other two
instances.

Patches are based on v7.0-rc5

Previous patchset versions:
v11: https://lore.kernel.org/all/cover.1774008873.git.m.wieczorretman@pm.me/
v10: https://lore.kernel.org/all/cover.1773771353.git.m.wieczorretman@pm.me/
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 (4):
  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
  x86/cpu: Clear feature bits whose dependencies were cleared

 arch/x86/include/asm/cpufeature.h  |  1 +
 arch/x86/kernel/cpu/common.c       | 63 +++++++++++++++++++++++++++---
 arch/x86/kernel/cpu/cpu.h          |  4 ++
 arch/x86/kernel/cpu/cpuid-deps.c   | 21 +++++-----
 arch/x86/tools/cpufeaturemasks.awk |  6 +++
 5 files changed, 79 insertions(+), 16 deletions(-)

-- 
2.53.0

[PATCH v12 1/4] 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 v12 2/4] 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 accessed based on the
features from cpuid_dependent_features[]. However it's not verified
whether the string in x86_cap_flags[] is non-zero which could lead to
unwanted output. While currently it's not a problem (all the features in
the checked list have non-zero strings) it may cause a failure if an
entry is added that doesn't have a feature string defined.

There are two other places that open code a similar operation of
printing out the feature string or if it's not present, the word:bit
feature format.

Reuse x86_feature_name() as a common helper to validate the presence of
feature strings in filter_cpuid_features() as well as unify similar open
coded cases.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v12:
- Remove Reviewed-by tags.
- Redo the patch message so it points out that the problem is not here
  now but may happen.
- Rename
	- X86_CAP_BUF_SIZE -> X86_NAMELSS_FEAT_BUFLEN
	- x86_cap_name() -> x86_feature_name()
- Move exporting the header to arch/x86/kernel/cpu/cpu.h
- Remove x86_bug_flags[] handling from x86_feature_name() since it
  doesn't interact with the array anywhere.

Changelog v11:
- Remove one extra tab after X86_CAP_BUF_SIZE.
- Add Reviewed-by tags from Sohil and Pawan.

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/kernel/cpu/common.c     | 30 +++++++++++++++++++++++++-----
 arch/x86/kernel/cpu/cpu.h        |  4 ++++
 arch/x86/kernel/cpu/cpuid-deps.c | 19 +++----------------
 3 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 76339e988304..7cfd124b3fbf 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_NAMELESS_FEAT_BUFLEN];
 
 	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_feature_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_NAMELESS_FEAT_BUFLEN];
 		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_feature_name(bit, name_buf));
 
 				taint++;
 			}
@@ -1983,6 +1982,27 @@ 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_NAMELESS_FEAT_BUFLEN.
+ */
+const char *x86_feature_name(unsigned int bit, char *buf)
+{
+	unsigned int word = bit >> 5;
+	const char *name = NULL;
+
+	if (word < NCAPINTS)
+		name = x86_cap_flags[bit];
+
+	if (name)
+		return name;
+
+	snprintf(buf, X86_NAMELESS_FEAT_BUFLEN, "%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/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 5c7a3a71191a..0ce29ee56442 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -91,4 +91,8 @@ static inline bool spectre_v2_in_eibrs_mode(enum spectre_v2_mitigation mode)
 	       mode == SPECTRE_V2_EIBRS_LFENCE;
 }
 
+#define X86_NAMELESS_FEAT_BUFLEN	16
+
+const char *x86_feature_name(unsigned int bit, char *buf);
+
 #endif /* ARCH_X86_CPU_H */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 146f6f8b0650..4354c0dd6d66 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -4,6 +4,8 @@
 #include <linux/module.h>
 #include <asm/cpufeature.h>
 
+#include "cpu.h"
+
 struct cpuid_dep {
 	unsigned int	feature;
 	unsigned int	depends;
@@ -156,24 +158,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_NAMELESS_FEAT_BUFLEN], depends_buf[X86_NAMELESS_FEAT_BUFLEN];
 	const struct cpuid_dep *d;
 
 	for (d = cpuid_deps; d->feature; d++) {
-- 
2.53.0

[PATCH v12 3/4] 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.

The NCAPINTS + 1 size of the required_features[] array results from
for_each_set_bit() parsing data in 64-bit chunks. In case NCAPINTS is an
odd number it will still reserve and zero out a 64-bit aligned chunk of
memory which will prevent false positives due to unaligned accesses.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v12:
- Redo the function into a one loop system instead of two loops
  according to Pawan Gupta's suggestion.
- Add a paragraph to the patch message about the NCAPINTS + 1 array
  size.

Changelog v11:
- Use DECLARE_BITMAP() on missing[] and recast to a u32 pointer for
  iterating. Do it to avoid unaligned memory accesses when later using
  for_each_set_bit() if NCAPINTS is going to ever become an odd number.
  missing[] was previously an u32 array and for_each_set_bit() works on
  unsigned long chunks of memory.
- Add a paragraph about the above to the patch message.
- Remove Peter's acked-by due to more changes.

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 | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 7cfd124b3fbf..8ad0da7012dd 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -2003,6 +2003,32 @@ const char *x86_feature_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 required_features[NCAPINTS + 1] = REQUIRED_MASK_INIT;
+	char cap_buf[X86_NAMELESS_FEAT_BUFLEN];
+	int i, error = 0;
+
+	for_each_set_bit(i, (unsigned long *)required_features, NCAPINTS * 32) {
+		if (test_bit(i, (unsigned long *)c->x86_capability))
+			continue;
+		if (!error)
+			pr_warn("CPU %d: missing required feature(s):", c->cpu_index);
+		pr_cont(" %s", x86_feature_name(i, cap_buf));
+		error = 1;
+	}
+
+	if (!error)
+		return;
+
+	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...
  */
@@ -2132,6 +2158,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

[PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Maciej Wieczor-Retman]

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

After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
features present in disabled bitmasks are cleared from x86_capability[].
However features that depend on them and are not part of any disabled
mask are not cleared by anything. They can trigger the warning in
check_cpufeature_deps(), as before both features would show up as
enabled even though they weren't. The uncleared features can also still
falsely show up in /proc/cpuinfo.

Take such cases into account before applying the cpu_caps_cleared[]
array.

Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v12:
- Move the check from check_cpufeature_deps() to apply_forced_caps().
  Redo last paragraph of the patch message.

Changelog v11:
- Add this patch to the series.

 arch/x86/include/asm/cpufeature.h |  1 +
 arch/x86/kernel/cpu/common.c      |  2 ++
 arch/x86/kernel/cpu/cpuid-deps.c  | 14 ++++++++++++++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 3ddc1d33399b..e7a62990a9c2 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -77,6 +77,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 
 extern void setup_clear_cpu_cap(unsigned int bit);
 extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
+void clear_feature_disabled_deps(struct cpuinfo_x86 *c);
 void check_cpufeature_deps(struct cpuinfo_x86 *c);
 
 #define setup_force_cpu_cap(bit) do {			\
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8ad0da7012dd..2e24bdb3acaa 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -955,6 +955,8 @@ static void apply_forced_caps(struct cpuinfo_x86 *c)
 {
 	int i;
 
+	clear_feature_disabled_deps(c);
+
 	for (i = 0; i < NCAPINTS + NBUGINTS; i++) {
 		c->x86_capability[i] &= ~cpu_caps_cleared[i];
 		c->x86_capability[i] |= cpu_caps_set[i];
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 4354c0dd6d66..83060c0013c1 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -158,6 +158,20 @@ void setup_clear_cpu_cap(unsigned int feature)
 	do_clear_cpu_cap(NULL, feature);
 }
 
+/*
+ * If the dependency was cleared through the disabled bitmasks while the
+ * feature wasn't it also needs to be cleared.
+ */
+void clear_feature_disabled_deps(struct cpuinfo_x86 *c)
+{
+	const struct cpuid_dep *d;
+
+	for (d = cpuid_deps; d->feature; d++) {
+		if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends))
+			set_bit(d->feature, (unsigned long *)cpu_caps_cleared);
+	}
+}
+
 void check_cpufeature_deps(struct cpuinfo_x86 *c)
 {
 	char feature_buf[X86_NAMELESS_FEAT_BUFLEN], depends_buf[X86_NAMELESS_FEAT_BUFLEN];
-- 
2.53.0

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

[Pawan Gupta]

On Fri, Mar 27, 2026 at 03:10:58PM +0000, Maciej Wieczor-Retman wrote:
> +static void verify_required_features(const struct cpuinfo_x86 *c)
> +{
> +	u32 required_features[NCAPINTS + 1] = REQUIRED_MASK_INIT;
> +	char cap_buf[X86_NAMELESS_FEAT_BUFLEN];
> +	int i, error = 0;
> +
> +	for_each_set_bit(i, (unsigned long *)required_features, NCAPINTS * 32) {
> +		if (test_bit(i, (unsigned long *)c->x86_capability))

This can be simplified to:

		if (test_cpu_cap(c, i))

> +			continue;
> +		if (!error)
> +			pr_warn("CPU %d: missing required feature(s):", c->cpu_index);
> +		pr_cont(" %s", x86_feature_name(i, cap_buf));
> +		error = 1;
> +	}
> +
> +	if (!error)
> +		return;
> +
> +	pr_cont("\n");
> +	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> +}

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

[Maciej Wieczor-Retman]

On 2026-03-27 at 10:10:33 -0700, Pawan Gupta wrote:
>On Fri, Mar 27, 2026 at 03:10:58PM +0000, Maciej Wieczor-Retman wrote:
>> +static void verify_required_features(const struct cpuinfo_x86 *c)
>> +{
>> +	u32 required_features[NCAPINTS + 1] = REQUIRED_MASK_INIT;
>> +	char cap_buf[X86_NAMELESS_FEAT_BUFLEN];
>> +	int i, error = 0;
>> +
>> +	for_each_set_bit(i, (unsigned long *)required_features, NCAPINTS * 32) {
>> +		if (test_bit(i, (unsigned long *)c->x86_capability))
>
>This can be simplified to:
>
>		if (test_cpu_cap(c, i))
>

Oh, right, thanks! I'll correct that for v13.

-- 
Kind regards
Maciej Wieczór-Retman

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

[Sohil Mehta]

On 3/27/2026 8:10 AM, Maciej Wieczor-Retman wrote:

>  arch/x86/kernel/cpu/common.c     | 30 +++++++++++++++++++++++++-----
>  arch/x86/kernel/cpu/cpu.h        |  4 ++++
>  arch/x86/kernel/cpu/cpuid-deps.c | 19 +++----------------
>  3 files changed, 32 insertions(+), 21 deletions(-)
> 

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

A couple of minor points below:


> @@ -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_NAMELESS_FEAT_BUFLEN];
>  		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 */

Can you delete this comment as well. It doesn't make sense now.

> -				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_feature_name(bit, name_buf));

All the other equivalent buffers are defined as feature_buf, but this
one is named as name_buf. Just curious, any specific reason?

>  
>  				taint++;
>  			}

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

[Maciej Wieczor-Retman]

On 2026-03-27 at 10:50:29 -0700, Sohil Mehta wrote:
>On 3/27/2026 8:10 AM, Maciej Wieczor-Retman wrote:
>
>>  arch/x86/kernel/cpu/common.c     | 30 +++++++++++++++++++++++++-----
>>  arch/x86/kernel/cpu/cpu.h        |  4 ++++
>>  arch/x86/kernel/cpu/cpuid-deps.c | 19 +++----------------
>>  3 files changed, 32 insertions(+), 21 deletions(-)
>> 
>
>Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
>
>A couple of minor points below:
>
>
>> @@ -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_NAMELESS_FEAT_BUFLEN];
>>  		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 */
>
>Can you delete this comment as well. It doesn't make sense now.

Right, will do, thanks!

>
>> -				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_feature_name(bit, name_buf));
>
>All the other equivalent buffers are defined as feature_buf, but this
>one is named as name_buf. Just curious, any specific reason?

I think I was experimenting with cleaning up a further part of
parse_set_clear_cpuid() that printed a string from either x86_bug_flags or
x86_cap_flags. It looked ugly so I scrapped it but I guess I forgot to change
the name_buf to feature_buf. I'll correct that, thanks for noticing it :)

>>  
>>  				taint++;
>>  			}

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[H. Peter Anvin]

On 2026-03-27 08:11, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> 
> After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
> features present in disabled bitmasks are cleared from x86_capability[].
> However features that depend on them and are not part of any disabled
> mask are not cleared by anything. They can trigger the warning in
> check_cpufeature_deps(), as before both features would show up as
> enabled even though they weren't. The uncleared features can also still
> falsely show up in /proc/cpuinfo.
> 
> Take such cases into account before applying the cpu_caps_cleared[]
> array.
> 
> +/*
> + * If the dependency was cleared through the disabled bitmasks while the
> + * feature wasn't it also needs to be cleared.
> + */
> +void clear_feature_disabled_deps(struct cpuinfo_x86 *c)
> +{
> +	const struct cpuid_dep *d;
> +
> +	for (d = cpuid_deps; d->feature; d++) {
> +		if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends))
> +			set_bit(d->feature, (unsigned long *)cpu_caps_cleared);
> +	}
> +}
> +

Thinking about it, if this is discovered at runtime, it is really too late,
because in a sense we have miscompiled the kernel with unwanted code (as we
should have compiled out these features just as with other DISABLED features.)

This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
be a good thing to print a message here saying Kconfig.cpufeatures should be
fixed.

The better option, which I don't know how difficult it would be, would be to
make the dependencies available to Kconfig. This sounds like something that
would fall in the scope of Ahmed's rework rather than this patchset, though
(Ahmed, would you agree?)

	-hpa

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[Andi Kleen]

I'm not sure what the point of this check is. Obviously the kernel cannot
handle it, short of refusing to boot which would be far too drastic.

And if it's just for having something in the kernel log, who would look
for this? Any possible symptoms from a bogus cpuid will be far
disconnected from that particular log location.

Further, there's also no evidence that it is a real practical problem.
If anything it could likely only come from rogue VMMs, but these don't 
seem to be common. But VMMs normally don't really disable ISA, so even if the 
CPUID is inconsistent things will still likely work because the actual
instructions are fine.

Assuming it was a real problem, you could just do it in a user program, why
put it into the kernel and waste everyone's memory? (this cannot be
initcode due to hotplug)

Also it seems to violate Steinbach's system programing maxim
(never check for something you don't know how to handle)

-Andi

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[Maciej Wieczor-Retman]

On 2026-03-29 at 23:11:19 -0700, Andi Kleen wrote:
>
>I'm not sure what the point of this check is. Obviously the kernel cannot
>handle it, short of refusing to boot which would be far too drastic.
>
>And if it's just for having something in the kernel log, who would look
>for this? Any possible symptoms from a bogus cpuid will be far
>disconnected from that particular log location.
>
>Further, there's also no evidence that it is a real practical problem.
>If anything it could likely only come from rogue VMMs, but these don't 
>seem to be common. But VMMs normally don't really disable ISA, so even if the 
>CPUID is inconsistent things will still likely work because the actual
>instructions are fine.
>
>Assuming it was a real problem, you could just do it in a user program, why
>put it into the kernel and waste everyone's memory? (this cannot be
>initcode due to hotplug)
>
>Also it seems to violate Steinbach's system programing maxim
>(never check for something you don't know how to handle)
>
>-Andi

According to hpa [1] one could for example boot with PAE disabled and it might
go unnoticed. In that thread it was also mentioned that the BIOS might have
something required disabled and even if the system will not get to boot fully a
user could get a clue what failed.

Also a user could technically disable required features through clearcpuid. I
know it will also taint the kernel but no warning is produced if the cleared
feature was required.

[1] https://lore.kernel.org/all/207ba0a6-5ebc-465a-8d54-6e5a99622a72@zytor.com/

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Maciej Wieczor-Retman]

On 2026-03-27 at 19:22:27 -0700, H. Peter Anvin wrote:
>On 2026-03-27 08:11, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> 
>> After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
>> features present in disabled bitmasks are cleared from x86_capability[].
>> However features that depend on them and are not part of any disabled
>> mask are not cleared by anything. They can trigger the warning in
>> check_cpufeature_deps(), as before both features would show up as
>> enabled even though they weren't. The uncleared features can also still
>> falsely show up in /proc/cpuinfo.
>> 
>> Take such cases into account before applying the cpu_caps_cleared[]
>> array.
>> 
>> +/*
>> + * If the dependency was cleared through the disabled bitmasks while the
>> + * feature wasn't it also needs to be cleared.
>> + */
>> +void clear_feature_disabled_deps(struct cpuinfo_x86 *c)
>> +{
>> +	const struct cpuid_dep *d;
>> +
>> +	for (d = cpuid_deps; d->feature; d++) {
>> +		if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends))
>> +			set_bit(d->feature, (unsigned long *)cpu_caps_cleared);
>> +	}
>> +}
>> +
>
>Thinking about it, if this is discovered at runtime, it is really too late,
>because in a sense we have miscompiled the kernel with unwanted code (as we
>should have compiled out these features just as with other DISABLED features.)
>
>This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
>have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
>be a good thing to print a message here saying Kconfig.cpufeatures should be
>fixed.

So how about a warning (for any future cases) and add a new patch to fix SGX (so
the current known problem is solved)?

>The better option, which I don't know how difficult it would be, would be to
>make the dependencies available to Kconfig. This sounds like something that
>would fall in the scope of Ahmed's rework rather than this patchset, though
>(Ahmed, would you agree?)
>
>	-hpa
>
>

-- 
Kind regards
Maciej Wieczór-Retman

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

[Borislav Petkov]

On Fri, Mar 27, 2026 at 03:10:52PM +0000, Maciej Wieczor-Retman wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 76339e988304..7cfd124b3fbf 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_NAMELESS_FEAT_BUFLEN];

The tip-tree preferred ordering of variable declarations at the
beginning of a function is reverse fir tree order::

	struct long_struct_name *descriptive_name;
	unsigned long foo, bar;
	unsigned int tmp;
	int ret;

The above is faster to parse than the reverse ordering::

	int ret;
	unsigned int tmp;
	unsigned long foo, bar;
	struct long_struct_name *descriptive_name;

And even more so than random ordering::

	unsigned long foo, bar;
	int ret;
	struct long_struct_name *descriptive_name;
	unsigned int tmp;

Check your whole set pls.

...

> +/*
> + * Return the feature "name" if available, otherwise return the
> + * X86_FEATURE_* numerals to make it easier to identify the feature.

"return the X86_FEATURE word number and bit position...."

Might as well correct it to be more precise.

> + * Callers of this function need to pass a char * buffer of size
> + * X86_NAMELESS_FEAT_BUFLEN.
> + */
> +const char *x86_feature_name(unsigned int bit, char *buf)

...

>  void check_cpufeature_deps(struct cpuinfo_x86 *c)
>  {
> -	char feature_buf[16], depends_buf[16];
> +	char feature_buf[X86_NAMELESS_FEAT_BUFLEN], depends_buf[X86_NAMELESS_FEAT_BUFLEN];

Blergh, that define is too long. ;-\

-- 
Regards/Gruss,
    Boris.

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

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

[Maciej Wieczor-Retman]

On 2026-03-30 at 22:00:45 +0200, Borislav Petkov wrote:
>On Fri, Mar 27, 2026 at 03:10:52PM +0000, Maciej Wieczor-Retman wrote:
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index 76339e988304..7cfd124b3fbf 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_NAMELESS_FEAT_BUFLEN];
>
>The tip-tree preferred ordering of variable declarations at the
>beginning of a function is reverse fir tree order::
>
>	struct long_struct_name *descriptive_name;
>	unsigned long foo, bar;
>	unsigned int tmp;
>	int ret;
>
>The above is faster to parse than the reverse ordering::
>
>	int ret;
>	unsigned int tmp;
>	unsigned long foo, bar;
>	struct long_struct_name *descriptive_name;
>
>And even more so than random ordering::
>
>	unsigned long foo, bar;
>	int ret;
>	struct long_struct_name *descriptive_name;
>	unsigned int tmp;
>
>Check your whole set pls.

Sorry, will do.

>
>...
>
>> +/*
>> + * Return the feature "name" if available, otherwise return the
>> + * X86_FEATURE_* numerals to make it easier to identify the feature.
>
>"return the X86_FEATURE word number and bit position...."
>
>Might as well correct it to be more precise.

so maybe:

+ * Return the feature's "name" if available, otherwise return the
+ * feature's bit numerals in "word:bit" format so it's easier to identify.

?

>> + * Callers of this function need to pass a char * buffer of size
>> + * X86_NAMELESS_FEAT_BUFLEN.
>> + */
>> +const char *x86_feature_name(unsigned int bit, char *buf)
>
>...
>
>>  void check_cpufeature_deps(struct cpuinfo_x86 *c)
>>  {
>> -	char feature_buf[16], depends_buf[16];
>> +	char feature_buf[X86_NAMELESS_FEAT_BUFLEN], depends_buf[X86_NAMELESS_FEAT_BUFLEN];
>
>Blergh, that define is too long. ;-\

X86_NAMELESS_FEAT_BUF?

X86_NUM_FEAT_BUF?

Not sure how to make it much more shorter without making it also unreadable.

-- 
Kind regards
Maciej Wieczór-Retman

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

[Borislav Petkov]

On Mon, Mar 30, 2026 at 08:42:11PM +0000, Maciej Wieczor-Retman wrote:
> + * Return the feature's "name" if available, otherwise return the
> + * feature's bit numerals in "word:bit" format so it's easier to identify.

This "numerals" thing is meh but I see why people use it.

It doesn't get any clearer than "word number and bit position".

> X86_NAMELESS_FEAT_BUF?
> 
> X86_NUM_FEAT_BUF?
> 
> Not sure how to make it much more shorter without making it also unreadable.

Yeah, I'm at the same spot as you - I can't think of a better name.

Since it is not too widespread, let's leave the longer, more descriptive one
and  we can change it later if really needed.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Ahmed S. Darwish]

On Fri, 27 Mar 2026, H. Peter Anvin wrote:
>
> Thinking about it, if this is discovered at runtime, it is really too late,
> because in a sense we have miscompiled the kernel with unwanted code (as we
> should have compiled out these features just as with other DISABLED features.)
>
> This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
> have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
> be a good thing to print a message here saying Kconfig.cpufeatures should be
> fixed.
>
> The better option, which I don't know how difficult it would be, would be to
> make the dependencies available to Kconfig. This sounds like something that
> would fall in the scope of Ahmed's rework rather than this patchset, though
> (Ahmed, would you agree?)
>

Definitely!

If the CPUID model sent some days ago is to be merged, (*) then all these
dependencies should be encoded within x86-cpuid-db, especially that it now
covers all the synthetic X86_FEATURE flags as well.

x86-cpuid-db can then flatten the Directed Acyclic Graph of dependencies,
and auto-generate a flat map which the kernel can use at configuration,
compile, and run time.

And if a dependency cycle (or other dependency annotation failures) exist,
then this can be detected early on; e.g., at the project's CI level, which
auto generates kcpuid CSV and the C99 fields at <asm/cpuid/leaf_types.h>.

Thanks,
Ahmed

(*) https://lore.kernel.org/lkml/20260327021645.555257-1-darwi@linutronix.de

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

[H. Peter Anvin]

On March 30, 2026 2:15:11 PM PDT, Borislav Petkov <bp@alien8.de> wrote:
>On Mon, Mar 30, 2026 at 08:42:11PM +0000, Maciej Wieczor-Retman wrote:
>> + * Return the feature's "name" if available, otherwise return the
>> + * feature's bit numerals in "word:bit" format so it's easier to identify.
>
>This "numerals" thing is meh but I see why people use it.
>
>It doesn't get any clearer than "word number and bit position".
>
>> X86_NAMELESS_FEAT_BUF?
>> 
>> X86_NUM_FEAT_BUF?
>> 
>> Not sure how to make it much more shorter without making it also unreadable.
>
>Yeah, I'm at the same spot as you - I can't think of a better name.
>
>Since it is not too widespread, let's leave the longer, more descriptive one
>and  we can change it later if really needed.
>
>Thx.
>

The Right Thing™ would be to have a table in the kernel which includes *all* the feature bit names, not just the ones exported to /proc/cpuinfo, and use the unfiltered string table for kernel messages (/proc/cpuinfo being filtered via a bitmask, list, or a flag in the table.)

I asked Maciej to look into it, and he has been, but I told him to not complicate this patchset too much by trying to fix everything in one shot — because it does ends up touching code in a surprisingly large set of places. 

It doesn't help one iota, either, that modprobe is supposed to know what the numeric bit positions mean, either. It is a pretty egregious design error.

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

[Borislav Petkov]

On Mon, Mar 30, 2026 at 02:44:56PM -0700, H. Peter Anvin wrote:
> The Right Thing™ would be to have a table in the kernel which includes *all*
> the feature bit names, not just the ones exported to /proc/cpuinfo, and use
> the unfiltered string table for kernel messages (/proc/cpuinfo being
> filtered via a bitmask, list, or a flag in the table.)

Meh, not convinced. Not sure it is worth the effort and bloating if we can
simply look up the feature from word and bit number.

> It doesn't help one iota, either, that modprobe is supposed to know what the
> numeric bit positions mean, either. It is a pretty egregious design error.

That was designed in ancient times, I'd presume. :)

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[H. Peter Anvin]

On 2026-03-29 23:11, Andi Kleen wrote:
> 
> I'm not sure what the point of this check is. Obviously the kernel cannot
> handle it, short of refusing to boot which would be far too drastic.
> 
> And if it's just for having something in the kernel log, who would look
> for this? Any possible symptoms from a bogus cpuid will be far
> disconnected from that particular log location.
> 
> Further, there's also no evidence that it is a real practical problem.
> If anything it could likely only come from rogue VMMs, but these don't 
> seem to be common. But VMMs normally don't really disable ISA, so even if the 
> CPUID is inconsistent things will still likely work because the actual
> instructions are fine.
> 

That's the main case; "it seems to work but if it breaks you get to keep both
pieces" -- i.e. the EXACT meaning of TAINT_CPU_OUT_OF_SPEC.

See my other posts on this thread.

> Assuming it was a real problem, you could just do it in a user program, why
> put it into the kernel and waste everyone's memory? (this cannot be
> initcode due to hotplug)
> 
> Also it seems to violate Steinbach's system programing maxim
> (never check for something you don't know how to handle)

You *do* realize that is sarcasm, right?

	-hpa

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

[H. Peter Anvin]

On 2026-03-30 15:59, Borislav Petkov wrote:
> On Mon, Mar 30, 2026 at 02:44:56PM -0700, H. Peter Anvin wrote:
>> The Right Thing™ would be to have a table in the kernel which includes *all*
>> the feature bit names, not just the ones exported to /proc/cpuinfo, and use
>> the unfiltered string table for kernel messages (/proc/cpuinfo being
>> filtered via a bitmask, list, or a flag in the table.)
> 
> Meh, not convinced. Not sure it is worth the effort and bloating if we can
> simply look up the feature from word and bit number.
> 

Bloating? Drop in the bucket compared to other kernel messages. Getting kernel
messages in cleartext is a good thing.

It's testing a flag... not exactly complicated, just didn't want Maciej to
complicate this one patchset with it.

	-hpa

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

[H. Peter Anvin]

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

On 2026-03-30 16:42, H. Peter Anvin wrote:
> On 2026-03-30 15:59, Borislav Petkov wrote:
>> On Mon, Mar 30, 2026 at 02:44:56PM -0700, H. Peter Anvin wrote:
>>> The Right Thing™ would be to have a table in the kernel which includes *all*
>>> the feature bit names, not just the ones exported to /proc/cpuinfo, and use
>>> the unfiltered string table for kernel messages (/proc/cpuinfo being
>>> filtered via a bitmask, list, or a flag in the table.)
>>
>> Meh, not convinced. Not sure it is worth the effort and bloating if we can
>> simply look up the feature from word and bit number.
>>
> 
> Bloating? Drop in the bucket compared to other kernel messages. Getting kernel
> messages in cleartext is a good thing.
> 
> It's testing a flag... not exactly complicated, just didn't want Maciej to
> complicate this one patchset with it.
> 

The main issue is that since we're not allowed to use *sane* scripting
languages in the kernel tree, we have to do everything in the POSIX subset of
awk -- or in C.

Anyway, here is a hacky and mostly untested port of mkcapflags.sh to awk which
also produces an export bitmask. Another alternative would be to simply put a
prefix character like + or - which can simply be skipped for kernel messages
but tested for /proc/cpuinfo generation. Definitely simpler in that there is
no need to haul two pointers around.

	-hpa

[-- Attachment #2: mkcapflags.awk --]
[-- Type: application/x-awk, Size: 2315 bytes --]

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Maciej Wieczor-Retman]

On 2026-03-30 at 23:41:57 +0200, Ahmed S. Darwish wrote:
>On Fri, 27 Mar 2026, H. Peter Anvin wrote:
>>
>> Thinking about it, if this is discovered at runtime, it is really too late,
>> because in a sense we have miscompiled the kernel with unwanted code (as we
>> should have compiled out these features just as with other DISABLED features.)
>>
>> This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
>> have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
>> be a good thing to print a message here saying Kconfig.cpufeatures should be
>> fixed.
>>
>> The better option, which I don't know how difficult it would be, would be to
>> make the dependencies available to Kconfig. This sounds like something that
>> would fall in the scope of Ahmed's rework rather than this patchset, though
>> (Ahmed, would you agree?)
>>
>
>Definitely!
>
>If the CPUID model sent some days ago is to be merged, (*) then all these
>dependencies should be encoded within x86-cpuid-db, especially that it now
>covers all the synthetic X86_FEATURE flags as well.
>
>x86-cpuid-db can then flatten the Directed Acyclic Graph of dependencies,
>and auto-generate a flat map which the kernel can use at configuration,
>compile, and run time.
>
>And if a dependency cycle (or other dependency annotation failures) exist,
>then this can be detected early on; e.g., at the project's CI level, which
>auto generates kcpuid CSV and the C99 fields at <asm/cpuid/leaf_types.h>.
>
>Thanks,
>Ahmed
>
>(*) https://lore.kernel.org/lkml/20260327021645.555257-1-darwi@linutronix.de

Cool, so I assume for now a warning should suffice and in the longer view the
x86-cpuid-db should help resolve the problem more broadly?

-- 
Kind regards
Maciej Wieczór-Retman

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

[Borislav Petkov]

On Mon, Mar 30, 2026 at 04:42:04PM -0700, H. Peter Anvin wrote:
> Bloating? Drop in the bucket compared to other kernel messages. Getting kernel
> messages in cleartext is a good thing.
> 
> It's testing a flag... not exactly complicated, just didn't want Maciej to
> complicate this one patchset with it.

I mean how much bigger does

arch/x86/kernel/cpu/capflags.c

get and, as a result, bzImage?

And what for if there's a way already which works?

I'm sure you know we have bigger fish to fry. So how about we concentrate on
Ahmed's set instead of poking on this?

Once that is reviewed and massaged and discussed and applied and tested and
we're all happy, we can spend more energy on this if still and really needed.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[Borislav Petkov]

On Fri, Mar 27, 2026 at 03:10:39PM +0000, Maciej Wieczor-Retman wrote:
> 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.

So, I just realized (yah, I am slow).

So Ahmed's patchset 

https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de

already has all the information in order to achieve what this has been trying
and more. I.e., it has all CPUID bit names and so on.

So I'd suggest we concentrate all our efforts on reviewing Ahmed's pile and if
then more functionality is needed, we can put it ontop.

Because this is simply duplicating effort and we will end up replacing this
eventually so it is all wasted effort.

So let's please concentrate all our energy there.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[Maciej Wieczor-Retman]

On 2026-03-31 at 16:02:16 +0200, Borislav Petkov wrote:
>On Fri, Mar 27, 2026 at 03:10:39PM +0000, Maciej Wieczor-Retman wrote:
>> 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.
>
>So, I just realized (yah, I am slow).
>
>So Ahmed's patchset
>
>https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de
>
>already has all the information in order to achieve what this has been trying
>and more. I.e., it has all CPUID bit names and so on.
>
>So I'd suggest we concentrate all our efforts on reviewing Ahmed's pile and if
>then more functionality is needed, we can put it ontop.
>
>Because this is simply duplicating effort and we will end up replacing this
>eventually so it is all wasted effort.
>
>So let's please concentrate all our energy there.
>
>Thx.
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

Okay, I'll stop posting this patchset and go test Ahmed's work.

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check

[Borislav Petkov]

On Tue, Mar 31, 2026 at 02:27:25PM +0000, Maciej Wieczor-Retman wrote:
> Okay, I'll stop posting this patchset and go test Ahmed's work.

Thanks a lot!

And if you still feel something's needed there, you can always base your
changes ontop.

But with the CPUID db in-tree, we'll have all the info needed and we can make
our error messages maximally useful.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Maciej Wieczor-Retman]

On 2026-03-30 at 23:41:57 +0200, Ahmed S. Darwish wrote:
>On Fri, 27 Mar 2026, H. Peter Anvin wrote:
>>
>> Thinking about it, if this is discovered at runtime, it is really too late,
>> because in a sense we have miscompiled the kernel with unwanted code (as we
>> should have compiled out these features just as with other DISABLED features.)
>>
>> This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
>> have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
>> be a good thing to print a message here saying Kconfig.cpufeatures should be
>> fixed.
>>
>> The better option, which I don't know how difficult it would be, would be to
>> make the dependencies available to Kconfig. This sounds like something that
>> would fall in the scope of Ahmed's rework rather than this patchset, though
>> (Ahmed, would you agree?)
>>
>
>Definitely!
>
>If the CPUID model sent some days ago is to be merged, (*) then all these
>dependencies should be encoded within x86-cpuid-db, especially that it now
>covers all the synthetic X86_FEATURE flags as well.

Hi! I'm still testing/browsing through the cpuid patchset. But I was wondering
what did you mean about encoding these dependencies? That they are encoded in
your patchset or that they should be?

-- 
Kind regards
Maciej Wieczór-Retman

Re: [PATCH v12 4/4] x86/cpu: Clear feature bits whose dependencies were cleared

[Ahmed S. Darwish]

On Wed, 01 Apr 2026, Maciej Wieczor-Retman wrote:
>
> On 2026-03-30 at 23:41:57 +0200, Ahmed S. Darwish wrote:
> >On Fri, 27 Mar 2026, H. Peter Anvin wrote:
> >>
> >> Thinking about it, if this is discovered at runtime, it is really too late,
> >> because in a sense we have miscompiled the kernel with unwanted code (as we
> >> should have compiled out these features just as with other DISABLED features.)
> >>
> >> This ultimately reflects a failed dependency in Kconfig.cpufeatures, which may
> >> have caused kconfig to do the Wrong Thing[TM]. So at the very least it might
> >> be a good thing to print a message here saying Kconfig.cpufeatures should be
> >> fixed.
> >>
> >> The better option, which I don't know how difficult it would be, would be to
> >> make the dependencies available to Kconfig. This sounds like something that
> >> would fall in the scope of Ahmed's rework rather than this patchset, though
> >> (Ahmed, would you agree?)
> >>
> >
> >Definitely!
> >
> >If the CPUID model sent some days ago is to be merged, (*) then all these
> >dependencies should be encoded within x86-cpuid-db, especially that it now
> >covers all the synthetic X86_FEATURE flags as well.
>
> Hi! I'm still testing/browsing through the cpuid patchset. But I was wondering
> what did you mean about encoding these dependencies? That they are encoded in
> your patchset or that they should be?
>

Just for the sake of archive follow-up, further discussion moved to here:

  https://lore.kernel.org/lkml/adz_584vlKivaECq@lx-t490

Thanks!
Ahmed