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

["H. Peter Anvin" <hpa@zytor.com>]

On 2026-02-12 07:33, 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.
> 
> 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.

I am explicitly NOT suggesting this for this patchset, but in the future, I
would also like to see even the CPUID flags NOT included in /proc/cpuinfo to
be in the table, for the purpose of displaying kernel messages. I fully agree
that including them in /proc/cpuinfo is an unnecessary burden, but it would
still be good to be able to print them in messages in cleartext, *especially*
for when bits get reassigned or recycled.

I would also like to see the module ID strings for CPU features change from
using the numeric representation to the string representation for the same
reasons.

However, let me also say this: I don't think it makes any sense whatsoever to
aggressively compact those CPUID leaves that are likely to grow more bits in
the future (which aren't everyone, of course). It isn't like these words are
particularly expensive.

	-hpa