On Tue, Apr 13, 2021 at 8:15 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> 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/a9441aea2780da8c93da1c73da860219f98438de/pkg/sentry/platform/kvm/bluepill_amd64_unsafe.go#L105 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 >
