KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs

In cases like IPI, we could be queueing an interrupt for a VCPU
that is already running and is not about to exit, because the
VCPU has entered the VM with the interrupt pending and would
not trap on EOI'ing that interrupt. This could result to delays
in interrupt deliveries or even loss of interrupts.
To guarantee prompt interrupt injection, here we have to try to
kick the VCPU.

Signed-off-by: Shih-Wei Li <shihwei@cs.columbia.edu>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

authored by Shih-Wei Li and committed by Marc Zyngier d42c7970 112b0b8f

Changed files
+12
virt
kvm
arm
vgic
+12
virt/kvm/arm/vgic/vgic.c
··· 273 273 * no more work for us to do. 274 274 */ 275 275 spin_unlock(&irq->irq_lock); 276 + 277 + /* 278 + * We have to kick the VCPU here, because we could be 279 + * queueing an edge-triggered interrupt for which we 280 + * get no EOI maintenance interrupt. In that case, 281 + * while the IRQ is already on the VCPU's AP list, the 282 + * VCPU could have EOI'ed the original interrupt and 283 + * won't see this one until it exits for some other 284 + * reason. 285 + */ 286 + if (vcpu) 287 + kvm_vcpu_kick(vcpu); 276 288 return false; 277 289 } 278 290