Re: [PATCH v4 26/30] KVM: x86: Don't treat interrupts as allowed just because a nested run is pending

[Sean Christopherson <seanjc@google.com>]

On Mon, Jun 15, 2026, Yosry Ahmed wrote:
> On Fri, Jun 12, 2026 at 5:04 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > When querying whether or not interrupts (IRQs) are allowed, check for a
> > pending nested run _after_ checking whether or not interrupts are blocked.
> > If L1 is running L2 _without_ nested_exit_on_intr(), i.e. if L1 IRQs can
> > be blocked while running L2, and interrupts will indeed be blocked once the
> > nested VM-Enter to L2 is completed, then KVM should treat interrupts as not
> > being allowed.
> >
> > For injection, this avoids an unnecessary (forced) VM-Exit, as KVM can
> > immediately request an IRQ window, instead of forcing an exit and _then_
> > requesting an IRQ window (because after the forced exit, KVM will see that
> > interrupts are blocked).
> >
> > For non-injection usage, only kvm_vcpu_ready_for_interrupt_injection() is
> > affected in practice.  kvm_vcpu_has_events() is unreachable when a nested
> > run is pending, as KVM clears nested_run_pending prior to calling
> > kvm_emulate_halt_noskip() when putting L2 into HLT via GUEST_ACTIVITY_HLT,
> > and SVM has no equivalent to GUEST_ACTIVITY_STATE.  I.e. the vCPU will
> > always be runnable if a nested run is pending, and thus
> > kvm_arch_vcpu_runnable() => kvm_vcpu_has_events() is effectively dead code,
> > as is __kvm_emulate_halt() => kvm_vcpu_has_events().  Oh, and TDX doesn't
> > support nested VMX.  Similarly, kvm_can_do_async_pf() is unreachable as
> > KVM shouldn't be faulting in memory with a pending nested VM-Enter.
> >
> > As for kvm_vcpu_ready_for_interrupt_injection(), incorrectly treating
> > interrupts as being allowed could result in KVM prematurely exiting to
> > userspace to accept an ExtINT.
> 
> "incorrectly treating interrupts as being allowed" is the status quo,
> that this patch fixes, not sth this patch introduces -- right?

Right.

> The changelog reads like for the non-injection case this change might
> not be the right thing to do, but I don't think this is the case? I
> assume returning false from
> kvm_vcpu_ready_for_interrupt_injection() and kvm_vcpu_has_events() if
> L1's interrupts are blocked while L2 is running is the right thing to
> do?

Yes.

> The code makes sense to me but I am trying to make sense of the changelog.

What part (parts?) is confusing?  Honest question.  I'm trying to reword the
changelog to make it "better", but I'm failing miserable because I don't know
what's wrong :-)