Re: [Xen-devel] [PATCH] x86/AMD: make use of CPUID leaf 0xb when available

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.19 at 14:53, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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 <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks.

> Hygon Fam18h is basically identical to AMD Fam17h at the moment, so an
> equivalent change in hygon.c should also be made.

Well, the situation on the Linux side isn't entirely clear: They do
use the function, but afterwards nevertheless override
c->phys_proc_id by that slightly odd approach. Therefore I'd
really prefer clarification on what is really needed there first,
and then also see whether the AMD side may also need further
adjustment.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel