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

[H. Peter Anvin]

On 2026-03-23 10:59, Borislav Petkov wrote:
> On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote:
>> Clearing the compile time disabled bits is fairly low effort since it's just
>> initializing the cpu_caps_cleared[].
> 
> and cpu_caps_cleared[] is consulted in apply_forced_caps().
> 
>> To validate the whole cpuid_deps[] array and add relevant bits to
>> cpu_caps_cleared[] would probably require adding another loop that would
>> check all of the entries. Since now only SGX has this problem I didn't think
>> it warranted adding more than this check in check_cpufeature_deps().
> 
> So we're going to do half-baked solution again and it'll come to bite us in
> the ass later?
> 
> How about we hammer it out properly once and for all?
> 

One could argue that the Right Thing[TM] to do would be to encode the
dependencies in a file that can be processed at compile time, and have those
features explicitly added to the enabled and disabled masks, basically
augmenting Kconfig.cpufeatures.

The sanest way to do that would probably be to move cpuid_deps[] from
cpuid-deps.c into a standalone file which can be processed by
cpufeaturesmask.awk or equivalent.

I do have to say that using awk for these things, especially being restricted
to POSIX awk, is really awful as it really is pushing the limits of that tool.
String processing in C is most definitely no fun either -- the single biggest
shortcoming of what is otherwise one of my favorite languages -- but it
*would* also be possible to refactor cpuid-deps.c so that it can be compiled
in user space and linked with a C tool that would replace cpufeaturesmask.awk,
mkcapflags.sh, and boot/mkcpustr.c.

This seemed to me to be a bit excessive in terms of churn and complexity, but
perhaps this is what you are looking for?

	-hpa