The AMD APM states that STGI causes a #UD if SVM is not enabled and
neither SVM Lock nor the device exclusion vector (DEV) are supported.
Support for DEV is part of the SKINIT architecture. Fix the STGI exit
handler by injecting #UD when these conditions are met.

Signed-off-by: Kevin Cheng <chengkev@google.com>
---
 arch/x86/kvm/svm/nested.c |  9 +++++++--
 arch/x86/kvm/svm/svm.c    | 12 +++++++++++-
 arch/x86/kvm/svm/svm.h    |  1 +
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index ba0f11c68372b..60bb320c34bda 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -1466,9 +1466,9 @@ int nested_svm_exit_handled(struct vcpu_svm *svm)
 	return vmexit;
 }
 
-int nested_svm_check_permissions(struct kvm_vcpu *vcpu)
+int __nested_svm_check_permissions(struct kvm_vcpu *vcpu, bool insn_allowed)
 {
-	if (!(vcpu->arch.efer & EFER_SVME) || !is_paging(vcpu)) {
+	if (!insn_allowed || !is_paging(vcpu)) {
 		kvm_queue_exception(vcpu, UD_VECTOR);
 		return 1;
 	}
@@ -1481,6 +1481,11 @@ int nested_svm_check_permissions(struct kvm_vcpu *vcpu)
 	return 0;
 }
 
+int nested_svm_check_permissions(struct kvm_vcpu *vcpu)
+{
+	return __nested_svm_check_permissions(vcpu, vcpu->arch.efer & EFER_SVME);
+}
+
 static bool nested_svm_is_exception_vmexit(struct kvm_vcpu *vcpu, u8 vector,
 					   u32 error_code)
 {
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 7a854e81b6560..e6b1f8fa98a20 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2283,9 +2283,19 @@ void svm_set_gif(struct vcpu_svm *svm, bool value)
 
 static int stgi_interception(struct kvm_vcpu *vcpu)
 {
+	bool insn_allowed;
 	int ret;
 
-	if (nested_svm_check_permissions(vcpu))
+	/*
+	 * According to the APM, STGI is allowed even with SVM disabled if SVM
+	 * Lock or device exclusion vector (DEV) are supported. DEV is part of
+	 * the SKINIT architecture.
+	 */
+	insn_allowed = (vcpu->arch.efer & EFER_SVME) ||
+		       guest_cpu_cap_has(vcpu, X86_FEATURE_SVML) ||
+		       guest_cpu_cap_has(vcpu, X86_FEATURE_SKINIT);
+
+	if (__nested_svm_check_permissions(vcpu, insn_allowed))
 		return 1;
 
 	ret = kvm_skip_emulated_instruction(vcpu);
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 01be93a53d077..0ec09559767a3 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -769,6 +769,7 @@ static inline int nested_svm_simple_vmexit(struct vcpu_svm *svm, u32 exit_code)
 }
 
 int nested_svm_exit_handled(struct vcpu_svm *svm);
+int __nested_svm_check_permissions(struct kvm_vcpu *vcpu, bool insn_allowed);
 int nested_svm_check_permissions(struct kvm_vcpu *vcpu);
 int nested_svm_check_exception(struct vcpu_svm *svm, unsigned nr,
 			       bool has_error_code, u32 error_code);
-- 
2.52.0.457.g6b5491de43-goog

On Thu, Jan 22, 2026, Kevin Cheng wrote:
> The AMD APM states that STGI causes a #UD if SVM is not enabled and
> neither SVM Lock nor the device exclusion vector (DEV) are supported.
> Support for DEV is part of the SKINIT architecture. Fix the STGI exit
> handler by injecting #UD when these conditions are met.

This is entirely pointless.  SVML and SKINIT can never bet set in guest caps.
There are many things that are documented in the SDM/APM that don't have "correct"
handling in KVM, because they're completely unsupported.

_If_ this is causing someone enough heartburn to want to "fix", just add a comment
in nested_svm_check_permissions() stating that KVM doesn't support SVML or SKINIT.

On Thu, Feb 12, 2026, Sean Christopherson wrote:
> On Thu, Jan 22, 2026, Kevin Cheng wrote:
> > The AMD APM states that STGI causes a #UD if SVM is not enabled and
> > neither SVM Lock nor the device exclusion vector (DEV) are supported.
> > Support for DEV is part of the SKINIT architecture. Fix the STGI exit
> > handler by injecting #UD when these conditions are met.
> 
> This is entirely pointless.  SVML and SKINIT can never bet set in guest caps.
> There are many things that are documented in the SDM/APM that don't have "correct"
> handling in KVM, because they're completely unsupported.
> 
> _If_ this is causing someone enough heartburn to want to "fix", just add a comment
> in nested_svm_check_permissions() stating that KVM doesn't support SVML or SKINIT.

Case in point, patch 4 is flawed because it forces interception of STGI if
EFER.SVME=0.  I.e. by trying to handle the impossible, you're introducing new
and novel ways for KVM to do things "wrong".

On Thu, Feb 12, 2026 at 4:18 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Thu, Feb 12, 2026, Sean Christopherson wrote:
> > On Thu, Jan 22, 2026, Kevin Cheng wrote:
> > > The AMD APM states that STGI causes a #UD if SVM is not enabled and
> > > neither SVM Lock nor the device exclusion vector (DEV) are supported.
> > > Support for DEV is part of the SKINIT architecture. Fix the STGI exit
> > > handler by injecting #UD when these conditions are met.
> >
> > This is entirely pointless.  SVML and SKINIT can never bet set in guest caps.
> > There are many things that are documented in the SDM/APM that don't have "correct"
> > handling in KVM, because they're completely unsupported.
> >
> > _If_ this is causing someone enough heartburn to want to "fix", just add a comment
> > in nested_svm_check_permissions() stating that KVM doesn't support SVML or SKINIT.
>
> Case in point, patch 4 is flawed because it forces interception of STGI if
> EFER.SVME=0.  I.e. by trying to handle the impossible, you're introducing new
> and novel ways for KVM to do things "wrong".

Just to clarify, do you mean patch 4 is flawed with patch 2? Or is the
forcing of STGI interception flawed regardless? I am assuming the
former here

On Thu, Feb 12, 2026, Kevin Cheng wrote:
> On Thu, Feb 12, 2026 at 4:18 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Thu, Feb 12, 2026, Sean Christopherson wrote:
> > > On Thu, Jan 22, 2026, Kevin Cheng wrote:
> > > > The AMD APM states that STGI causes a #UD if SVM is not enabled and
> > > > neither SVM Lock nor the device exclusion vector (DEV) are supported.
> > > > Support for DEV is part of the SKINIT architecture. Fix the STGI exit
> > > > handler by injecting #UD when these conditions are met.
> > >
> > > This is entirely pointless.  SVML and SKINIT can never bet set in guest caps.
> > > There are many things that are documented in the SDM/APM that don't have "correct"
> > > handling in KVM, because they're completely unsupported.
> > >
> > > _If_ this is causing someone enough heartburn to want to "fix", just add a comment
> > > in nested_svm_check_permissions() stating that KVM doesn't support SVML or SKINIT.
> >
> > Case in point, patch 4 is flawed because it forces interception of STGI if
> > EFER.SVME=0.  I.e. by trying to handle the impossible, you're introducing new
> > and novel ways for KVM to do things "wrong".
> 
> Just to clarify, do you mean patch 4 is flawed with patch 2? Or is the
> forcing of STGI interception flawed regardless? I am assuming the
> former here

Yes, the former.  Checking only SVME here:

	if (guest_cpuid_is_intel_compatible(vcpu) || !(efer & EFER_SVME)) {
		svm_set_intercept(svm, INTERCEPT_CLGI);
		svm_set_intercept(svm, INTERCEPT_STGI);
		svm_set_intercept(svm, INTERCEPT_VMLOAD);
		svm_set_intercept(svm, INTERCEPT_VMSAVE);

is confusing, because KVM's logic for injecting the #UD would be:

	if (!(vcpu->arch.efer & EFER_SVME) &&
	    !guest_cpu_cap_has(vcpu, X86_FEATURE_SVML) &&
	    !guest_cpu_cap_has(vcpu, X86_FEATURE_SKINIT))
		<#ud>

which raises the question of why the interception code doesn't factor in SVML and
SKINIT.  "wrong" was in quotes, because there's no functional bug, but it's weird
and confusing because KVM is blatantly contradicting itself.