On 11/29/21 23:14, Sean Christopherson wrote:
Heh, maybe s/max_irr_updated/new_pir_found or so? This is a bit weird:
- Update max_irr
- max_irr_updated = false
Sounds good (I went for got_posted_interrupt).
}
- vmx_hwapic_irr_update(vcpu, max_irr);
- /*
* If virtual interrupt delivery is not in use, the interrupt
* will be processed via KVM_REQ_EVENT, not RVI. This can happen
I'd strongly prefer to phrase this as a command, e.g. "process the interrupt via KVM_REQ_EVENT". "will be processed" makes it sound like some other flow is handling the event, which confused me.
What I wanted to convey is that the interrupt is not processed yet, and the vmentry might have to be canceled. I changed it to
* Newly recognized interrupts are injected via either virtual interrupt * delivery (RVI) or KVM_REQ_EVENT. Virtual interrupt delivery is * disabled in two cases:
* 1) If L2 is running and the vCPU has a new pending interrupt. If L1 * wants to exit on interrupts, KVM_REQ_EVENT is needed to synthesize a * VM-Exit to L1. If L1 doesn't want to exit, the interrupt is injected * into L2, but KVM doesn't use virtual interrupt delivery to inject * interrupts into L2, and so KVM_REQ_EVENT is again needed. * * 2) If APICv is disabled for this vCPU, assigned devices may still * attempt to post interrupts. The posted interrupt vector will cause * a VM-Exit and the subsequent entry will call sync_pir_to_irr. */
Applied these.
Paolo