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(-)
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.