Re: [PATCH 6.18.y] x86/cpufeatures: Make X86_FEATURE leaf 17 Linux-specific

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, Nov 12 2026 at 15:33, Borislav Petkov wrote:
> On Fri, Nov 13, 2026 at 12:09:03AM +0100, Thomas Gleixner wrote:
>> Even if a new leaf has only _ONE_ bit defined then it's a new leaf. This
>> whole "save space" nonsense has been source of a gazillion of subtle
>> bugs in the past and we just continue to "fix" them instead of actually
>> tackling the underlying problem.
>> 
>> Linux specific leafs want to be in a space which is reserved by
>> hardware for software purposes and not arbitrarily hacked into "holes".
>> 
>> Hardware defined leafs have to be represented by a proper entry even if
>> there is only one relevant bit in a leaf.
>
> Are you saying we should get rid of scattered.c?

Yes. It's an abomination as you know very well.

> Well, as a matter of fact, after stopping this silly nonsense of having to add
> a cpufeatures.h leaf just to advertise feature bits to a guests, the space
> saving is not really important anymore. We're much better there.
>
> So I could whack scattered.c, we make it a rule to allocate a new
> x86_capability leaf when we need it and then we will switch to the stuff Ahmed
> has been working on eventually, when we get that upstreamed.

Emphasis on eventually.

So another twenty years to actually have a proper design in place for
something which just resulted in duct tape layers since the initial
CPUID/feature management design mistake was made twenty years ago.

Until we get there we just add more duct tape which interferes with the
cleanup, right?

> Anything else missing?

Yes. The fact that it's ridiculous that we still have to debate this.

The time wasted on that, the time wasted by people to decode the subtle
bugs and the amount of AI tokens wasted to come up with more duct tape
fixes is at least an order of magnitude more expensive than funding the
completion of the overhaul.

But I just "work" here so I might be missing something important which
justifies that ...

Thanks,

        tglx