[PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On AMD CPUs, CPUID faulting support is advertised via
CPUID.80000021H:EAX.CpuidUserDis[bit 17] and enabled by setting
HWCR.CpuidUserDis[bit 35].

Advertise the feature to userspace regardless of host CPU support. Allow
writes to HWCR to set bit 35 when the guest CPUID advertises
CpuidUserDis. Update cpuid_fault_enabled() to check HWCR.CpuidUserDis
as well as MSR_FEATURE_ENABLES.CPUID_GP_ON_CPL_GT_0.

Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/include/asm/msr-index.h |  1 +
 arch/x86/kvm/cpuid.c             |  2 +-
 arch/x86/kvm/cpuid.h             |  5 +++--
 arch/x86/kvm/x86.c               | 18 ++++++++++++------
 4 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 6673601246b3..0eeae121b0a6 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -888,6 +888,7 @@
 #define MSR_K7_HWCR_IRPERF_EN_BIT	30
 #define MSR_K7_HWCR_IRPERF_EN		BIT_ULL(MSR_K7_HWCR_IRPERF_EN_BIT)
 #define MSR_K7_HWCR_CPUID_USER_DIS_BIT	35
+#define MSR_K7_HWCR_CPUID_USER_DIS	BIT_ULL(MSR_K7_HWCR_CPUID_USER_DIS_BIT)
 #define MSR_K7_FID_VID_CTL		0xc0010041
 #define MSR_K7_FID_VID_STATUS		0xc0010042
 #define MSR_K7_HWCR_CPB_DIS_BIT		25
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1c95d1fa3ead..8e5340dd2621 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1248,7 +1248,7 @@ void kvm_initialize_cpu_caps(void)
 		F(AUTOIBRS),
 		EMULATED_F(NO_SMM_CTL_MSR),
 		/* PrefetchCtlMsr */
-		/* GpOnUserCpuid */
+		EMULATED_F(GP_ON_USER_CPUID),
 		/* EPSF */
 		F(PREFETCHI),
 		F(AVX512_BMM),
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);
 }
 
 static inline bool kvm_is_cpuid_allowed(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c60773349f35..6581018db16b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3990,22 +3990,28 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
 		break;
 	case MSR_EFER:
 		return set_efer(vcpu, msr_info);
-	case MSR_K7_HWCR:
-		data &= ~(u64)0x40;	/* ignore flush filter disable */
-		data &= ~(u64)0x100;	/* ignore ignne emulation enable */
-		data &= ~(u64)0x8;	/* ignore TLB cache disable */
-
+	case MSR_K7_HWCR: {
 		/*
 		 * Allow McStatusWrEn and TscFreqSel. (Linux guests from v3.2
 		 * through at least v6.6 whine if TscFreqSel is clear,
 		 * depending on F/M/S.
 		 */
-		if (data & ~(BIT_ULL(18) | BIT_ULL(24))) {
+		u64 valid = BIT_ULL(18) | BIT_ULL(24);
+
+		data &= ~(u64)0x40;	/* ignore flush filter disable */
+		data &= ~(u64)0x100;	/* ignore ignne emulation enable */
+		data &= ~(u64)0x8;	/* ignore TLB cache disable */
+
+		if (guest_cpu_cap_has(vcpu, X86_FEATURE_GP_ON_USER_CPUID))
+			valid |= MSR_K7_HWCR_CPUID_USER_DIS;
+
+		if (data & ~valid) {
 			kvm_pr_unimpl_wrmsr(vcpu, msr, data);
 			return 1;
 		}
 		vcpu->arch.msr_hwcr = data;
 		break;
+	}
 	case MSR_FAM10H_MMIO_CONF_BASE:
 		if (data != 0) {
 			kvm_pr_unimpl_wrmsr(vcpu, msr, data);
-- 
2.54.0.631.ge1b05301d1-goog

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Wed, May 13, 2026 at 3:46 PM Jim Mattson <jmattson@google.com> wrote:
>
> On AMD CPUs, CPUID faulting support is advertised via
> CPUID.80000021H:EAX.CpuidUserDis[bit 17] and enabled by setting
> HWCR.CpuidUserDis[bit 35].
>
> Advertise the feature to userspace regardless of host CPU support. Allow
> writes to HWCR to set bit 35 when the guest CPUID advertises
> CpuidUserDis. Update cpuid_fault_enabled() to check HWCR.CpuidUserDis
> as well as MSR_FEATURE_ENABLES.CPUID_GP_ON_CPL_GT_0.
>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
>  arch/x86/include/asm/msr-index.h |  1 +
>  arch/x86/kvm/cpuid.c             |  2 +-
>  arch/x86/kvm/cpuid.h             |  5 +++--
>  arch/x86/kvm/x86.c               | 18 ++++++++++++------
>  4 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 6673601246b3..0eeae121b0a6 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -888,6 +888,7 @@
>  #define MSR_K7_HWCR_IRPERF_EN_BIT      30
>  #define MSR_K7_HWCR_IRPERF_EN          BIT_ULL(MSR_K7_HWCR_IRPERF_EN_BIT)
>  #define MSR_K7_HWCR_CPUID_USER_DIS_BIT 35
> +#define MSR_K7_HWCR_CPUID_USER_DIS     BIT_ULL(MSR_K7_HWCR_CPUID_USER_DIS_BIT)
>  #define MSR_K7_FID_VID_CTL             0xc0010041
>  #define MSR_K7_FID_VID_STATUS          0xc0010042
>  #define MSR_K7_HWCR_CPB_DIS_BIT                25
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 1c95d1fa3ead..8e5340dd2621 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1248,7 +1248,7 @@ void kvm_initialize_cpu_caps(void)
>                 F(AUTOIBRS),
>                 EMULATED_F(NO_SMM_CTL_MSR),
>                 /* PrefetchCtlMsr */
> -               /* GpOnUserCpuid */
> +               EMULATED_F(GP_ON_USER_CPUID),
>                 /* EPSF */
>                 F(PREFETCHI),
>                 F(AVX512_BMM),
> 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
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.
> 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?

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Sean Christopherson]

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?

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Thu, May 14, 2026 at 7:28 AM Sean Christopherson <seanjc@google.com> wrote:
>
> 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).

Per the SDM, volume 3, section 27.1.1: Relative Priority of Faults and VM Exits

> Certain exceptions have priority over VM exits. These include invalid-opcode exceptions, faults based on
privilege level,1 and general-protection exceptions that are based on
checking I/O permission bits in the task-
state segment (TSS). For example, execution of RDMSR with CPL = 3
generates a general-protection exception
and not a VM exit.2

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

True.

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

APM volume 2, section 15.7: Intercept Operation

> Generally, instruction intercepts are checked after simple exceptions
(such as #GP—when CPL is incorrect—or #UD) have been checked, but
before exceptions related to
memory accesses (such as page faults) and exceptions based on specific
operand values.

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Sean Christopherson]

On Thu, May 14, 2026, Jim Mattson wrote:
> On Thu, May 14, 2026 at 7:28 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > 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).
> 
> Per the SDM, volume 3, section 27.1.1: Relative Priority of Faults and VM Exits
> 
> Certain exceptions have priority over VM exits. These include invalid-opcode
> exceptions, faults based on privilege level,1 and general-protection
> exceptions that are based on checking I/O permission bits in the task- state
> segment (TSS). For example, execution of RDMSR with CPL = 3 generates a
> general-protection exception and not a VM exit.2

