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