Re: [PATCH v7 004/120] x86/cpuid: Introduce <asm/cpuid/leaf_types.h>

[Borislav Petkov]

On Tue, Jun 02, 2026 at 11:15:06PM +0200, Ahmed S. Darwish wrote:
> On Tue, 02 Jun 2026, Borislav Petkov wrote:
> >
> > Well, I think it would be best if in such cases we do both: send it against
> > x86-cpuid-db and then generate the kernel patch from it. So that we don't lose
> > time.
> >
> > I wouldn't want for 7.2 to release with those typos in a user-visible header.
> > I mean, there's time until 7.2 releases but it would be good to send a fixed
> > and complete pull request to Linus already in 2-3 weeks time.
> 
> I've pushed an x86-cpuid-db release about an hour after receiving Maciej's
> patch.  And that was mostly because of adding more fixes in the same spirit
> as Maciej's findings.
> 
> So I would suggest a "wait and see" approach.  I don't think that the
> frequency of adding new bits or fixes to the database will be that high.
> 
> There is also a git-describe tag on top of leaf_types.h and kcpuid.csv.
> The idea was to encourage people that submitted kernel patches touching
> these files are either from a pushed x86-cpuid-db release or at least from
> its tip branch.
> 
> I'm definitely biased here, but I'm optimistic that this can smoothly work
> out.  In the end, the x86 maintainers still hold all the keys here, in the
> sense that there is no risk of slowing down anything, especially in
> emergency cases (say a new HW vulnerability.)

My only goal is to have an official release with all known issues addressed
and not release something which is clearly wrong and luserspace starts
depending on it and then we'll have to support it forever.

And then we start sending fixes back'n'forth.

We can wait and see all we want but those headers in the kernel better be
fixed properly. How we update the database in the background is at our leisure
and there we can take our time.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette