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@xxxxxxxxxxxxx