On Tue, Apr 13, 2021 at 8:15 PM Paolo Bonzini pbonzini@redhat.com wrote:
On 13/04/21 13:03, Lai Jiangshan wrote:
This patch claims that it has a place to stash the IRQ when EFLAGS.IF=0, but inject_pending_event() seams to ignore EFLAGS.IF and queues the IRQ to the guest directly in the first branch of using "kvm_x86_ops.set_irq(vcpu)".
This is only true for pure-userspace irqchip. For split-irqchip, in which case the "place to stash" the interrupt is vcpu->arch.pending_external_vector.
For pure-userspace irqchip, KVM_INTERRUPT only cares about being able to stash the interrupt in vcpu->arch.interrupt.injected. It is indeed wrong for userspace to call KVM_INTERRUPT if the vCPU is not ready for interrupt injection, but KVM_INTERRUPT does not return an error.
Thanks for the reply.
May I ask what is the correct/practical way of using KVM_INTERRUPT ABI for pure-userspace irqchip.
gVisor is indeed a pure-userspace irqchip, it will call KVM_INTERRUPT when kvm_run->ready_for_interrupt_injection=1 (along with other conditions unrelated to our discussion).
https://github.com/google/gvisor/blob/a9441aea2780da8c93da1c73da860219f98438...
if kvm_run->ready_for_interrupt_injection=1 when expection pending or EFLAGS.IF=0, it would be unexpected for gVisor.
Thanks Lai
Ignoring the fact that this would be incorrect use of the API, are you saying that the incorrect injection was not possible before this patch?
Paolo