...

> > 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.
> 
> APM volume 2, section 15.7: Intercept Operation
> 
> > Generally, instruction intercepts are checked after simple exceptions
> (such as #GP—when CPL is incorrect—or #UD) have been checked, but
> before exceptions related to
> memory accesses (such as page faults) and exceptions based on specific
> operand values.

Oooh, this is based on the generic CPL rules.  I didn't think about it from that
perspective.  So yeah, addressing that does make sense.  What a pain.

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Thu, May 14, 2026 at 9:20 AM Sean Christopherson <seanjc@google.com> wrote:
> Oooh, this is based on the generic CPL rules.  I didn't think about it from that
> perspective.  So yeah, addressing that does make sense.  What a pain.

When I fix this in version 4, what's the correct footer for Sashiko attribution:

Assisted-by: Sashiko:gemini/gemini-3.1-pro-preview

or

Reported-by: Sashiko:gemini/gemini-3.1-pro-preview

or something else?

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Sean Christopherson]

On Thu, May 14, 2026, Jim Mattson wrote:
> On Thu, May 14, 2026 at 9:20 AM Sean Christopherson <seanjc@google.com> wrote:
> > Oooh, this is based on the generic CPL rules.  I didn't think about it from that
> > perspective.  So yeah, addressing that does make sense.  What a pain.
> 
> When I fix this in version 4, what's the correct footer for Sashiko attribution:
> 
> Assisted-by: Sashiko:gemini/gemini-3.1-pro-preview
> 
> or
> 
> Reported-by: Sashiko:gemini/gemini-3.1-pro-preview

