[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61df5e77-dfc4-4189-a86d-f1b2cabcac88@oracle.com>
Date: Fri, 27 Jun 2025 08:23:52 +0200
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Xiaoyao Li <xiaoyao.li@...el.com>, Sean Christopherson <seanjc@...gle.com>
Cc: alexandre.chartre@...cle.com, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, pbonzini@...hat.com, x86@...nel.org,
konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
Jim Mattson <jmattson@...gle.com>
Subject: Re: [PATCH] kvm/x86: ARCH_CAPABILITIES should not be advertised on
AMD
On 6/27/25 07:41, Xiaoyao Li wrote:
> On 6/26/2025 10:02 PM, 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@...cle.com>
>>> ---
>>>
>>> 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@...ux.intel.com/
>> 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 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.
>
> Isn't it the Windows bugs? I think it is incorrect to assume AMD will never implement ARCH_CAPABILITIES.
>
Yes, although on one hand they are just following the current AMD specification which
says that ARCH_CAPABILITIES is not defined on AMD cpus; but on the other hand they are
breaking a 6+ years behavior. So it might be nice if we could prevent such an issue in
the future.
Note that a Windows update preview has just been released with a fix (OS Build 26100.4484),
but the Windows automatic update will still install the version with the issue at the moment
(automatic update doesn't install preview).
alex.
Powered by blists - more mailing lists