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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