This, or even just:

  Reported-by: Sashiko

is good enough for me.  I don't expect random developers to know or care what
model was used, at least not when it comes to reporting bugs.  If you use AI to
help write the code, then maybe I'd care?

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Thu, May 14, 2026 at 9:35 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Thu, May 14, 2026, Jim Mattson wrote:
> > On Thu, May 14, 2026 at 9:20 AM Sean Christopherson <seanjc@google.com> wrote:
> > > Oooh, this is based on the generic CPL rules.  I didn't think about it from that
> > > perspective.  So yeah, addressing that does make sense.  What a pain.
> >
> > When I fix this in version 4, what's the correct footer for Sashiko attribution:
> >
> > Assisted-by: Sashiko:gemini/gemini-3.1-pro-preview
> >
> > or
> >
> > Reported-by: Sashiko:gemini/gemini-3.1-pro-preview
>
> This, or even just:
>
>   Reported-by: Sashiko
>
> is good enough for me.  I don't expect random developers to know or care what
> model was used, at least not when it comes to reporting bugs.  If you use AI to
> help write the code, then maybe I'd care?

I had Jetski write an empirical test to see how the hardware behaves.
On the first userspace CPUID VM-exit, temporarily set #GP on userspace
CPUID per the appropriate vendor's mechanism, make sure that we
intercept #GP, and re-enter the guest without advancing RIP. Then, see
what the next VM-exit is.

Surprise!

kvm_intel: KVM: EMPIRICAL TEST RESULT: #GP took precedence over CPUID VM-exit
kvm_amd: KVM: EMPIRICAL TEST RESULT (SVM): CPUID VM-exit took
precedence over #GP!

LOL!

David: Is this intentional or a bug?

RE: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Kaplan, David]

AMD General

> -----Original Message-----
> From: Jim Mattson <jmattson@google.com>
> Sent: Thursday, May 14, 2026 1:02 PM
> To: Sean Christopherson <seanjc@google.com>; Kaplan, David
> <David.Kaplan@amd.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
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, May 14, 2026 at 9:35 AM Sean Christopherson
> <seanjc@google.com> wrote:
> >
> > On Thu, May 14, 2026, Jim Mattson wrote:
> > > On Thu, May 14, 2026 at 9:20 AM Sean Christopherson
> <seanjc@google.com> wrote:
> > > > Oooh, this is based on the generic CPL rules.  I didn't think about it from
> that
> > > > perspective.  So yeah, addressing that does make sense.  What a pain.
> > >
> > > When I fix this in version 4, what's the correct footer for Sashiko
> attribution:
> > >
> > > Assisted-by: Sashiko:gemini/gemini-3.1-pro-preview
> > >
> > > or
> > >
> > > Reported-by: Sashiko:gemini/gemini-3.1-pro-preview
> >
> > This, or even just:
> >
> >   Reported-by: Sashiko
> >
> > is good enough for me.  I don't expect random developers to know or care
> what
> > model was used, at least not when it comes to reporting bugs.  If you use AI
> to
> > help write the code, then maybe I'd care?
>
> I had Jetski write an empirical test to see how the hardware behaves.
> On the first userspace CPUID VM-exit, temporarily set #GP on userspace
> CPUID per the appropriate vendor's mechanism, make sure that we
> intercept #GP, and re-enter the guest without advancing RIP. Then, see
> what the next VM-exit is.
>
> Surprise!
>
> kvm_intel: KVM: EMPIRICAL TEST RESULT: #GP took precedence over CPUID
> VM-exit
> kvm_amd: KVM: EMPIRICAL TEST RESULT (SVM): CPUID VM-exit took
> precedence over #GP!
>
> LOL!
>
> David: Is this intentional or a bug?

