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

[Pratik R. Sampat]

On 9/21/26 9:16 AM, Sean Christopherson wrote:
> On Mon, Sep 14, 2026, Pratik R. Sampat wrote:
>> When injecting an event into the guest via the event_inj field, a
>> non-zero event_inj value on #VMEXIT means that the hardware was not able
>> to inject the event into the guest.  This used to only occur for the
>> VMEXIT_INVALID intercept code, which was a fatal error and resulted in
>> the guest being torn down.
>>
>> Enhanced SMT Protection (ESMTP) invalidates that assumption.  When ESMTP
>> is enabled, VMRUN doesn't enter guest mode immediately; it stalls at a
>> synchronization point until every sibling thread is either idle or has
>> executed VMRUN for a legal sibling vCPU.  If an ESMTP timeout / illegal
>> sibling exit / interrupt arrives while VMRUN is stalled, VMRUN can now
>> terminate with the corresponding #VMEXIT intercept code, without
>> entering guest mode, and thus without injecting the event.
>>
>> For example, on a 2-way SMT core running vCPU0 on thread 0 and vCPU1 on
>> thread 1:
>>   Thread 0 (vCPU0)                         Thread 1 (vCPU1)
>>   ----------------                         ----------------
>>   Interrupt A injected to the guest             in host
>>   VMRUN                                           |
>>     |                                             |
>>     v                                             |
>>   Stall waiting for sibling                       |
>>     |                                             |
>>     |  host INTR arrives on thread 0              |
>>     |  while it waits                             |
>>     |                                             |
>>     v                                             |
>>   #VMEXIT                                         v
>>   Interrupt B injected to the guest              idle
>>   VMRUN
> 
> So how is KVM_RUN_FORCE_IMMEDIATE_EXIT supposed to work?

I don't think KVM_RUN_FORCE_IMMEDIATE_EXIT should be affected negatively right?

On SVM, it queues a self-IPI before VMRUN. Normally, VMRUN enters the guest,
consumes EVENTINJ, and then exits with VMEXIT_INTR; EXITINTINFO may describe
interrupted event delivery.

With ESMTP, the pending IPI could terminate a stalled VMRUN before guest entry.
EVENTINJ would remain valid, and this patch would requeue it for another
attempt. That should preserve the intended behavior across retries. Of course,
progress would still be gated on it being a legal sibling to begin with, but
that should be fine.

Thanks,
--Pratik