Hi Xiaoyao, On Mon, Jan 15, 2024 at 11:51:05AM +0800, Xiaoyao Li wrote: > Date: Mon, 15 Jan 2024 11:51:05 +0800 > From: Xiaoyao Li <xiaoyao.li@xxxxxxxxx> > Subject: Re: [PATCH v7 02/16] i386/cpu: Use APIC ID offset to encode cache > topo in CPUID[4] > > On 1/11/2024 4:43 PM, Zhao Liu wrote: > > Hi Xiaoyao, > > > > On Wed, Jan 10, 2024 at 05:31:28PM +0800, Xiaoyao Li wrote: > > > Date: Wed, 10 Jan 2024 17:31:28 +0800 > > > From: Xiaoyao Li <xiaoyao.li@xxxxxxxxx> > > > Subject: Re: [PATCH v7 02/16] i386/cpu: Use APIC ID offset to encode cache > > > topo in CPUID[4] > > > > > > On 1/8/2024 4:27 PM, Zhao Liu wrote: > > > > From: Zhao Liu <zhao1.liu@xxxxxxxxx> > > > > > > > > Refer to the fixes of cache_info_passthrough ([1], [2]) and SDM, the > > > > CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26] should use the > > > > nearest power-of-2 integer. > > > > > > > > The nearest power-of-2 integer can be calculated by pow2ceil() or by > > > > using APIC ID offset (like L3 topology using 1 << die_offset [3]). > > > > > > > > But in fact, CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26] > > > > are associated with APIC ID. For example, in linux kernel, the field > > > > "num_threads_sharing" (Bits 25 - 14) is parsed with APIC ID. > > > > > > And for > > > > another example, on Alder Lake P, the CPUID.04H:EAX[bits 31:26] is not > > > > matched with actual core numbers and it's calculated by: > > > > "(1 << (pkg_offset - core_offset)) - 1". > > > > > > could you elaborate it more? what is the value of actual core numbers on > > > Alder lake P? and what is the pkg_offset and core_offset? > > > > For example, the following's the CPUID dump of an ADL-S machine: > > > > CPUID.04H: > > > > 0x00000004 0x00: eax=0xfc004121 ebx=0x01c0003f ecx=0x0000003f edx=0x00000000 > > 0x00000004 0x01: eax=0xfc004122 ebx=0x01c0003f ecx=0x0000007f edx=0x00000000 > > 0x00000004 0x02: eax=0xfc01c143 ebx=0x03c0003f ecx=0x000007ff edx=0x00000000 > > 0x00000004 0x03: eax=0xfc1fc163 ebx=0x0240003f ecx=0x00009fff edx=0x00000004 > > 0x00000004 0x04: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 > > > > > > CPUID.1FH: > > > > 0x0000001f 0x00: eax=0x00000001 ebx=0x00000001 ecx=0x00000100 edx=0x0000004c > > 0x0000001f 0x01: eax=0x00000007 ebx=0x00000014 ecx=0x00000201 edx=0x0000004c > > 0x0000001f 0x02: eax=0x00000000 ebx=0x00000000 ecx=0x00000002 edx=0x0000004c > > > > The CPUID.04H:EAX[bits 31:26] is 63. > > From CPUID.1FH.00H:EAX[bits 04:00], the core_offset is 1, and from > > CPUID.1FH.01H:EAX[bits 04:00], the pkg_offset is 7. > > > > Thus we can verify that the above equation as: > > > > 1 << (0x7 - 0x1) - 1 = 63. > > > > "Maximum number of addressable IDs" refers to the maximum number of IDs > > that can be enumerated in the APIC ID's topology layout, which does not > > necessarily correspond to the actual number of topology domains. > > > > you still don't tell how many core numbers on Alder lake P. > > I guess the number is far smaller than 64, which is not matched with (63 + > 1) > There're 8 P cores (with 2 threads per P core) + 4 E cores (with 1 thread per E core) for this machine (ADL-S). Thus this field only shows the theoretical size of the id space and does not reflect the actual cores numbers. Thanks, Zhao
