Messages in this thread | | | Date | Tue, 30 Nov 2021 09:31:05 +0100 | Subject | Re: [PATCH 2/4] KVM: VMX: prepare sync_pir_to_irr for running with APICv disabled | From | Paolo Bonzini <> |
| |
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
| |