On 07/06/2019 13:50, Jan Beulich wrote:
> Initially I did simply stumble across a backport of Linux commit
> e0ceeae708 ("x86/CPU/hygon: Fix phys_proc_id calculation logic for
> multi-die processors") to our kernels. There I got puzzled by the claim
> that a similar change isn't needed on the AMD side. As per the web page
> cited [1], there aren't supposed to be affected AMD processors, but
> according to my reading there are: The EPYC 7000 series comes with 8,
> 16, 24, or 32 cores, which I imply to be 1, 2, 3, or 4 die processors.
> And many of them have "1P/2P" in the "socket count" column. Therefore
> our calculation, being based on CPUID.80000008.EBX[15:12], would be
> similarly wrong on such 2-socket 1- or 2-die systems.
>
> Checking Linux code I then found that they don't even rely on the
> calculation we currently use anymore, at least not in the case when
> leaf 0xb is available (which is the case on Fam17). Let's follow
> Suravee's Linux commit 3986a0a805 ("x86/CPU/AMD: Derive CPU topology
> from CPUID function 0xB when available") in this regard to address this.
>
> To avoid logging duplicate information, make the function return bool.
> Move its and detect_ht()'s declaration to a private header at the same
> time.
>
> [1] https://www.amd.com/en/products/specifications/processors
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
Hygon Fam18h is basically identical to AMD Fam17h at the moment, so an
equivalent change in hygon.c should also be made.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
