[PATCH 0/5] i386: Add support for CPUID 0x80000026 and Bus Lock Detect

[PATCH 0/5] i386: Add support for CPUID 0x80000026 and Bus Lock Detect

[Shivansh Dhiman]

This series introduces support for AMD's Extended CPU Topology CPUID leaf
(0x80000026) and Bus Lock Detect in QEMU. 

AMD's Extended CPU Topology 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. 

A new CPU property is added to gate this CPUID to AMD Zen 4+ CPUs. New
versions of EPYC-Genoa and EPYC-Turin are also created to include the
property. Tested the VM migrations with both newer and older CPU versions.

Bus Lock Detect signals when a process has acquired a bus lock. It is
enumerated with cpuid Fn0000_0007_ECX_x0 bit [24 / BUSLOCKTRAP]. It can be
enabled through MSR_IA32_DEBUGCTLMSR. When enabled, hardware clears DR6[11]
and raises a #DB exception on occurrence of Bus Lock if CPL > 0. More detail
about the feature can be found in AMD APM[1]. 

It is enabled for EPYC-Turin-v2. The KVM patch enabling Bus Lock Detect
for SVM can be found here:
https://lore.kernel.org/kvm/20251121081228.426974-1-shivansh.dhiman@amd.com/

Patches are prepared on master (4481234e).

[1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
     2023, Vol 2, 13.1.3.6 Bus Lock Trap
     https://bugzilla.kernel.org/attachment.cgi?id=304653

Best regards,
Shivansh
---
Ravi Bangoria (1):
  i386: Add Bus Lock Detect support

Shivansh Dhiman (4):
  i386: Implement CPUID 0x80000026
  i386: Add CPU property x-force-cpuid-0x80000026
  i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU
  i386: Add Bus Lock Detect support for EPYC-Turin-v2 model

 target/i386/cpu.c     | 103 ++++++++++++++++++++++++++++++++++++++++++
 target/i386/cpu.h     |  19 ++++++++
 target/i386/kvm/kvm.c |  21 ++++++++-
 3 files changed, 141 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH 1/5] i386: Implement CPUID 0x80000026

[Shivansh Dhiman]

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.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 target/i386/cpu.c     | 76 +++++++++++++++++++++++++++++++++++++++++++
 target/i386/kvm/kvm.c | 17 ++++++++++
 2 files changed, 93 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 641777578637..b7827e448aa5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -495,6 +495,78 @@ static void encode_topo_cpuid1f(CPUX86State *env, uint32_t count,
     assert(!(*eax & ~0x1f));
 }
 
+/*
+ * CPUID_Fn80000026: Extended CPU Topology
+ *
+ * EAX Bits Description
+ * 31:5 Reserved
+ *  4:0 Number of bits to shift Extended APIC ID right to get a unique
+ *      topology ID of the current hierarchy level.
+ *
+ * EBX Bits Description
+ * 31:16 Reserved
+ * 15:0  Number of logical processors at the current hierarchy level.
+ *
+ * ECX Bits Description
+ * 31:16 Reserved
+ * 15:8  Level Type. Values:
+ *       Value   Description
+ *       0h      Reserved
+ *       1h      Core
+ *       2h      Complex
+ *       3h      Die
+ *       4h      Socket
+ *       FFh-05h Reserved
+ * 7:0   Input ECX
+ *
+ * EDX Bits Description
+ * 31:0 Extended APIC ID of the logical processor
+ */
+static void encode_topo_cpuid80000026(CPUX86State *env, uint32_t count,
+                                X86CPUTopoInfo *topo_info,
+                                uint32_t *eax, uint32_t *ebx,
+                                uint32_t *ecx, uint32_t *edx)
+{
+    X86CPU *cpu = env_archcpu(env);
+    uint32_t shift, nr_logproc, lvl_type;
+
+    switch (count) {
+    case 0:
+        shift = apicid_core_offset(topo_info);
+        nr_logproc = num_threads_by_topo_level(topo_info, CPU_TOPOLOGY_LEVEL_CORE);
+        lvl_type = 1;
+        break;
+
+    case 1:
+        shift = apicid_die_offset(topo_info);
+        nr_logproc = num_threads_by_topo_level(topo_info, CPU_TOPOLOGY_LEVEL_DIE);
+        lvl_type = 2;
+        break;
+
+    case 2:
+        shift = apicid_die_offset(topo_info);
+        nr_logproc = num_threads_by_topo_level(topo_info, CPU_TOPOLOGY_LEVEL_DIE);
+        lvl_type = 3;
+        break;
+
+    case 3:
+        shift = apicid_pkg_offset(topo_info);
+        nr_logproc = num_threads_by_topo_level(topo_info, CPU_TOPOLOGY_LEVEL_SOCKET);
+        lvl_type = 4;
+        break;
+
+    default:
+        shift = 0;
+        nr_logproc = 0;
+        lvl_type = 0;
+    }
+
+    *eax = shift & 0x1F;
+    *ebx = nr_logproc;
+    *ecx = ((lvl_type & 0xFF) << 8) | (count & 0xFF);
+    *edx = cpu->apic_id;
+}
+
 /* Encode cache info for CPUID[0x80000005].ECX or CPUID[0x80000005].EDX */
 static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
 {
@@ -8554,6 +8626,10 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
                                                  R_EBX) & 0xf;
         }
         break;