This appears to be a bug, as most other instructions (e.g. INVPCID) that have CPL checks do the CPL checks before the VMEXIT checks.  I'm following up on this internally...

Thanks for bringing this to our attention
--David Kaplan

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Thu, May 14, 2026 at 11:17 AM Kaplan, David <David.Kaplan@amd.com> wrote:
>
> This appears to be a bug, as most other instructions (e.g. INVPCID) that have CPL checks do the CPL checks before the VMEXIT checks.  I'm following up on this internally...

Did you learn anything from the internal follow-up? The ellipsis
suggests, "stay tuned..." :)

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Jim Mattson]

On Tue, May 26, 2026 at 2:30 PM Kaplan, David <David.Kaplan@amd.com> wrote:
>
> AMD General
>
> > -----Original Message-----
> > From: Jim Mattson <jmattson@google.com>
> > Sent: Tuesday, May 26, 2026 1:39 PM
> > To: Kaplan, David <David.Kaplan@amd.com>
> > Cc: Sean Christopherson <seanjc@google.com>; 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
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Thu, May 14, 2026 at 11:17 AM Kaplan, David <David.Kaplan@amd.com>
> > wrote:
> > >
> > > This appears to be a bug, as most other instructions (e.g. INVPCID) that have
> > CPL checks do the CPL checks before the VMEXIT checks.  I'm following up on
> > this internally...
> >
> > Did you learn anything from the internal follow-up? The ellipsis
> > suggests, "stay tuned..." :)
>
> It appears it was a deliberate decision, due in part to the fact that the traditional flow of checking CPL exceptions before intercepts typically applies to using instructions in an illegal way, but the user is not doing anything illegal here by executing CPUID which is normally a legal instruction at CPL3.
>
> That said, clearly the behavior is different now between the vendors, however at this point the feedback I got is that our architects want to stick with the existing behavior unless there is a strong reason that it is a problem for SW.

No problem from the standpoint of nested SVM emulation.

The APM does say, "**Generally** [emphasis mine], instruction
intercepts are checked after simple exceptions (such as #GP—when CPL
is incorrect—or #UD) have been checked, but before exceptions related
to memory accesses (such as page faults) and exceptions based on
specific operand values," but it would be nice to have exceptions such
as this enumerated.

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Christian Ludloff]

> It appears it was a deliberate decision, due in part to the fact that the traditional flow of checking CPL exceptions before intercepts typically applies to using instructions in an illegal way, but the user is not doing anything illegal here by executing CPUID which is normally a legal instruction at CPL3.
>
> That said, clearly the behavior is different now between the vendors, however at this point the feedback I got is that our architects want to stick with the existing behavior unless there is a strong reason that it is a problem for SW.

What is a HV expected to do for such a CPUID guest exit?

--
C.

Re: [PATCH v3 3/4] KVM: x86: Virtualize AMD CPUID faulting

[Sean Christopherson]

On Thu, May 28, 2026, Christian Ludloff wrote:
> > It appears it was a deliberate decision, due in part to the fact that the
> > traditional flow of checking CPL exceptions before intercepts typically
> > applies to using instructions in an illegal way, but the user is not doing
> > anything illegal here by executing CPUID which is normally a legal
> > instruction at CPL3.
> >
> > That said, clearly the behavior is different now between the vendors,
> > however at this point the feedback I got is that our architects want to
> > stick with the existing behavior unless there is a strong reason that it is
> > a problem for SW.
> 
> What is a HV expected to do for such a CPUID guest exit?

Emulate hardware behavior.  The only question we had was whether the observed
hardware behavior (VM-Exit takes precedence over #GP) was AMD's architectural
behavior.