Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD

[Alexandre Chartre <alexandre.chartre@oracle.com>]

On 7/1/25 10:23, Xiaoyao Li wrote:
> On 6/30/2025 9:30 PM, Alexandre Chartre wrote:
>> KVM emulates the ARCH_CAPABILITIES on x86 for both Intel and AMD
>> cpus, although the IA32_ARCH_CAPABILITIES MSR is an Intel-specific
>> MSR and it makes no sense to emulate it on AMD.
>>
>> As a consequence, VMs created on AMD with qemu -cpu host and using
>> KVM will advertise the ARCH_CAPABILITIES feature and provide the
>> IA32_ARCH_CAPABILITIES MSR. This can cause issues (like Windows BSOD)
>> as the guest OS might not expect this MSR to exist on such cpus (the
>> AMD documentation specifies that ARCH_CAPABILITIES feature and MSR
>> are not defined on the AMD architecture).
>>
>> A fix was proposed in KVM code, however KVM maintainers don't want to
>> change this behavior that exists for 6+ years and suggest changes to be
>> done in qemu instead.
>>
>> So this commit changes the behavior in qemu so that ARCH_CAPABILITIES
>> is not provided by default on AMD cpus when the hypervisor emulates it,
>> but it can still be provided by explicitly setting arch-capabilities=on.
>>
>> Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
>> ---
>>   target/i386/cpu.c | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 0d35e95430..7e136c48df 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -8324,6 +8324,20 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>>           }
>>       }
>> +    /*
>> +     * For years, KVM has inadvertently emulated the ARCH_CAPABILITIES
>> +     * MSR on AMD although this is an Intel-specific MSR; and KVM will
>> +     * continue doing so to not change its ABI for existing setups.
>> +     *
>> +     * So ensure that the ARCH_CAPABILITIES MSR is disabled on AMD cpus
>> +     * to prevent providing a cpu with an MSR which is not supposed to
>> +     * be there, unless it was explicitly requested by the user.
>> +     */
>> +    if (IS_AMD_CPU(env) &&
>> +        !(env->user_features[FEAT_7_0_EDX] & CPUID_7_0_EDX_ARCH_CAPABILITIES)) {
>> +        env->features[FEAT_7_0_EDX] &= ~CPUID_7_0_EDX_ARCH_CAPABILITIES;
>> +    }
> 
> This changes the result for the existing usage of "-cpu host" on
> AMD. So it will need a compat_prop to keep the old behavior for old
> machine.

Right, I will look at that.

> 
> But I would like discuss if we really want to do it in QEMU.
> ARCH_CAPABILITIES is not the only one KVM emulates unconditionally.
> We have TSC_DEADLINE_TIMER as well. So why to treat them
> differently? just because some Windows cannot boot? To me, it looks
> just the bug of Windows. So please fix Windows. And to run with the
> buggy Windows, we have the workaround: "-cpu host,-arch-capabilities"

Well, the Windows behavior is not that wrong as it conforms to the AMD Manual
which specifies that ARCH_CAPABILITIES feature and MSR are not defined on AMD
cpus; while QEMU/KVM are providing an hybrid kind of AMD cpu with Intel feature/MSR.

Microsoft is fixing that behavior anyway and has provided a preview fix (OS Build
26100.4484), so that's good news. But the goal here is also to prevent such future
misbehavior. So if other features (like TSC_DEADLINE_TIMER) are exposed while they
shouldn't then they should probably be fixed as well.

"-cpu host,-arch-capabilities" is indeed a workaround, but it defeats the purpose
of the "-cpu host" option which is to provide a guest with the same features as the
host. And this workaround basically says: "provide a guest with the same cpu as
the host but disable this feature that the host doesn't provide"; this doesn't make
sense. Also this workaround doesn't integrate well in heterogeneous environments
(with Intel,  AMD, ARM or other cpus) where you just want to use "-cpu host" whatever
the platform is, and not have a special case for AMD cpus.

Thanks,

alex.