+    case 0x80000026:
+        /* AMD Extended CPU Topology */
+        encode_topo_cpuid80000026(env, count, topo_info, eax, ebx, ecx, edx);
+        break;
     case 0xC0000000:
         *eax = env->cpuid_xlevel2;
         *ebx = 0;
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 60c798113823..ed3d40bf073e 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -2037,6 +2037,23 @@ uint32_t kvm_x86_build_cpuid(CPUX86State *env, struct kvm_cpuid_entry2 *entries,
                 c = &entries[cpuid_i++];
             }
             break;
+        case 0x80000026:
+            /* Query for all AMD extended topology information leaves */
+            for (j = 0; ; j++) {
+                c->function = i;
+                c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+                c->index = j;
+                cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
+
+                if (((c->ecx >> 8) & 0xFF) == 0) {
+                    break;
+                }
+                if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+                    goto full;
+                }
+                c = &entries[cpuid_i++];
+            }
+            break;
         default:
             c->function = i;
             c->flags = 0;
-- 
2.43.0

[PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026

[Shivansh Dhiman]

Introduce new CPU property x-force-cpuid-0x80000026 using which the CPUID
0x80000026 is enabled. It defaults to false.

If a vCPU's model is host, then CPUID is enabled based on CPU family/model.
Implement x86_is_amd_zen4_or_above() helper to detect Zen4+ CPUs using
family/model.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 target/i386/cpu.c |  8 ++++++++
 target/i386/cpu.h | 18 ++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index b7827e448aa5..01c4da7cf134 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
         if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
             x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
         }
+
+        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
+        if (cpu->force_cpuid_0x80000026 ||
+            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {
+            x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x80000026);
+        }
     }
 
     /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */
@@ -10133,6 +10139,8 @@ static const Property x86_cpu_properties[] = {
                      arch_cap_always_on, false),
     DEFINE_PROP_BOOL("x-pdcm-on-even-without-pmu", X86CPU,
                      pdcm_on_even_without_pmu, false),
+    DEFINE_PROP_BOOL("x-force-cpuid-0x80000026", X86CPU, force_cpuid_0x80000026,
+                     false),
 };
 
 #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index cee1f692a1c3..0fecca26dc4a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2292,6 +2292,9 @@ struct ArchCPU {
     /* Force to enable cpuid 0x1f */
     bool force_cpuid_0x1f;
 
+    /* Force to enable cpuid 0x80000026 */
+    bool force_cpuid_0x80000026;
+
     /* Enable auto level-increase for all CPUID leaves */
     bool full_cpuid_auto_level;
 
@@ -2879,6 +2882,21 @@ void x86_cpu_xsave_all_areas(X86CPU *cpu, void *buf, uint32_t buflen);
 uint32_t xsave_area_size(uint64_t mask, bool compacted);
 void x86_update_hflags(CPUX86State* env);
 
