Re: [PATCH 6.6.y] x86/cpu/amd: Always try detect_extended_topology() on AMD processors

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Sep 22, 2025 at 12:00:08PM +0530, K Prateek Nayak wrote:
> Hello Greg,
> 
> On 9/21/2025 10:45 PM, Greg KH wrote:
> > On Mon, Sep 15, 2025 at 05:18:25AM +0000, K Prateek Nayak wrote:
> >> commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.
> 
> [..snip..]
> 
> >>
> >>   [ prateek: Adapted the fix from the original commit to stable kernel
> >>     which doesn't contain the x86 topology rewrite, renamed
> >>     cpu_parse_topology_ext() with the erstwhile
> >>     detect_extended_topology() function in commit message, dropped
> >>     references to extended topology leaf 0x80000026 which the stable
> >>     kernels aren't aware of, make a note of "cpu_die_id" parsing
> >>     nuances in detect_extended_topology() and why AMD processors should
> >>     still rely on TOPOEXT leaf for "cpu_die_id". ]
> > 
> > That's a lot of changes.  Why not just use a newer kernel for this new
> > hardware?  Why backport this in such a different way?
> 
> We are mostly solving problems of virtualization with this one for
> now.
> 
> QEMU can create a guest with more than 256vCPUs and tell the guest that
> each CPU is an individual core leading to weird handling of the
> CPUID 0x8000001e leaf when CoreId > 255
> https://github.com/qemu/qemu/commit/35ac5dfbcaa4b.
> 
> QEMU expects the guest to discover the topology using 0xb leaf which,
> the PPR says, is not dependent on the TOPOEXT feature.

Great, so these are new guests, use a new kernel!  :)

> > That is going to
> > cause other changes in the future to be harder to backport in the
> > future.
> 
> Thomas thinks this fix should be backported
> (https://lore.kernel.org/all/87o6rirrvc.ffs@tglx/) and for any future
> conflicts in this area, I'll be more than happy to help out resolve
> them.

Ok, if you get the maintainers to sign off on the change, I'll be glad
to take the patch.

thanks,

greg k-h