All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: pbonzini@redhat.com, tglx@kernel.org, mingo@redhat.com,
	bp@alien8.de,  dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, shuah@kernel.org,  kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-kselftest@vger.kernel.org,
	ctpence@google.com
Subject: Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting
Date: Thu, 14 May 2026 07:28:56 -0700	[thread overview]
Message-ID: <agXcKDjnJc9DPcyr@google.com> (raw)
In-Reply-To: <CALMp9eS4s9tsOmvDUDeqS7oph0mSHyhxBiULQdwHVaG+7gXLSQ@mail.gmail.com>

On Thu, May 14, 2026, Jim Mattson wrote:
> > diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
> > index 95d09ccbf951..fc96ba86c644 100644
> > --- a/arch/x86/kvm/cpuid.h
> > +++ b/arch/x86/kvm/cpuid.h
> > @@ -185,8 +185,9 @@ static inline int guest_cpuid_stepping(struct kvm_vcpu *vcpu)
> >
> >  static inline bool cpuid_fault_enabled(struct kvm_vcpu *vcpu)
> >  {
> > -       return vcpu->arch.msr_misc_features_enables &
> > -                 MSR_MISC_FEATURES_ENABLES_CPUID_FAULT;
> > +       return (vcpu->arch.msr_misc_features_enables &
> > +               MSR_MISC_FEATURES_ENABLES_CPUID_FAULT) ||
> > +               (vcpu->arch.msr_hwcr & MSR_K7_HWCR_CPUID_USER_DIS);
> >  }
> 
> Sashiko raises a good point here about a pre-existing issue that

Calling this pre-existing is a bit of a stretch.  I'm guessing VMX doesn't check
the #GP before the VM-Exit (checking #GP before a VM-Exit is so stupid).

Yes, KVM technically emulates MSR_MISC_FEATURES_ENABLES_CPUID_FAULT for AMD, but
we're firmly in "making shit up" territory when reasoning about the interactions
between SVM and a feature that doesn't exist on real AMD CPUs.

> probably warrants a fix before propagating it further:
> 
> > Does this emulation of CPUID faulting respect architectural fault
> > priorities in a nested virtualization scenario?
> >
> > According to the AMD APM, if CPUID faulting is enabled, a #GP fault takes
> > precedence over a CPUID VM-exit intercept.

Where in the APM?  I can't find anything in the description of CPUID or CpuidUserDis
that specifies the priority, and "Table 15-7. Instruction Intercepts" is flat out
wrong because it just says:

   CPUID  CPUID  No exceptions to check.

> > Because KVM emulates CPUID faulting in kvm_emulate_cpuid(), the fault check
> > happens after nested VM-exit intercept checks. If an L1 hypervisor enables
> > both CPUID faulting and a CPUID VM-exit intercept, L0's nested exit
> > handlers will observe L1's intercept request and immediately reflect the
> > VM-exit to L1.
> >
> > Since this reflection happens before evaluating kvm_emulate_cpuid(), does
> > this allow L2 guests to completely bypass the CPUID faulting restrictions
> > imposed by L1?

  reply	other threads:[~2026-05-14 14:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 22:46 [PATCH v3 0/4] KVM: x86: Virtualize AMD's "disable CPUID in usermode" Jim Mattson
2026-05-13 22:46 ` [PATCH v3 1/4] KVM: x86: Consolidate CPUID fault handling for emulator and interception logic Jim Mattson
2026-05-14  8:41   ` Binbin Wu
2026-05-13 22:46 ` [PATCH v3 2/4] KVM: x86: Remove supports_cpuid_fault() helper Jim Mattson
2026-05-14  8:51   ` Binbin Wu
2026-05-13 22:46 ` [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting Jim Mattson
2026-05-14 13:19   ` Jim Mattson
2026-05-14 14:28     ` Sean Christopherson [this message]
2026-05-14 14:45       ` Jim Mattson
2026-05-14 16:20         ` Sean Christopherson
2026-05-14 16:22           ` Jim Mattson
2026-05-14 16:35             ` Sean Christopherson
2026-05-14 18:01               ` Jim Mattson
2026-05-14 18:17                 ` Kaplan, David
2026-05-13 22:46 ` [PATCH v3 4/4] KVM: selftests: Update hwcr_msr_test for CPUID faulting bit Jim Mattson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agXcKDjnJc9DPcyr@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=ctpence@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.