+static inline bool x86_is_amd_zen4_or_above(X86CPU *cpu)
+{
+    uint32_t family = x86_cpu_family(cpu->env.cpuid_version);
+    uint32_t model = x86_cpu_model(cpu->env.cpuid_version);
+
+    if (!IS_AMD_CPU(&cpu->env) || family < 0x19) {
+        return false;
+    }
+    if (family > 0x19) {
+        return true;
+    }
+    return (model >= 0x10 && model <= 0x1f) ||
+           (model >= 0x60 && model <= 0xaf);
+}
+
 static inline bool hyperv_feat_enabled(X86CPU *cpu, int feat)
 {
     return !!(cpu->hyperv_features & BIT(feat));
-- 
2.43.0

[PATCH 3/5] i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU

[Shivansh Dhiman]

Enable CPUID leaf 0x80000026 (Extended CPU Topology) for AMD Zen4+ processors,
i.e, Genoa and above. Add version 3 to EPYC-Genoa and version 2 to EPYC-Turin
CPU models with x-force-cpuid-0x80000026 property enabled.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 target/i386/cpu.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 01c4da7cf134..12500d6b7bed 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6505,6 +6505,13 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                 },
                 .cache_info = &epyc_genoa_v2_cache_info
             },
+            {
+                .version = 3,
+                .props = (PropValue[]) {
+                    { "x-force-cpuid-0x80000026", "on" },
+                    { /* end of list */ }
+                }
+            },
             { /* end of list */ }
         }
     },
@@ -6735,6 +6742,17 @@ static const X86CPUDefinition builtin_x86_defs[] = {
         .xlevel = 0x80000022,
         .model_id = "AMD EPYC-Turin Processor",
         .cache_info = &epyc_turin_cache_info,
+        .versions = (X86CPUVersionDefinition[]) {
+            { .version = 1 },
+            {
+                .version = 2,
+                .props = (PropValue[]) {
+                    { "x-force-cpuid-0x80000026", "on" },
+                    { /* end of list */ }
+                }
+            },
+            { /* end of list */ }
+        }
     },
 };
 
-- 
2.43.0

[PATCH 4/5] i386: Add Bus Lock Detect support

[Shivansh Dhiman]

From: Ravi Bangoria <ravi.bangoria@amd.com>

Bus Lock Detect is enumerated with cpuid Fn0000_0007_ECX_x0 
bit [24 / BUSLOCKTRAP]. It can be enabled through MSR_IA32_DEBUGCTLMSR.
When enabled, hardware clears DR6[11] and raises a #DB exception on
occurrence of Bus Lock if CPL > 0. More detail about the feature can be
found in AMD APM[1].

Qemu supports remote debugging through host gdb (the "gdbstub" facility)
where some of the remote debugging features like instruction and data
breakpoints relies on the same hardware infrastructure (#DB, DR6 etc.)
that Bus Lock Detect also uses. Instead of handling internally, KVM
forwards #DB to Qemu when remote debugging is ON and #DB is being
intercepted. It's Qemu's responsibility to re-inject the exception to
guest when some of the exception source bits (in DR6) are not being
handled by Qemu remote debug handler. Bus Lock Detect is one such case.

[1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
     2023, Vol 2, 13.1.3.6 Bus Lock Trap
     https://bugzilla.kernel.org/attachment.cgi?id=304653

Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 target/i386/cpu.h     | 1 +
 target/i386/kvm/kvm.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 0fecca26dc4a..852b3a33b54d 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -276,6 +276,7 @@ typedef enum X86Seg {
                 | CR4_SMEP_MASK | CR4_SMAP_MASK | CR4_PKE_MASK | CR4_PKS_MASK \
                 | CR4_LAM_SUP_MASK | CR4_FRED_MASK))
 
+#define DR6_BLD         (1 << 11)
 #define DR6_BD          (1 << 13)
 #define DR6_BS          (1 << 14)
 #define DR6_BT          (1 << 15)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index ed3d40bf073e..00c44c2de650 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -5864,14 +5864,14 @@ static int kvm_handle_debug(X86CPU *cpu,
     } else if (kvm_find_sw_breakpoint(cs, arch_info->pc)) {
         ret = EXCP_DEBUG;
     }
