Re: [PATCH v5 2/2] KVM: nSVM: Always intercept VMMCALL when L2 is active

[Sean Christopherson]

On Wed, Mar 04, 2026, Yosry Ahmed wrote:
> On Tue, Mar 03, 2026 at 04:22:23PM -0800, Sean Christopherson wrote:
> > Always intercept VMMCALL now that KVM properly synthesizes a #UD as
> > appropriate, i.e. when L1 doesn't want to intercept VMMCALL, to avoid
> > putting L2 into an infinite #UD loop if KVM_X86_QUIRK_FIX_HYPERCALL_INSN
> > is enabled.
> > 
> > By letting L2 execute VMMCALL natively and thus #UD, for all intents and
> > purposes KVM morphs the VMMCALL intercept into a #UD intercept (KVM always
> > intercepts #UD).  When the hypercall quirk is enabled, KVM "emulates"
> > VMMCALL in response to the #UD by trying to fixup the opcode to the "right"
> > vendor, then restarts the guest, without skipping the VMMCALL.  As a
> > result, the guest sees an endless stream of #UDs since it's already
> > executing the correct vendor hypercall instruction, i.e. the emulator
> > doesn't anticipate that the #UD could be due to lack of interception, as
> > opposed to a truly undefined opcode.
> > 
> > Fixes: 0d945bd93511 ("KVM: SVM: Don't allow nested guest to VMMCALL into host")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > ---
> >  arch/x86/kvm/svm/hyperv.h | 4 ----
> >  arch/x86/kvm/svm/nested.c | 7 -------
> >  2 files changed, 11 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/svm/hyperv.h b/arch/x86/kvm/svm/hyperv.h
> > index 9af03970d40c..f70d076911a6 100644
> > --- a/arch/x86/kvm/svm/hyperv.h
> > +++ b/arch/x86/kvm/svm/hyperv.h
> > @@ -51,10 +51,6 @@ static inline bool nested_svm_is_l2_tlb_flush_hcall(struct kvm_vcpu *vcpu)
> >  void svm_hv_inject_synthetic_vmexit_post_tlb_flush(struct kvm_vcpu *vcpu);
> >  #else /* CONFIG_KVM_HYPERV */
> >  static inline void nested_svm_hv_update_vm_vp_ids(struct kvm_vcpu *vcpu) {}
> > -static inline bool nested_svm_l2_tlb_flush_enabled(struct kvm_vcpu *vcpu)
> > -{
> > -	return false;
> > -}
> 
> Why is this dropped? We still need it for vmmcall_interception under
> !CONFIG_KVM_HYPERV, right?

Nope, because vmmcall_interception() uses nested_svm_is_l2_tlb_flush_hcall(), and
the previous patch created a stub for that one.  I.e. only the non-stub
CONFIG_KVM_HYPERV=y version references nested_svm_l2_tlb_flush_enabled().