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@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 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.