-    if (ret == 0) {
+    if (ret == 0 || !(arch_info->dr6 & DR6_BLD)) {
         cpu_synchronize_state(cs);
         assert(env->exception_nr == -1);
 
         /* pass to guest */
         kvm_queue_exception(env, arch_info->exception,
                             arch_info->exception == EXCP01_DB,
-                            arch_info->dr6);
+                            ret == 0 ? arch_info->dr6 ^ DR6_BLD : DR6_BLD);
         env->has_error_code = 0;
     }
 
-- 
2.43.0

[PATCH 5/5] i386: Add Bus Lock Detect support for EPYC-Turin-v2 model

[Shivansh Dhiman]

Enable the Bus Lock Detect feature for the EPYC-Turin-v2 CPU model to
match the hardware capabilities of AMD Turin processors. This feature
allows detection of split locks and bus locks, which can cause
performance degradation in multi-core systems.

The bus-lock-detect feature is part of the architectural capabilities
exposed through CPUID and should be enabled by default for Turin v2
and later CPU models.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 target/i386/cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 12500d6b7bed..660b9c2a98b6 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6748,6 +6748,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                 .version = 2,
                 .props = (PropValue[]) {
                     { "x-force-cpuid-0x80000026", "on" },
+                    { "bus-lock-detect", "on" },
                     { /* end of list */ }
                 }
             },
-- 
2.43.0

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Zhao Liu]

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 <shivansh.dhiman@amd.com>
> 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,
};

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?

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.

> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  target/i386/cpu.c     | 76 +++++++++++++++++++++++++++++++++++++++++++
>  target/i386/kvm/kvm.c | 17 ++++++++++
>  2 files changed, 93 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 641777578637..b7827e448aa5 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -495,6 +495,78 @@ static void encode_topo_cpuid1f(CPUX86State *env, uint32_t count,
>      assert(!(*eax & ~0x1f));
>  }
>  
> +/*
> + * CPUID_Fn80000026: Extended CPU Topology
> + *
> + * EAX Bits Description
> + * 31:5 Reserved
> + *  4:0 Number of bits to shift Extended APIC ID right to get a unique
> + *      topology ID of the current hierarchy level.
> + *
> + * EBX Bits Description
> + * 31:16 Reserved
> + * 15:0  Number of logical processors at the current hierarchy level.
> + *
> + * ECX Bits Description
> + * 31:16 Reserved
> + * 15:8  Level Type. Values:
> + *       Value   Description
> + *       0h      Reserved
> + *       1h      Core
> + *       2h      Complex
> + *       3h      Die
> + *       4h      Socket
> + *       FFh-05h Reserved
> + * 7:0   Input ECX
> + *
> + * EDX Bits Description
> + * 31:0 Extended APIC ID of the logical processor
> + */

I feel this long comment is not necessary, since people could check APM for
details. Or this description could be included in commit message.

> +static void encode_topo_cpuid80000026(CPUX86State *env, uint32_t count,
> +                                X86CPUTopoInfo *topo_info,
> +                                uint32_t *eax, uint32_t *ebx,
> +                                uint32_t *ecx, uint32_t *edx)

Regards,
Zhao

Re: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026

[Zhao Liu]

