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
