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

["Pratik R. Sampat" <prsampat@amd.com>]

Hi Sean,

On 9/21/26 12:15 PM, Sean Christopherson wrote:
>>>> +     /*
>>>> +      * 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.

My wording in the comment is misleading. The clear is part of the #VMEXIT path
out of guest mode, where it is indeed unconditional. However, VMRUN can
terminate even before the guest mode is ever entered. With ESMTP, the hardware
can give out a garden variety of exits at the sync point. In this case we
get a VMEXIT that implies the VMRUN never actually ran any guest code then
EVENTINJ won't be cleared. Since the exit code isn't a reliable discriminator,
a non-zero EVENTINJ is the only way to tell.

Thanks,
--Pratik