On Fri, Nov 21, 2025 at 08:34:49AM +0000, Shivansh Dhiman wrote:
> Date: Fri, 21 Nov 2025 08:34:49 +0000
> From: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Subject: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026
> X-Mailer: git-send-email 2.43.0
> 
> Introduce new CPU property x-force-cpuid-0x80000026 using which the CPUID
> 0x80000026 is enabled. It defaults to false.
> 
> If a vCPU's model is host, then CPUID is enabled based on CPU family/model.
> Implement x86_is_amd_zen4_or_above() helper to detect Zen4+ CPUs using
> family/model.
> 
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  target/i386/cpu.c |  8 ++++++++
>  target/i386/cpu.h | 18 ++++++++++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b7827e448aa5..01c4da7cf134 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>          if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
>          }
> +
> +        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
> +        if (cpu->force_cpuid_0x80000026 ||
> +            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {

I understand you want to address max/host CPU case here, but it's still
may not guarentee the compatibility with old QEMU PC mahinces, e.g.,
boot a old PC machine on v11.0 QEMU, it can still have this leaf.

So it would be better to add a compat option to disable 0x80000026 for
old PC machines by default.

If needed, to avoid unnecessarily enabling extended CPU topology, I think
it's possible to implement a check similar to x86_has_cpuid_0x1f().

> +            x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x80000026);
> +        }
>      }

Thanks,
Zhao

Re: [PATCH 3/5] i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU

[Zhao Liu]

On Fri, Nov 21, 2025 at 08:34:50AM +0000, Shivansh Dhiman wrote:
> Date: Fri, 21 Nov 2025 08:34:50 +0000
> From: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Subject: [PATCH 3/5] i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU
> X-Mailer: git-send-email 2.43.0
> 
> Enable CPUID leaf 0x80000026 (Extended CPU Topology) for AMD Zen4+ processors,
> i.e, Genoa and above. Add version 3 to EPYC-Genoa and version 2 to EPYC-Turin
> CPU models with x-force-cpuid-0x80000026 property enabled.
> 
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  target/i386/cpu.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Shivansh Dhiman]

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 <shivansh.dhiman@amd.com>
>> 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,
};

> 
> 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.

Back to your question, the complex is same as tile since both represent a L3
cache boundary.

> 
> 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.

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.

> 
>> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>> ---
>>  target/i386/cpu.c     | 76 +++++++++++++++++++++++++++++++++++++++++++
>>  target/i386/kvm/kvm.c | 17 ++++++++++
>>  2 files changed, 93 insertions(+)
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 641777578637..b7827e448aa5 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -495,6 +495,78 @@ static void encode_topo_cpuid1f(CPUX86State *env, uint32_t count,
>>      assert(!(*eax & ~0x1f));
>>  }
>>  
>> +/*
>> + * CPUID_Fn80000026: Extended CPU Topology
>> + *
>> + * EAX Bits Description
>> + * 31:5 Reserved
>> + *  4:0 Number of bits to shift Extended APIC ID right to get a unique
>> + *      topology ID of the current hierarchy level.
>> + *
>> + * EBX Bits Description
>> + * 31:16 Reserved
>> + * 15:0  Number of logical processors at the current hierarchy level.
>> + *
>> + * ECX Bits Description
>> + * 31:16 Reserved
>> + * 15:8  Level Type. Values:
>> + *       Value   Description
>> + *       0h      Reserved
>> + *       1h      Core
>> + *       2h      Complex
>> + *       3h      Die
>> + *       4h      Socket
>> + *       FFh-05h Reserved
>> + * 7:0   Input ECX
>> + *
>> + * EDX Bits Description
>> + * 31:0 Extended APIC ID of the logical processor
>> + */
> 
> I feel this long comment is not necessary, since people could check APM for
> details. Or this description could be included in commit message.

Sure. Will do. Thanks.

> 
>> +static void encode_topo_cpuid80000026(CPUX86State *env, uint32_t count,
>> +                                X86CPUTopoInfo *topo_info,
>> +                                uint32_t *eax, uint32_t *ebx,
>> +                                uint32_t *ecx, uint32_t *edx)
> 
> Regards,
> Zhao
> 

Re: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026

[Shivansh Dhiman]

Hi Zhao,

