Re: [PATCH] kvm/x86: ARCH_CAPABILITIES should not be advertised on AMD

[Alexandre Chartre]

On 6/26/25 16:02, Sean Christopherson wrote:
> +Jim
>
> For the scope, "KVM: x86:"
>
> On Thu, Jun 26, 2025, Alexandre Chartre wrote:
> > KVM emulates the ARCH_CAPABILITIES on x86 for both vmx and svm.
> > However the IA32_ARCH_CAPABILITIES MSR is an Intel-specific MSR
> > so it makes no sense to emulate it on AMD.
> >
> > The AMD documentation specifies that this MSR is not defined on
> > the AMD architecture. So emulating this MSR on AMD can even cause
> > issues (like Windows BSOD) as the guest OS might not expect this
> > MSR to exist on such architecture.
> >
> > Signed-off-by: Alexandre Chartre <alexandre.chartre@xxxxxxxxxx>
> > ---
> >
> > A similar patch was submitted some years ago but it looks like it felt
> > through the cracks:
> > https://lore.kernel.org/kvm/20190307093143.77182-1-xiaoyao.li@xxxxxxxxxxxxxxx/
>
> It didn't fall through the cracks, we deliberately elected to emulate the MSR in
> common code so that KVM's advertised CPUID support would match KVM's emulation.
>
>    On Thu, 2019-03-07 at 19:15 +0100, Paolo Bonzini wrote:
>    > On 07/03/19 18:37, Sean Christopherson wrote:
>    > > On Thu, Mar 07, 2019 at 05:31:43PM +0800, Xiaoyao Li wrote:
>    > > > At present, we report F(ARCH_CAPABILITIES) for x86 arch(both vmx and svm)
>    > > > unconditionally, but we only emulate this MSR in vmx. It will cause #GP
>    > > > while guest kernel rdmsr(MSR_IA32_ARCH_CAPABILITIES) in an AMD host.
>    > > >
>    > > > Since MSR IA32_ARCH_CAPABILITIES is an intel-specific MSR, it makes no
>    > > > sense to emulate it in svm. Thus this patch chooses to only emulate it
>    > > > for vmx, and moves the related handling to vmx related files.
>    > >
>    > > What about emulating the MSR on an AMD host for testing purpsoes?  It
>    > > might be a useful way for someone without Intel hardware to test spectre
>    > > related flows.
>    > >
>    > > In other words, an alternative to restricting emulation of the MSR to
>    > > Intel CPUS would be to move MSR_IA32_ARCH_CAPABILITIES handling into
>    > > kvm_{get,set}_msr_common().  Guest access to MSR_IA32_ARCH_CAPABILITIES
>    > > is gated by X86_FEATURE_ARCH_CAPABILITIES in the guest's CPUID, e.g.
>    > > RDMSR will naturally #GP fault if userspace passes through the host's
>    > > CPUID on a non-Intel system.
>    >
>    > This is also better because it wouldn't change the guest ABI for AMD
>    > processors.  Dropping CPUID flags is generally not a good idea.
>    >
>    > Paolo
>
> I don't necessarily disagree about emulating ARCH_CAPABILITIES being pointless,
> but Paolo's point about not changing ABI for existing setups still stands.  This
> has been KVM's behavior for 6 years (since commit 0cf9135b773b ("KVM: x86: Emulate
> MSR_IA32_ARCH_CAPABILITIES on AMD hosts"); 7 years, if we go back to when KVM
> enumerated support without emulating the MSR (commit 1eaafe91a0df ("kvm: x86:
> IA32_ARCH_CAPABILITIES is always supported").
>
> And it's not like KVM is forcing userspace to enumerate support for
> ARCH_CAPABILITIES, e.g. QEMU's named AMD configs don't enumerate support.  So
> while I completely agree KVM's behavior is odd and annoying for userspace to deal
> with, this is probably something that should be addressed in userspace.

I understand, no one likes to break ABI. However one can argue that any AMD code
(and even Intel) is supposed to work without ARCH_CAPABILITIES (AMD cpus never have
this capability and some Intel cpus don't either). Also if code running on AMD rely
on ARCH_CAPABILITIES then it's probably wrong. We can also imagine that exposing
this capability can induce incorrect behaviors in the guest like "the ARCH_CAPABILITIES
is present so that's an Intel cpu".


> > I am resurecting this change because some recent Windows updates (like OS Build
> > 26100.4351) crashes on AMD KVM guests (BSOD with Stop code: UNSUPPORTED PROCESSOR)
> > just because the ARCH_CAPABILITIES is available.
> >
> > ---
> >   arch/x86/kvm/svm/svm.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index ab9b947dbf4f..600d2029156e 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -5469,6 +5469,9 @@ static __init void svm_set_cpu_caps(void)
> >   
> >   	/* Don't advertise Bus Lock Detect to guest if SVM support is absent */
> >   	kvm_cpu_cap_clear(X86_FEATURE_BUS_LOCK_DETECT);
> > +
> > +	/* Don't advertise ARCH_CAPABILITIES on AMD */
> > +	kvm_cpu_cap_clear(X86_FEATURE_ARCH_CAPABILITIES);
>
> Strictly speaking, I think we'd want to update svm_has_emulated_msr() as well.

Yes, that would be cleaner. even though the access to the MSR is prevented by
KVM when the ARCH_CAPABILITIES is cleared.

Thanks,

alex.

> >   }
> >   
> >   static __init int svm_hardware_setup(void)
> > --
> > 2.43.5