arch/x86/kvm/svm/hyperv.h | 11 ++++++++ arch/x86/kvm/svm/nested.c | 4 +-- arch/x86/kvm/svm/svm.c | 59 +++++++++++++++++++++++++++++++++++---- 3 files changed, 65 insertions(+), 9 deletions(-)
The APM lists the following behaviors
- The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions
can be used when the EFER.SVME is set to 1; otherwise, these
instructions generate a #UD exception.
- If VMMCALL instruction is not intercepted, the instruction raises a
#UD exception.
The patches in this series fix current SVM bugs that do not adhere to
the APM listed behaviors.
v3 -> v4:
- Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock
and DEV are not available" as per Sean
- Added back STGI and CLGI intercept clearing in init_vmcb to maintain
previous behavior on intel guests. Previously intel guests always
had STGI and CLGI intercepts cleared if vgif was enabled. In V3,
because the clearing of the intercepts was moved from init_vmcb() to
the !guest_cpuid_is_intel_compatible() case in
svm_recalc_instruction_intercepts(), the CLGI intercept would be
indefinitely set on intel guests. I added back the clearing to
init_vmcb() to retain intel guest behavior before this patch.
- In "Raise #UD if VMMCALL instruction is not intercepted" patch:
- Exempt Hyper-V L2 TLB flush hypercalls from the #UD injection,
as L0 intentionally intercepts these VMMCALLs on behalf of L1
via the direct hypercall enlightenment.
- Added nested_svm_is_l2_tlb_flush_hcall() which just returns true
if the hypercall was a Hyper-V L2 TLB flush hypercall.
v3: https://lore.kernel.org/kvm/20260122045755.205203-1-chengkev@google.com/
v2 -> v3:
- Elaborated on 'Move STGI and CLGI intercept handling' commit message
as per Sean
- Fixed bug due to interaction with svm_enable_nmi_window() and 'Move
STGI and CLGI intercept handling' as pointed out by Yosry. Code
changes suggested by Sean/Yosry.
- Removed open-coded nested_svm_check_permissions() in STGI
interception function as per Yosry
v2: https://lore.kernel.org/all/20260112174535.3132800-1-chengkev@google.com/
v1 -> v2:
- Split up the series into smaller more logical changes as suggested
by Sean
- Added patch for injecting #UD for STGI under APM defined conditions
as suggested by Sean
- Combined EFER.SVME=0 conditional with intel CPU logic in
svm_recalc_instruction_intercepts
Kevin Cheng (4):
KVM: SVM: Move STGI and CLGI intercept handling
KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
KVM: SVM: Recalc instructions intercepts when EFER.SVME is toggled
KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted
arch/x86/kvm/svm/hyperv.h | 11 ++++++++
arch/x86/kvm/svm/nested.c | 4 +--
arch/x86/kvm/svm/svm.c | 59 +++++++++++++++++++++++++++++++++++----
3 files changed, 65 insertions(+), 9 deletions(-)
--
2.53.0.473.g4a7958ca14-goog
On Sat, 28 Feb 2026 03:33:24 +0000, Kevin Cheng wrote:
> The APM lists the following behaviors
> - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions
> can be used when the EFER.SVME is set to 1; otherwise, these
> instructions generate a #UD exception.
> - If VMMCALL instruction is not intercepted, the instruction raises a
> #UD exception.
>
> [...]
Applied patch 2 to kvm-x86 nested (the rest are coming separately). Thanks!
[2/4] KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
https://github.com/kvm-x86/linux/commit/d99df02ff427
--
https://github.com/kvm-x86/linux/tree/next
On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@google.com> wrote: > > The APM lists the following behaviors > - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions > can be used when the EFER.SVME is set to 1; otherwise, these > instructions generate a #UD exception. > - If VMMCALL instruction is not intercepted, the instruction raises a > #UD exception. > > The patches in this series fix current SVM bugs that do not adhere to > the APM listed behaviors. > > v3 -> v4: > - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock > and DEV are not available" as per Sean > - Added back STGI and CLGI intercept clearing in init_vmcb to maintain > previous behavior on intel guests. Previously intel guests always > had STGI and CLGI intercepts cleared if vgif was enabled. In V3, > because the clearing of the intercepts was moved from init_vmcb() to > the !guest_cpuid_is_intel_compatible() case in > svm_recalc_instruction_intercepts(), the CLGI intercept would be > indefinitely set on intel guests. I added back the clearing to > init_vmcb() to retain intel guest behavior before this patch. I am a bit confused by this. v4 kept initializing the intercepts as cleared for all guests, but we still set the CLGI/STGI intercepts for Intel-compatible guests in svm_recalc_instruction_intercepts() patch 3. So what difference did this make? Also taking a step back, I am not really sure what's the right thing to do for Intel-compatible guests here. It also seems like even if we set the intercept, svm_set_gif() will clear the STGI intercept, even on Intel-compatible guests. Maybe we should leave that can of worms alone, go back to removing initializing the CLGI/STGI intercepts in init_vmcb(), and in svm_recalc_instruction_intercepts() set/clear these intercepts based on EFER.SVME alone, irrespective of Intel-compatibility? > - In "Raise #UD if VMMCALL instruction is not intercepted" patch: > - Exempt Hyper-V L2 TLB flush hypercalls from the #UD injection, > as L0 intentionally intercepts these VMMCALLs on behalf of L1 > via the direct hypercall enlightenment. > - Added nested_svm_is_l2_tlb_flush_hcall() which just returns true > if the hypercall was a Hyper-V L2 TLB flush hypercall. > > v3: https://lore.kernel.org/kvm/20260122045755.205203-1-chengkev@google.com/ > > v2 -> v3: > - Elaborated on 'Move STGI and CLGI intercept handling' commit message > as per Sean > - Fixed bug due to interaction with svm_enable_nmi_window() and 'Move > STGI and CLGI intercept handling' as pointed out by Yosry. Code > changes suggested by Sean/Yosry. > - Removed open-coded nested_svm_check_permissions() in STGI > interception function as per Yosry > > v2: https://lore.kernel.org/all/20260112174535.3132800-1-chengkev@google.com/ > > v1 -> v2: > - Split up the series into smaller more logical changes as suggested > by Sean > - Added patch for injecting #UD for STGI under APM defined conditions > as suggested by Sean > - Combined EFER.SVME=0 conditional with intel CPU logic in > svm_recalc_instruction_intercepts > > Kevin Cheng (4): > KVM: SVM: Move STGI and CLGI intercept handling > KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 > KVM: SVM: Recalc instructions intercepts when EFER.SVME is toggled > KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted > > arch/x86/kvm/svm/hyperv.h | 11 ++++++++ > arch/x86/kvm/svm/nested.c | 4 +-- > arch/x86/kvm/svm/svm.c | 59 +++++++++++++++++++++++++++++++++++---- > 3 files changed, 65 insertions(+), 9 deletions(-) > > -- > 2.53.0.473.g4a7958ca14-goog >
On Mon, Mar 2, 2026 at 11:21 AM Yosry Ahmed <yosry@kernel.org> wrote: > > On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@google.com> wrote: > > > > The APM lists the following behaviors > > - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions > > can be used when the EFER.SVME is set to 1; otherwise, these > > instructions generate a #UD exception. > > - If VMMCALL instruction is not intercepted, the instruction raises a > > #UD exception. > > > > The patches in this series fix current SVM bugs that do not adhere to > > the APM listed behaviors. > > > > v3 -> v4: > > - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock > > and DEV are not available" as per Sean > > - Added back STGI and CLGI intercept clearing in init_vmcb to maintain > > previous behavior on intel guests. Previously intel guests always > > had STGI and CLGI intercepts cleared if vgif was enabled. In V3, > > because the clearing of the intercepts was moved from init_vmcb() to > > the !guest_cpuid_is_intel_compatible() case in > > svm_recalc_instruction_intercepts(), the CLGI intercept would be > > indefinitely set on intel guests. I added back the clearing to > > init_vmcb() to retain intel guest behavior before this patch. > > I am a bit confused by this. v4 kept initializing the intercepts as > cleared for all guests, but we still set the CLGI/STGI intercepts for > Intel-compatible guests in svm_recalc_instruction_intercepts() patch > 3. So what difference did this make? > Yes I was mistaken in that comment. Please ignore that comment as it is incorrect. > Also taking a step back, I am not really sure what's the right thing > to do for Intel-compatible guests here. It also seems like even if we > set the intercept, svm_set_gif() will clear the STGI intercept, even > on Intel-compatible guests. > > Maybe we should leave that can of worms alone, go back to removing > initializing the CLGI/STGI intercepts in init_vmcb(), and in > svm_recalc_instruction_intercepts() set/clear these intercepts based > on EFER.SVME alone, irrespective of Intel-compatibility? > > > > > - In "Raise #UD if VMMCALL instruction is not intercepted" patch: > > - Exempt Hyper-V L2 TLB flush hypercalls from the #UD injection, > > as L0 intentionally intercepts these VMMCALLs on behalf of L1 > > via the direct hypercall enlightenment. > > - Added nested_svm_is_l2_tlb_flush_hcall() which just returns true > > if the hypercall was a Hyper-V L2 TLB flush hypercall. > > > > v3: https://lore.kernel.org/kvm/20260122045755.205203-1-chengkev@google.com/ > > > > v2 -> v3: > > - Elaborated on 'Move STGI and CLGI intercept handling' commit message > > as per Sean > > - Fixed bug due to interaction with svm_enable_nmi_window() and 'Move > > STGI and CLGI intercept handling' as pointed out by Yosry. Code > > changes suggested by Sean/Yosry. > > - Removed open-coded nested_svm_check_permissions() in STGI > > interception function as per Yosry > > > > v2: https://lore.kernel.org/all/20260112174535.3132800-1-chengkev@google.com/ > > > > v1 -> v2: > > - Split up the series into smaller more logical changes as suggested > > by Sean > > - Added patch for injecting #UD for STGI under APM defined conditions > > as suggested by Sean > > - Combined EFER.SVME=0 conditional with intel CPU logic in > > svm_recalc_instruction_intercepts > > > > Kevin Cheng (4): > > KVM: SVM: Move STGI and CLGI intercept handling > > KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 > > KVM: SVM: Recalc instructions intercepts when EFER.SVME is toggled > > KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted > > > > arch/x86/kvm/svm/hyperv.h | 11 ++++++++ > > arch/x86/kvm/svm/nested.c | 4 +-- > > arch/x86/kvm/svm/svm.c | 59 +++++++++++++++++++++++++++++++++++---- > > 3 files changed, 65 insertions(+), 9 deletions(-) > > > > -- > > 2.53.0.473.g4a7958ca14-goog > >
On Mon, Mar 02, 2026, Yosry Ahmed wrote: > On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@google.com> wrote: > > > > The APM lists the following behaviors > > - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions > > can be used when the EFER.SVME is set to 1; otherwise, these > > instructions generate a #UD exception. > > - If VMMCALL instruction is not intercepted, the instruction raises a > > #UD exception. > > > > The patches in this series fix current SVM bugs that do not adhere to > > the APM listed behaviors. > > > > v3 -> v4: > > - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock > > and DEV are not available" as per Sean > > - Added back STGI and CLGI intercept clearing in init_vmcb to maintain > > previous behavior on intel guests. Previously intel guests always > > had STGI and CLGI intercepts cleared if vgif was enabled. In V3, > > because the clearing of the intercepts was moved from init_vmcb() to > > the !guest_cpuid_is_intel_compatible() case in > > svm_recalc_instruction_intercepts(), the CLGI intercept would be > > indefinitely set on intel guests. I added back the clearing to > > init_vmcb() to retain intel guest behavior before this patch. > > I am a bit confused by this. v4 kept initializing the intercepts as > cleared for all guests, but we still set the CLGI/STGI intercepts for > Intel-compatible guests in svm_recalc_instruction_intercepts() patch > 3. So what difference did this make? > > Also taking a step back, I am not really sure what's the right thing > to do for Intel-compatible guests here. It also seems like even if we > set the intercept, svm_set_gif() will clear the STGI intercept, even > on Intel-compatible guests. > > Maybe we should leave that can of worms alone, go back to removing > initializing the CLGI/STGI intercepts in init_vmcb(), and in > svm_recalc_instruction_intercepts() set/clear these intercepts based > on EFER.SVME alone, irrespective of Intel-compatibility? Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE. KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the guest enables and uses SVM. /* * Intercept VMLOAD if the vCPU model is Intel in order to emulate that * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing * SVM on Intel is bonkers and extremely unlikely to work). */ if (guest_cpuid_is_intel_compatible(vcpu)) guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD); Sorry for not catching this in previous versions.
On Mon, Mar 02, 2026, Sean Christopherson wrote:
> On Mon, Mar 02, 2026, Yosry Ahmed wrote:
> > On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@google.com> wrote:
> > >
> > > The APM lists the following behaviors
> > > - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions
> > > can be used when the EFER.SVME is set to 1; otherwise, these
> > > instructions generate a #UD exception.
> > > - If VMMCALL instruction is not intercepted, the instruction raises a
> > > #UD exception.
> > >
> > > The patches in this series fix current SVM bugs that do not adhere to
> > > the APM listed behaviors.
> > >
> > > v3 -> v4:
> > > - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock
> > > and DEV are not available" as per Sean
> > > - Added back STGI and CLGI intercept clearing in init_vmcb to maintain
> > > previous behavior on intel guests. Previously intel guests always
> > > had STGI and CLGI intercepts cleared if vgif was enabled. In V3,
> > > because the clearing of the intercepts was moved from init_vmcb() to
> > > the !guest_cpuid_is_intel_compatible() case in
> > > svm_recalc_instruction_intercepts(), the CLGI intercept would be
> > > indefinitely set on intel guests. I added back the clearing to
> > > init_vmcb() to retain intel guest behavior before this patch.
> >
> > I am a bit confused by this. v4 kept initializing the intercepts as
> > cleared for all guests, but we still set the CLGI/STGI intercepts for
> > Intel-compatible guests in svm_recalc_instruction_intercepts() patch
> > 3. So what difference did this make?
> >
> > Also taking a step back, I am not really sure what's the right thing
> > to do for Intel-compatible guests here. It also seems like even if we
> > set the intercept, svm_set_gif() will clear the STGI intercept, even
> > on Intel-compatible guests.
> >
> > Maybe we should leave that can of worms alone, go back to removing
> > initializing the CLGI/STGI intercepts in init_vmcb(), and in
> > svm_recalc_instruction_intercepts() set/clear these intercepts based
> > on EFER.SVME alone, irrespective of Intel-compatibility?
>
> Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE.
> KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM
> is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the
> guest enables and uses SVM.
>
> /*
> * Intercept VMLOAD if the vCPU model is Intel in order to emulate that
> * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing
> * SVM on Intel is bonkers and extremely unlikely to work).
> */
> if (guest_cpuid_is_intel_compatible(vcpu))
> guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
>
> Sorry for not catching this in previous versions.
Because I got all kinds of confused trying to recall what was different between
v3 and v4, I went ahead and spliced them together.
Does the below look right? If so, I'll formally post just patches 1 and 3 as v5.
I'll take 2 and 4 directly from here; I want to switch the ordering anyways so
that the vgif movement immediately precedes the Recalc "instructions" patch.
/*
* Intercept instructions that #UD if EFER.SVME=0, as SVME must be set
* even when running the guest, i.e. hardware will only ever see
* EFER.SVME=1.
*
* No need to toggle any of the vgif/vls/etc. enable bits here, as they
* are set when the VMCB is initialized and never cleared (if the
* relevant intercepts are set, the enablements are meaningless anyway).
*/
if (!(vcpu->arch.efer & EFER_SVME)) {
svm_set_intercept(svm, INTERCEPT_VMLOAD);
svm_set_intercept(svm, INTERCEPT_VMSAVE);
svm_set_intercept(svm, INTERCEPT_CLGI);
svm_set_intercept(svm, INTERCEPT_STGI);
} else {
/*
* If hardware supports Virtual VMLOAD VMSAVE then enable it
* in VMCB and clear intercepts to avoid #VMEXIT.
*/
if (guest_cpuid_is_intel_compatible(vcpu)) {
svm_set_intercept(svm, INTERCEPT_VMLOAD);
svm_set_intercept(svm, INTERCEPT_VMSAVE);
} else if (vls) {
svm_clr_intercept(svm, INTERCEPT_VMLOAD);
svm_clr_intercept(svm, INTERCEPT_VMSAVE);
}
/*
* Process pending events when clearing STGI/CLGI intercepts if
* there's at least one pending event that is masked by GIF, so
* that KVM re-evaluates if the intercept needs to be set again
* to track when GIF is re-enabled (e.g. for NMI injection).
*/
if (vgif) {
svm_clr_intercept(svm, INTERCEPT_CLGI);
svm_clr_intercept(svm, INTERCEPT_STGI);
if (svm_has_pending_gif_event(svm))
kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
}
}
where init_vmcb() is (like v3):
if (vnmi)
svm->vmcb->control.int_ctl |= V_NMI_ENABLE_MASK;
if (vgif)
svm->vmcb->control.int_ctl |= V_GIF_ENABLE_MASK;
if (vls)
svm->vmcb->control.virt_ext |= VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK;
On Mon, Mar 2, 2026 at 6:17 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Mar 02, 2026, Sean Christopherson wrote:
> > On Mon, Mar 02, 2026, Yosry Ahmed wrote:
> > > On Fri, Feb 27, 2026 at 7:33 PM Kevin Cheng <chengkev@google.com> wrote:
> > > >
> > > > The APM lists the following behaviors
> > > > - The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions
> > > > can be used when the EFER.SVME is set to 1; otherwise, these
> > > > instructions generate a #UD exception.
> > > > - If VMMCALL instruction is not intercepted, the instruction raises a
> > > > #UD exception.
> > > >
> > > > The patches in this series fix current SVM bugs that do not adhere to
> > > > the APM listed behaviors.
> > > >
> > > > v3 -> v4:
> > > > - Dropped "KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock
> > > > and DEV are not available" as per Sean
> > > > - Added back STGI and CLGI intercept clearing in init_vmcb to maintain
> > > > previous behavior on intel guests. Previously intel guests always
> > > > had STGI and CLGI intercepts cleared if vgif was enabled. In V3,
> > > > because the clearing of the intercepts was moved from init_vmcb() to
> > > > the !guest_cpuid_is_intel_compatible() case in
> > > > svm_recalc_instruction_intercepts(), the CLGI intercept would be
> > > > indefinitely set on intel guests. I added back the clearing to
> > > > init_vmcb() to retain intel guest behavior before this patch.
> > >
> > > I am a bit confused by this. v4 kept initializing the intercepts as
> > > cleared for all guests, but we still set the CLGI/STGI intercepts for
> > > Intel-compatible guests in svm_recalc_instruction_intercepts() patch
> > > 3. So what difference did this make?
> > >
> > > Also taking a step back, I am not really sure what's the right thing
> > > to do for Intel-compatible guests here. It also seems like even if we
> > > set the intercept, svm_set_gif() will clear the STGI intercept, even
> > > on Intel-compatible guests.
> > >
> > > Maybe we should leave that can of worms alone, go back to removing
> > > initializing the CLGI/STGI intercepts in init_vmcb(), and in
> > > svm_recalc_instruction_intercepts() set/clear these intercepts based
> > > on EFER.SVME alone, irrespective of Intel-compatibility?
> >
> > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE.
> > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM
> > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the
> > guest enables and uses SVM.
> >
> > /*
> > * Intercept VMLOAD if the vCPU model is Intel in order to emulate that
> > * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing
> > * SVM on Intel is bonkers and extremely unlikely to work).
> > */
> > if (guest_cpuid_is_intel_compatible(vcpu))
> > guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
> >
> > Sorry for not catching this in previous versions.
>
> Because I got all kinds of confused trying to recall what was different between
> v3 and v4, I went ahead and spliced them together.
>
> Does the below look right? If so, I'll formally post just patches 1 and 3 as v5.
> I'll take 2 and 4 directly from here; I want to switch the ordering anyways so
> that the vgif movement immediately precedes the Recalc "instructions" patch.
>
> /*
> * Intercept instructions that #UD if EFER.SVME=0, as SVME must be set
> * even when running the guest, i.e. hardware will only ever see
> * EFER.SVME=1.
> *
> * No need to toggle any of the vgif/vls/etc. enable bits here, as they
> * are set when the VMCB is initialized and never cleared (if the
> * relevant intercepts are set, the enablements are meaningless anyway).
> */
> if (!(vcpu->arch.efer & EFER_SVME)) {
> svm_set_intercept(svm, INTERCEPT_VMLOAD);
> svm_set_intercept(svm, INTERCEPT_VMSAVE);
> svm_set_intercept(svm, INTERCEPT_CLGI);
> svm_set_intercept(svm, INTERCEPT_STGI);
> } else {
> /*
> * If hardware supports Virtual VMLOAD VMSAVE then enable it
> * in VMCB and clear intercepts to avoid #VMEXIT.
> */
> if (guest_cpuid_is_intel_compatible(vcpu)) {
> svm_set_intercept(svm, INTERCEPT_VMLOAD);
> svm_set_intercept(svm, INTERCEPT_VMSAVE);
> } else if (vls) {
> svm_clr_intercept(svm, INTERCEPT_VMLOAD);
> svm_clr_intercept(svm, INTERCEPT_VMSAVE);
> }
>
> /*
> * Process pending events when clearing STGI/CLGI intercepts if
> * there's at least one pending event that is masked by GIF, so
> * that KVM re-evaluates if the intercept needs to be set again
> * to track when GIF is re-enabled (e.g. for NMI injection).
> */
> if (vgif) {
> svm_clr_intercept(svm, INTERCEPT_CLGI);
> svm_clr_intercept(svm, INTERCEPT_STGI);
>
> if (svm_has_pending_gif_event(svm))
> kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
> }
> }
>
> where init_vmcb() is (like v3):
>
> if (vnmi)
> svm->vmcb->control.int_ctl |= V_NMI_ENABLE_MASK;
>
> if (vgif)
> svm->vmcb->control.int_ctl |= V_GIF_ENABLE_MASK;
>
> if (vls)
> svm->vmcb->control.virt_ext |= VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK;
Yup this looks correct to me.
On Mon, Mar 02, 2026, Sean Christopherson wrote: > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > On Mon, Mar 02, 2026, Yosry Ahmed wrote: > > > Also taking a step back, I am not really sure what's the right thing > > > to do for Intel-compatible guests here. It also seems like even if we > > > set the intercept, svm_set_gif() will clear the STGI intercept, even > > > on Intel-compatible guests. > > > > > > Maybe we should leave that can of worms alone, go back to removing > > > initializing the CLGI/STGI intercepts in init_vmcb(), and in > > > svm_recalc_instruction_intercepts() set/clear these intercepts based > > > on EFER.SVME alone, irrespective of Intel-compatibility? > > > > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE. > > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM > > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the > > guest enables and uses SVM. > > > > /* > > * Intercept VMLOAD if the vCPU model is Intel in order to emulate that > > * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing > > * SVM on Intel is bonkers and extremely unlikely to work). > > */ > > if (guest_cpuid_is_intel_compatible(vcpu)) > > guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD); > > > > Sorry for not catching this in previous versions. > > Because I got all kinds of confused trying to recall what was different between > v3 and v4, I went ahead and spliced them together. > > Does the below look right? If so, I'll formally post just patches 1 and 3 as v5. > I'll take 2 and 4 directly from here; I want to switch the ordering anyways so > that the vgif movement immediately precedes the Recalc "instructions" patch. Actually, I partially take that back. I'm going to send a separate v5 for patch 4, as there are additional cleanups that can be done related to Hyper-V stubs. P.S. This is a good example of why bundling unrelated patches into series is discouraged.
On Mon, Mar 2, 2026 at 7:35 PM Sean Christopherson <seanjc@google.com> wrote: > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > > On Mon, Mar 02, 2026, Yosry Ahmed wrote: > > > > Also taking a step back, I am not really sure what's the right thing > > > > to do for Intel-compatible guests here. It also seems like even if we > > > > set the intercept, svm_set_gif() will clear the STGI intercept, even > > > > on Intel-compatible guests. > > > > > > > > Maybe we should leave that can of worms alone, go back to removing > > > > initializing the CLGI/STGI intercepts in init_vmcb(), and in > > > > svm_recalc_instruction_intercepts() set/clear these intercepts based > > > > on EFER.SVME alone, irrespective of Intel-compatibility? > > > > > > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE. > > > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM > > > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the > > > guest enables and uses SVM. > > > > > > /* > > > * Intercept VMLOAD if the vCPU model is Intel in order to emulate that > > > * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing > > > * SVM on Intel is bonkers and extremely unlikely to work). > > > */ > > > if (guest_cpuid_is_intel_compatible(vcpu)) > > > guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD); > > > > > > Sorry for not catching this in previous versions. > > > > Because I got all kinds of confused trying to recall what was different between > > v3 and v4, I went ahead and spliced them together. > > > > Does the below look right? If so, I'll formally post just patches 1 and 3 as v5. > > I'll take 2 and 4 directly from here; I want to switch the ordering anyways so > > that the vgif movement immediately precedes the Recalc "instructions" patch. > > Actually, I partially take that back. I'm going to send a separate v5 for patch > 4, as there are additional cleanups that can be done related to Hyper-V stubs. > Gotcha, if you're sending just patch 4 as v5, then should I send patches 1 and 3 (with fixes) as a new series? > P.S. This is a good example of why bundling unrelated patches into series is > discouraged. > Noted :)
On Tue, Mar 03, 2026, Kevin Cheng wrote: > On Mon, Mar 2, 2026 at 7:35 PM Sean Christopherson <seanjc@google.com> wrote: > > > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > > > On Mon, Mar 02, 2026, Yosry Ahmed wrote: > > > > > Also taking a step back, I am not really sure what's the right thing > > > > > to do for Intel-compatible guests here. It also seems like even if we > > > > > set the intercept, svm_set_gif() will clear the STGI intercept, even > > > > > on Intel-compatible guests. > > > > > > > > > > Maybe we should leave that can of worms alone, go back to removing > > > > > initializing the CLGI/STGI intercepts in init_vmcb(), and in > > > > > svm_recalc_instruction_intercepts() set/clear these intercepts based > > > > > on EFER.SVME alone, irrespective of Intel-compatibility? > > > > > > > > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE. > > > > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM > > > > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the > > > > guest enables and uses SVM. > > > > > > > > /* > > > > * Intercept VMLOAD if the vCPU model is Intel in order to emulate that > > > > * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing > > > > * SVM on Intel is bonkers and extremely unlikely to work). > > > > */ > > > > if (guest_cpuid_is_intel_compatible(vcpu)) > > > > guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD); > > > > > > > > Sorry for not catching this in previous versions. > > > > > > Because I got all kinds of confused trying to recall what was different between > > > v3 and v4, I went ahead and spliced them together. > > > > > > Does the below look right? If so, I'll formally post just patches 1 and 3 as v5. > > > I'll take 2 and 4 directly from here; I want to switch the ordering anyways so > > > that the vgif movement immediately precedes the Recalc "instructions" patch. > > > > Actually, I partially take that back. I'm going to send a separate v5 for patch > > 4, as there are additional cleanups that can be done related to Hyper-V stubs. > > > > Gotcha, if you're sending just patch 4 as v5, then should I send > patches 1 and 3 (with fixes) as a new series? No need, I'll send a v5 for 1 and 3 as well.
On Tue, Mar 3, 2026 at 5:08 PM Sean Christopherson <seanjc@google.com> wrote: > > On Tue, Mar 03, 2026, Kevin Cheng wrote: > > On Mon, Mar 2, 2026 at 7:35 PM Sean Christopherson <seanjc@google.com> wrote: > > > > > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > > > On Mon, Mar 02, 2026, Sean Christopherson wrote: > > > > > On Mon, Mar 02, 2026, Yosry Ahmed wrote: > > > > > > Also taking a step back, I am not really sure what's the right thing > > > > > > to do for Intel-compatible guests here. It also seems like even if we > > > > > > set the intercept, svm_set_gif() will clear the STGI intercept, even > > > > > > on Intel-compatible guests. > > > > > > > > > > > > Maybe we should leave that can of worms alone, go back to removing > > > > > > initializing the CLGI/STGI intercepts in init_vmcb(), and in > > > > > > svm_recalc_instruction_intercepts() set/clear these intercepts based > > > > > > on EFER.SVME alone, irrespective of Intel-compatibility? > > > > > > > > > > Ya, guest_cpuid_is_intel_compatible() should only be applied to VMLOAD/VMSAVE. > > > > > KVM intercepts VMLOAD/VMSAVE to fixup SYSENTER MSRs, not to inject #UD. I.e. KVM > > > > > is handling (the absoutely absurd) case that FMS reports an Intel CPU, but the > > > > > guest enables and uses SVM. > > > > > > > > > > /* > > > > > * Intercept VMLOAD if the vCPU model is Intel in order to emulate that > > > > > * VMLOAD drops bits 63:32 of SYSENTER (ignoring the fact that exposing > > > > > * SVM on Intel is bonkers and extremely unlikely to work). > > > > > */ > > > > > if (guest_cpuid_is_intel_compatible(vcpu)) > > > > > guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD); > > > > > > > > > > Sorry for not catching this in previous versions. > > > > > > > > Because I got all kinds of confused trying to recall what was different between > > > > v3 and v4, I went ahead and spliced them together. > > > > > > > > Does the below look right? If so, I'll formally post just patches 1 and 3 as v5. > > > > I'll take 2 and 4 directly from here; I want to switch the ordering anyways so > > > > that the vgif movement immediately precedes the Recalc "instructions" patch. > > > > > > Actually, I partially take that back. I'm going to send a separate v5 for patch > > > 4, as there are additional cleanups that can be done related to Hyper-V stubs. > > > > > > > Gotcha, if you're sending just patch 4 as v5, then should I send > > patches 1 and 3 (with fixes) as a new series? > > No need, I'll send a v5 for 1 and 3 as well. Sounds good. Thanks Sean
© 2016 - 2026 Red Hat, Inc.