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

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