Re: [PATCH V3 2/5] KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock and DEV are not available

[Kevin Cheng]

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