From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Kevin Cheng <chengkev@google.com>,
pbonzini@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 1/5] KVM: SVM: Move STGI and CLGI intercept handling
Date: Thu, 15 Jan 2026 09:00:07 -0800 [thread overview]
Message-ID: <aWkdF8gz1IDssQOd@google.com> (raw)
In-Reply-To: <xndoethnkd2djh5zkemvgmuj6gc4hsnxur2uo5frl57ugxa2ql@c3k7cadxmr4u>
On Thu, Jan 15, 2026, Yosry Ahmed wrote:
> On Wed, Jan 14, 2026 at 05:39:13PM -0800, Sean Christopherson wrote:
> > On Mon, Jan 12, 2026, Yosry Ahmed wrote:
> > As for how to fix this, a few ideas:
> >
> > 1. Set KVM_REQ_EVENT to force KVM to re-evulate all events. kvm_check_and_inject_events()
> > will see the pending NMI and/or SMI, that the NMI/SMI is not allowed, and
> > re-call enable_{nmi,smi}_window().
> >
> > 2. Manually check for pending+blocked NMI/SMIs.
> >
> > 3. Combine parts of #1 and #2. Set KVM_REQ_EVENT, but only if there's a pending
> > NMI or SMI.
> >
> > 4. Add flags to vcpu_svm to explicitly track if a vCPU has an NMI/SMI window,
> > similar to what we're planning on doing for IRQs[*], and use that to more
> > confidently do the right thing when recomputing intercepts.
> >
> > I don't love any of those ideas. Ah, at least not until I poke around KVM. In
> > svm_set_gif() there's already this:
> >
> > if (svm->vcpu.arch.smi_pending ||
> > svm->vcpu.arch.nmi_pending ||
> > kvm_cpu_has_injectable_intr(&svm->vcpu) ||
> > kvm_apic_has_pending_init_or_sipi(&svm->vcpu))
> > kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
> >
> > So I think it makes sense to bundle that into a helper, e.g. (no idea what to
> > call it)
> >
> > static bool svm_think_of_a_good_name(struct kvm_vcpu *vcpu)
> > {
> > if (svm->vcpu.arch.smi_pending ||
> > svm->vcpu.arch.nmi_pending ||
> > kvm_cpu_has_injectable_intr(&svm->vcpu) ||
> > kvm_apic_has_pending_init_or_sipi(&svm->vcpu))
> > kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
> > }
>
> Maybe svm_check_gif_events() or svm_check_gif_interrupts()?
>
> Or maybe it's clearer if we just put the checks in a helper like
> svm_waiting_for_gif() or svm_pending_gif_interrupt().
This was my first idea as well, though I would name it svm_has_pending_gif_event()
to better align with kvm_vcpu_has_events().
I suggested a single helper because I don't love that how to react to the pending
event is duplicated. But I definitely don't object to open coding the request if
the consensus is that it's more readable overall.
> Then in svm_recalc_instruction_intercepts() we do:
>
> /*
> * If there is a pending interrupt controlled by GIF, set
> * KVM_REQ_EVENT to re-evaluate if the intercept needs to be set
> * again to track when GIF is re-enabled (e.g. for NMI
> * injection).
> */
> svm_clr_intercept(svm, INTERCEPT_STGI);
> if (svm_pending_gif_interrupt())
> kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
>
> and in svm_set_gif() it reads well semantically:
>
> enable_gif(svm);
> if (svm_pending_gif_interrupt())
> kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
next prev parent reply other threads:[~2026-01-15 17:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 17:45 [PATCH V2 0/5] Align SVM with APM defined behaviors Kevin Cheng
2026-01-12 17:45 ` [PATCH V2 1/5] KVM: SVM: Move STGI and CLGI intercept handling Kevin Cheng
2026-01-12 20:37 ` Yosry Ahmed
2026-01-15 1:39 ` Sean Christopherson
2026-01-15 16:41 ` Yosry Ahmed
2026-01-15 17:00 ` Sean Christopherson [this message]
2026-01-15 17:05 ` Yosry Ahmed
2026-01-15 17:29 ` Sean Christopherson
2026-01-22 4:59 ` Kevin Cheng
2026-01-12 17:45 ` [PATCH V2 2/5] KVM: SVM: Inject #UD for STGI if EFER.SVME=0 and SVM Lock and DEV are not available Kevin Cheng
2026-01-12 20:50 ` Yosry Ahmed
2026-01-22 5:02 ` Kevin Cheng
2026-01-12 17:45 ` [PATCH V2 3/5] KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 Kevin Cheng
2026-01-12 20:51 ` Yosry Ahmed
2026-01-12 17:45 ` [PATCH V2 4/5] KVM: SVM: Recalc instructions intercepts when EFER.SVME is toggled Kevin Cheng
2026-01-12 17:45 ` [PATCH V2 5/5] KVM: SVM: Raise #UD if VMMCALL instruction is not intercepted Kevin Cheng
2026-01-12 20:54 ` Yosry Ahmed
2026-01-14 5:20 ` Manali Shukla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWkdF8gz1IDssQOd@google.com \
--to=seanjc@google.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yosry.ahmed@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox