Re: [PATCH V3 2/5] KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock and DEV are not available
From: Sean Christopherson
Date: Fri Feb 13 2026 - 10:07:30 EST
On Thu, Feb 12, 2026, Kevin Cheng wrote:
> On Thu, Feb 12, 2026 at 4:18 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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.