On 09-01-2026 14:33, Zhao Liu wrote:
> On Thu, Jan 08, 2026 at 04:03:12PM +0530, Shivansh Dhiman wrote:
>> Date: Thu, 8 Jan 2026 16:03:12 +0530
>> From: Shivansh Dhiman <[email protected]>
>> Subject: Re: [PATCH 1/5] i386: Implement CPUID 0x80000026
>>
>> Hi Zhao,
>>
>> On 07-01-2026 12:55, Zhao Liu wrote:
>>> Hi Shivansh,
>>>
>>> Sorry for late reply.
>>>
>>> On Fri, Nov 21, 2025 at 08:34:48AM +0000, Shivansh Dhiman wrote:
>>>> Date: Fri, 21 Nov 2025 08:34:48 +0000
>>>> From: Shivansh Dhiman <[email protected]>
>>>> Subject: [PATCH 1/5] i386: Implement CPUID 0x80000026
>>>> X-Mailer: git-send-email 2.43.0
>>>>
>>>> Implement CPUID leaf 0x80000026 (AMD Extended CPU Topology). It presents
>>>> the
>>>> complete topology information to guests via a single CPUID with multiple
>>>> subleafs, each describing a specific hierarchy level, viz. core, complex,
>>>> die, socket.
>>>>
>>>> Note that complex/CCX level relates to "die" in QEMU, and die/CCD level is
>>>> not supported in QEMU yet. Hence, use CCX at CCD level until diegroups are
>>>> implemented.
>>>
>>> I'm trying to understand AMD's topology hierarchy by comparing it to the
>>> kernel's arch/x86/kernel/cpu/topology_ext.c file:
>>>
>>> static const unsigned int topo_domain_map_0b_1f[MAX_TYPE_1F] = {
>>> [SMT_TYPE] = TOPO_SMT_DOMAIN,
>>> [CORE_TYPE] = TOPO_CORE_DOMAIN,
>>> [MODULE_TYPE] = TOPO_MODULE_DOMAIN,
>>> [TILE_TYPE] = TOPO_TILE_DOMAIN,
>>> [DIE_TYPE] = TOPO_DIE_DOMAIN,
>>> [DIEGRP_TYPE] = TOPO_DIEGRP_DOMAIN,
>>> };
>>>
>>> static const unsigned int topo_domain_map_80000026[MAX_TYPE_80000026] = {
>>> [SMT_TYPE] = TOPO_SMT_DOMAIN,
>>> [CORE_TYPE] = TOPO_CORE_DOMAIN,
>>> [AMD_CCD_TYPE] = TOPO_TILE_DOMAIN,
>>> [AMD_SOCKET_TYPE] = TOPO_DIE_DOMAIN,
>>> };
>>
>> These mappings reuse some original names (SMT_TYPE and CORE_TYPE) along with
>> the
>> new ones (AMD_CCD_TYPE and AMD_SOCKET_TYPE). I think to avoid defining more
>> AMD
>> specific types the original names are used. So, essentially you can read them
>> like this:
>>
>> static const unsigned int topo_domain_map_80000026[MAX_TYPE_80000026] = {
>> [AMD_CORE_TYPE] = TOPO_SMT_DOMAIN,
>> [AMD_CCX_TYPE] = TOPO_CORE_DOMAIN,
>> [AMD_CCD_TYPE] = TOPO_TILE_DOMAIN,
>> [AMD_SOCKET_TYPE] = TOPO_DIE_DOMAIN,
>> };
>
> Thank you! It's clear and I see the difference.
>
>>> What particularly puzzles me is that "complex" isn't listed here, yet it
>>> should be positioned between "core" and CCD. Does this mean complex
>>> actually corresponds to kernel's module domain?
>>
>> There is a nuance with CPUID 80000026h related to the shifting of x2APIC ID.
>> According to APM, EAX[4:0] tells us the number of bits to shift x2APIC ID
>> right
>> to get unique topology ID of the next instance of the current level type.
>>
>> So, all logical processors with the same next level ID share current level.
>> This
>> results in mapping the Nth level type to (N-1)th domain. This is unlike
>> Intel's
>> CPUID 0xb which maps Nth level type to Nth domain.
>
> Yes, it's the core difference. I think it's better to have a helper
> clearly define the mapping between QEMU general topo level v.s. AMD topo
> types, similar to cpuid1f_topo_type().
Yeah. That can be done.
>
>> Back to your question, the complex is same as tile since both represent a L3
>> cache boundary.
>
> Yeah, this makes sense. CCD->die, and CCX->tile.
>
>>> Back to QEMU, now CCX is mapped as QEMU's die level, and AMD socket is
>>> mapped
>>> to socket level. Should we revisit QEMU's topology level mapping for AMD, to
>>> align with the above topology domain mapping?
>>>
>>> If we want to go further: supporting CCD configuration would be quite
>>> tricky. I feel that adding another new parameter between the smp.dies
>>> and smp.sockets would create significant confusion.
>>
>> The current kernel doesn't have sensitivity to a level between L3 boundary
>> and
>> socket. Also, most production systems in current AMD CPU landscape have
>> CCD=CCX.
>> Only a handful of models feature CCD=2CCX, so this isn't an immediate
>> pressing need.
>>
>> In QEMU's terminology, socket represents an actual socket and die represents
>> the
>> L3 cache boundary. There is no intermediate level between them. Looking
>> ahead,
>> when more granular topology information (like CCD) becomes necessary for VMs,
>> introducing a "diegroup" level would be the logical approach. This level
>> would
>> fit naturally between die and socket, as its role cannot be fulfilled by
>> existing topology levels.
>
> With your nice clarification, I think this problem has become a bit easier.
>
> In fact, we can consider that CCD=CCX=die is currently the default
> assumption in QEMU. When future implementations require distinguishing between
> these CCD/CCX concepts, we can simply introduce an additional "smp.tiles" and
> map CCX to it. This may need a documentation or a compatibility option, but I
> believe these extra efforts are worthwhile.
>
> And "smp.tiles" means "how many tiles in a die", so I feel it's perfect
> to describe CCX.
That indeed looks like a cleaner solution. However, I'm concerned about
retaining compatibility with existing "dies". But yeah, that's a task for a
later time.
>
>> Also, I was looking at Intel's SDM Vol. 2A "Instruction Set Reference, A-Z"
>> Table 3-8. "Information Returned by CPUID Instruction". The presence of a
>> "diegrp" level between die and socket suggests Intel has already recognized
>> the
>> need for this intermediate topology level. If this maps to a similar concept
>> as
>> AMD's CCD, it would indeed strengthen the case for introducing a new level
>> in QEMU.
>
> SDM has "diedrp" but currently no product is using it. So it's hard for me
> to say what this layer will look like in the future, especially with
> topology-aware features/MSRs. Therefore, I prefer to add the "tile" if
> needed, as it aligns better with the existing hierarchy definition. Anyway,
> this is the future topic (though it is related with the last statement in your
> commit message). At least for now, how to map the AMD hierarchy is fairly
> clear.
Ack.
>
> Thanks,
> Zhao
>
