Re: [PATCH v7 013/120] x86/cpu: Use parsed CPUID(0x80000000)

"Ahmed S. Darwish" <[email protected]> Fri, 12 Jun 2026 21:49:39 +0200
Newsgroups dev.linux.lists.x86-cpuid,org.kernel.vger.linux-kernel
Message-ID <aixi07o7c3s7EOaX@lx-t490>
On Tue, 02 Jun 2026, Borislav Petkov wrote:
>
> So I went forward to look a bit... the whole point of that code in
> microcode_check() is to rescan the *full* CPUID leafage into a separate copy
> of cpuinfo_x86.cpuid.
>
> And then compare the old and the new one and see whether microcode changed
> anything.
>
> I see you're doing something in patch 106 and I'll know much better when I get
> to it but my gut feeling right now tells me, you should leave that code alone
> and do it separately, ontop, when we start removing ->x86_capability.

Patch #16:

    x86/cpuid: Split parser tables and add vendor-qualified parsing
    https://lore.kernel.org/lkml/[email protected]

initializes the CPUID table at get_cpu_caps() through cpuid_scan_cpu().

I'll just move the group CPUID(0x8000*) patches after that patch, and
everything should be handled nicely.

>
> AFAICT, the CPUID parser can simply do:
>
>         struct cpuid_table *table = &second_copy.cpuid;
>
>         cpuid_fill_table(table, cpuid_parse_entries, nr_entries);
>
> and fill the table. Then we'll need to go over that table and compare it with
> the existing one. I guess adding a __cmp_range() or so in the same manner like
> you do iterate over ranges right now.
>
> Something along those lines I guess...
>

As you hinted at, this is indeed dealt with by the end of the series.  I
actually tested it back then to make sure the before/after microcode
comparisons are still working.

So, I fully agree, let's postpone this until we reach there.

Thanks,
Ahmed