On 07-01-2026 13:17, Zhao Liu wrote:
> On Fri, Nov 21, 2025 at 08:34:49AM +0000, Shivansh Dhiman wrote:
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index b7827e448aa5..01c4da7cf134 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>>          if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
>>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
>>          }
>> +
>> +        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
>> +        if (cpu->force_cpuid_0x80000026 ||
>> +            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {
> 
> I understand you want to address max/host CPU case here, but it's still
> may not guarentee the compatibility with old QEMU PC mahinces, e.g.,
> boot a old PC machine on v11.0 QEMU, it can still have this leaf.

Wouldn't initializing x-force-cpuid-0x80000026 default to false prevent this?
Oh, but, this CPUID can still be enabled on an older machine-type with latest
QEMU with the existing checks. And probably this could also affect live migration.

> 
> So it would be better to add a compat option to disable 0x80000026 for
> old PC machines by default.

Does this look fine?

GlobalProperty pc_compat_10_2[] = {
    { TYPE_X86_CPU, "x-force-cpuid-0x80000026", "false" },
};
const size_t pc_compat_10_2_len = G_N_ELEMENTS(pc_compat_10_2);


> 
> If needed, to avoid unnecessarily enabling extended CPU topology, I think
> it's possible to implement a check similar to x86_has_cpuid_0x1f().

Do you mean something like this? I avoided it initially because it is
functionally same as current one, and a bit lengthy.

/* Enable CPUID[0x80000026] for AMD Genoa models and above */
static inline bool x86_has_cpuid_0x80000026(X86CPU *cpu) {
    X86CPUClass *xcc = X86_CPU_GET_CLASS(cpu);
    return cpu->force_cpuid_0x80000026 ||
	(!xcc->model && x86_is_amd_zen4_or_above(cpu));
}

...

if (x86_has_cpuid_0x80000026(cpu))
    x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x80000026);


Thanks for the review.
Shivansh

> 
>> +            x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x80000026);
>> +        }
>>      }
> 
> Thanks,
> Zhao
> 

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Zhao Liu]

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 <shivansh.dhiman@amd.com>
> 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 <shivansh.dhiman@amd.com>
> >> 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().

> 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.

> 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.

Thanks,
Zhao

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Shivansh Dhiman]

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 <shivansh.dhiman@amd.com>
>> 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 <shivansh.dhiman@amd.com>
>>>> 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
> 

Re: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026

[Zhao Liu]

