Re: [PATCH 1/3] KVM: SVM: Re-queue events that were never injected

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 17, 2026, Pratik R. Sampat wrote:
> 
> 
> On 9/14/26 1:16 PM, sashiko-bot@kernel.org wrote:
> > [You don't often get email from sashiko-bot@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] svm_complete_interrupts() incorrectly checks if (control->event_inj) instead of the SVM_EVTINJ_VALID bit, which can silently drop valid hardware-reported events (like guest page faults) by clobbering EXITINTINFO.
> > --
> > 
> > commit 50716e3ba11eb9d000a0186ffad984ac08df1dcb
> > Author: Pratik R. Sampat <prsampat@amd.com>
> > 
> > KVM: SVM: Re-queue events that were never injected
> > 
> > When injecting an event into the guest via the event_inj field, a non-zero
> > event_inj value on #VMEXIT means the hardware was unable to inject it.
> > This commit adds a check to recover potentially lost interrupts by detecting
> > an undelivered injected event and re-queuing it.
> > 
> >> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> >> index d0971685034b9..e2be2cd86c320 100644
> >> --- a/arch/x86/kvm/svm/svm.c
> >> +++ b/arch/x86/kvm/svm/svm.c
> > [ ... ]
> >> @@ -4323,6 +4324,27 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
> >>       svm->nmi_l1_to_l2 = false;
> >>       svm->soft_int_injected = false;
> >>
> >> +     /*
> >> +      * Hardware clears EVENTINJ field when it injects an event.
> >> +      * A non-empty EVENTINJ on #VMEXIT means the vCPU never entered guest
> >> +      * mode, and thus that the event was never delivered.  Migrate the event
> >> +      * to EXITINTINFO so that it's requeued instead of being dropped.
> >> +      *
> >> +      * An undelivered event doesn't imply a fatal VMEXIT_INVALID. With
> >> +      * Enhanced SMT Protection, VMRUN may exit with an ordinary #VMEXIT
> >> +      * without having injected that event into the guest.
> >> +      *
> >> +      * Clobbering EXITINTINFO is safe precisely because the vCPU never
> >> +      * entered guest mode.
> >> +      */
> >> +     if (control->event_inj) {
> > [Severity: High]
> > Does this code silently drop valid hardware-reported events?
> > 
> > If an L1 hypervisor sets event_inj to a non-zero value but leaves the
> > SVM_EVTINJ_VALID bit clear, hardware will ignore the injection and won't
> > clear EVENTINJ.
> 
> 
> The first half is right, nested_svm_check_event_inj() intentionally returns
> true when V is clear, so vmcb02->control.event_inj can be non-zero with V=0.
> 
> The second half isn't. Clearing EVENTINJ is not part of injection, it's part of
> #VMEXIT, and it's unconditional. 

So that doesn't mesh with the above comment, which says:

  Hardware clears EVENTINJ field when it injects an event.

And it begs the question of how this patch is at all useful.  Because all this
fancy new paranoia is clearly generating #VMEXITs, and if #VMEXIT unconditionally
clears control->event_inj, I don't see how control->event_inj can be non-zero if
KVM attempted VMRUN.

I.e. either this is all broken, or the APM is buggy.