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
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
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
>
> 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
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
© 2016 - 2026 Red Hat, Inc.