> On 07-01-2026 13:17, Zhao Liu wrote:
> > On Fri, Nov 21, 2025 at 08:34:49AM +0000, Shivansh Dhiman wrote:
> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >> index b7827e448aa5..01c4da7cf134 100644
> >> --- a/target/i386/cpu.c
> >> +++ b/target/i386/cpu.c
> >> @@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
> >>          if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
> >>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
> >>          }
> >> +
> >> +        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
> >> +        if (cpu->force_cpuid_0x80000026 ||
> >> +            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {
> > 
> > I understand you want to address max/host CPU case here, but it's still
> > may not guarentee the compatibility with old QEMU PC mahinces, e.g.,
> > boot a old PC machine on v11.0 QEMU, it can still have this leaf.
> 
> Wouldn't initializing x-force-cpuid-0x80000026 default to false prevent this?
> Oh, but, this CPUID can still be enabled on an older machine-type with latest
> QEMU with the existing checks. And probably this could also affect live migration.

Yes, on a zen4 host, booting an older machine with latest QEMU will have
this CPUID leaf.
 
> > So it would be better to add a compat option to disable 0x80000026 for
> > old PC machines by default.
> 
> Does this look fine?
> 
> GlobalProperty pc_compat_10_2[] = {
>     { TYPE_X86_CPU, "x-force-cpuid-0x80000026", "false" },
> };
> const size_t pc_compat_10_2_len = G_N_ELEMENTS(pc_compat_10_2);

It looks fine if we only check "if (cpu->force_cpuid_0x80000026)".

> > If needed, to avoid unnecessarily enabling extended CPU topology, I think
> > it's possible to implement a check similar to x86_has_cpuid_0x1f().
> 
> Do you mean something like this? I avoided it initially because it is
> functionally same as current one, and a bit lengthy.

Sorry for confusion. Could we get rid of model check
(x86_is_amd_zen4_or_above)? and could we do something like 0x1f leaf,

static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
{
    return cpu->force_cpuid_0x1f ||
           x86_has_extended_topo(cpu->env.avail_cpu_topo);
	   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}

similarly, apply x86_has_extended_topo() for AMD CPU as well?

x86_has_extended_topo() also checks "module" level, but I think we could
return error in encode_topo_cpuid80000026() for unsupported "moduel"
level?

Thus, when users explicitly set these levels, the 0x80000026 leaf will be
enabled.

Furthermore, I think it's better that different x86 vendors could adopt
similar behavior for these extended topology levels, especially since
they are all all configured through a unified "-smp" interface.

Thanks,
Zhao

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Zhao Liu]

> >> 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.

Yes, it may be necessary to address some compatibility issues. But I think
this way could align with the topology mapping of the Linux kernel as much
as possible.

Thanks,
Zhao

Re: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026

[Shivansh Dhiman]

Hi,

On 12-01-2026 13:27, Zhao Liu wrote:
>> On 07-01-2026 13:17, Zhao Liu wrote:
>>> On Fri, Nov 21, 2025 at 08:34:49AM +0000, Shivansh Dhiman wrote:
>>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>>> index b7827e448aa5..01c4da7cf134 100644
>>>> --- a/target/i386/cpu.c
>>>> +++ b/target/i386/cpu.c
>>>> @@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>>>>          if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
>>>>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
>>>>          }
>>>> +
>>>> +        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
>>>> +        if (cpu->force_cpuid_0x80000026 ||
>>>> +            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {
>>>
>>> I understand you want to address max/host CPU case here, but it's still
>>> may not guarentee the compatibility with old QEMU PC mahinces, e.g.,
>>> boot a old PC machine on v11.0 QEMU, it can still have this leaf.
>>
>> Wouldn't initializing x-force-cpuid-0x80000026 default to false prevent this?
>> Oh, but, this CPUID can still be enabled on an older machine-type with latest
>> QEMU with the existing checks. And probably this could also affect live migration.
> 
> Yes, on a zen4 host, booting an older machine with latest QEMU will have
> this CPUID leaf.
>  
>>> So it would be better to add a compat option to disable 0x80000026 for
>>> old PC machines by default.
>>
>> Does this look fine?
>>
>> GlobalProperty pc_compat_10_2[] = {
>>     { TYPE_X86_CPU, "x-force-cpuid-0x80000026", "false" },
>> };
>> const size_t pc_compat_10_2_len = G_N_ELEMENTS(pc_compat_10_2);
> 
> It looks fine if we only check "if (cpu->force_cpuid_0x80000026)".
> 
>>> If needed, to avoid unnecessarily enabling extended CPU topology, I think
>>> it's possible to implement a check similar to x86_has_cpuid_0x1f().
>>
>> Do you mean something like this? I avoided it initially because it is
>> functionally same as current one, and a bit lengthy.
> 
> Sorry for confusion. Could we get rid of model check
> (x86_is_amd_zen4_or_above)? and could we do something like 0x1f leaf,

The CPUs prior to Zen4 do not have this CPUID. So, we need to match the hardware
and avoid enabling 80000026h on guests booting with EPYC-Milan or older. For
such a condition, we can't get rid of the model/family check.

> 
> static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
> {
>     return cpu->force_cpuid_0x1f ||
>            x86_has_extended_topo(cpu->env.avail_cpu_topo);
> 	   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> }
> 
> similarly, apply x86_has_extended_topo() for AMD CPU as well?

Something like this looks fine?

static inline bool x86_has_cpuid_0x80000026(X86CPU *cpu) {
    X86CPUClass *xcc = X86_CPU_GET_CLASS(cpu);

    return cpu->force_cpuid_0x80000026 ||
            (x86_has_extended_topo(cpu->env.avail_cpu_topo) &&
             x86_is_amd_zen4_or_above(cpu) && !xcc->model);
}

> 
> x86_has_extended_topo() also checks "module" level, but I think we could
> return error in encode_topo_cpuid80000026() for unsupported "moduel"
> level?

That can be done, but it should be harmless to let QEMU encode 80000026h when
only module is present, right? Another option can be to add vendor specific
checks in x86_has_extended_topo(). Thoughts?

> 
> Thus, when users explicitly set these levels, the 0x80000026 leaf will be
> enabled.>
> Furthermore, I think it's better that different x86 vendors could adopt
> similar behavior for these extended topology levels, especially since
> they are all all configured through a unified "-smp" interface.

Ack.

> 
> Thanks,
> Zhao
> 

Regards,
Shivansh

Re: [PATCH 1/5] i386: Implement CPUID 0x80000026

[Shivansh Dhiman]

On 12-01-2026 13:31, Zhao Liu wrote:
>>>> 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.
> 
> Yes, it may be necessary to address some compatibility issues. But I think
> this way could align with the topology mapping of the Linux kernel as much
> as possible.

This sounds like a good idea. Thanks.

> 
> Thanks,
> Zhao

Re: [PATCH 4/5] i386: Add Bus Lock Detect support

[Shivansh Dhiman]

Hi,

Gentle ping for reviewing patches for Bus Lock Detect in this series. Would
appreciate any feedback or guidance on next steps. The related KVM patch is at [1].

[1] https://lore.kernel.org/kvm/20251121081228.426974-1-shivansh.dhiman@amd.com/

Thanks,
Shivansh

On 21-11-2025 14:04, Shivansh Dhiman wrote:
> From: Ravi Bangoria <ravi.bangoria@amd.com>
> 
> Bus Lock Detect is enumerated with cpuid Fn0000_0007_ECX_x0 
> bit [24 / BUSLOCKTRAP]. It can be enabled through MSR_IA32_DEBUGCTLMSR.
> When enabled, hardware clears DR6[11] and raises a #DB exception on
> occurrence of Bus Lock if CPL > 0. More detail about the feature can be
> found in AMD APM[1].
> 
> Qemu supports remote debugging through host gdb (the "gdbstub" facility)
> where some of the remote debugging features like instruction and data
> breakpoints relies on the same hardware infrastructure (#DB, DR6 etc.)
> that Bus Lock Detect also uses. Instead of handling internally, KVM
> forwards #DB to Qemu when remote debugging is ON and #DB is being
> intercepted. It's Qemu's responsibility to re-inject the exception to
> guest when some of the exception source bits (in DR6) are not being
> handled by Qemu remote debug handler. Bus Lock Detect is one such case.
> 
> [1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
>      2023, Vol 2, 13.1.3.6 Bus Lock Trap
>      https://bugzilla.kernel.org/attachment.cgi?id=304653
> 
> Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  target/i386/cpu.h     | 1 +
>  target/i386/kvm/kvm.c | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 0fecca26dc4a..852b3a33b54d 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -276,6 +276,7 @@ typedef enum X86Seg {
>                  | CR4_SMEP_MASK | CR4_SMAP_MASK | CR4_PKE_MASK | CR4_PKS_MASK \
>                  | CR4_LAM_SUP_MASK | CR4_FRED_MASK))
>  
> +#define DR6_BLD         (1 << 11)
>  #define DR6_BD          (1 << 13)
>  #define DR6_BS          (1 << 14)
>  #define DR6_BT          (1 << 15)
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index ed3d40bf073e..00c44c2de650 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -5864,14 +5864,14 @@ static int kvm_handle_debug(X86CPU *cpu,
>      } else if (kvm_find_sw_breakpoint(cs, arch_info->pc)) {
>          ret = EXCP_DEBUG;
>      }
> -    if (ret == 0) {
> +    if (ret == 0 || !(arch_info->dr6 & DR6_BLD)) {
>          cpu_synchronize_state(cs);
>          assert(env->exception_nr == -1);
>  
>          /* pass to guest */
>          kvm_queue_exception(env, arch_info->exception,
>                              arch_info->exception == EXCP01_DB,
> -                            arch_info->dr6);
> +                            ret == 0 ? arch_info->dr6 ^ DR6_BLD : DR6_BLD);
>          env->has_error_code = 0;
>      }
>