Re: [PATCH RFC untested] kvm_set_irq: report coalesced for clear

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jul 19, 2012 at 10:38:03AM -0600, Alex Williamson wrote:
> Yes, the problem isn't the state.  The original patch works just fine to
> mask and assert the interrupt every time the device signals and
> de-assert and unmask on every EOI.  KVM doesn't need to track this for
> migration (not that we support migration, of course), we can always just
> send an unmask to the device to retrigger an interrupt if needed.

I agree, just let's document this in case emulated devices use EOIFD.

> The thing Michael is trying to avoid is spurious assertions and
> de-assertions by tracking the state machine.  Spurious assertions are
> not really a problem, at least for vfio where the interrupt is masked
> until kvm/qemu tells us to unmask it.  So at any point in time we can
> reset the state machine with an unmask.  Spurious unmasks are
> theoretically a problem if an IRQ is shared among multiple devices we
> can trigger unmasks for devices that haven't been asserted.  vfio
> handles this pretty well though and recognizes the device isn't masked
> and does nothing.
> 
> Something I note out of this discussion is that while the spinlock I use
> to maintain the state machine is ugly, the lock has no contention.

Good point. Overall I'm convinced now it was a good idea.

> I don't think that's necessarily the case with pic_lock.  Anyway, I think
> we can do w/o the spinlock altogether.  Lock contention and spurious
> eois over level triggered interrupts is probably not worth worrying
> about.

Thanks, good summary.

I think I can prove to you spurious wakeups are a problem though:
consider a setup where an IRQ is shared with a userspace device (e.g.
console). If said userspace uses EOIFD you wake up userspace on each
interrupt of an assigned device which is exactly what level IRQFD was
designed to avoid.

-- 
MST