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:
1. Update max_irr
2. 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
