Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > If the guest issues an INT command targetting a VLPI, let's > call into the irq_set_irqchip_state() helper to make it pending > on the physical side. > > This works just as well if userspace decides to inject an interrupt > using the normal userspace API... There is also another path: KVM_SIGNAL_MSI ioctl / kvm_send_userspace_msi / kvm_set_msi / vgic_its_inject_msi / vgic_its_trigger_msi I wonder whether we shouldn't prevent the userspace from messing up with the host irq pending state? Thanks Eric > > Acked-by: Christoffer Dall <cdall@xxxxxxxxxx> > Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> > --- > virt/kvm/arm/vgic/vgic-its.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c > index 89768d2b6a91..b2a678d131d0 100644 > --- a/virt/kvm/arm/vgic/vgic-its.c > +++ b/virt/kvm/arm/vgic/vgic-its.c > @@ -578,6 +578,10 @@ static int vgic_its_trigger_msi(struct kvm *kvm, struct vgic_its *its, > if (err) > return err; > > + if (irq->hw) > + return irq_set_irqchip_state(irq->host_irq, > + IRQCHIP_STATE_PENDING, true); > + > spin_lock(&irq->irq_lock); > irq->pending_latch = true; > vgic_queue_irq_unlock(kvm, irq); > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
