On Tue, Jun 26, 2012 at 11:08:52PM -0600, Alex Williamson wrote: > Ok, let's see how this flies. I actually quite like this, so be > gentle tearing it apart ;) > > I just couldn't bring myself to contort KVM_IRQFD into something > that either sets up an irqfd or specifies a nearly unrelated EOI > eventfd. The solution I've come up with, that also avoids exposing > irq_source_ids to userspace, is to work through the irqfd. If we > setup a level irqfd, we can optionally associate an eoifd with > the same irq_source_id, by passing the irqfd. To do this, we just > need to create a new reference counted object for the source ID > so we don't run into problems ordering release. This means we > end up with a KVM_EOIFD ioctl that has both general usefulness and > can still tie into an irqfd. I like this API. > In patch 6/6 I also include an alternate de-assert mechanism via an > irqfd with the opposite polarity. I don't currently use this, but > it's pretty trivial and at least available in archives now. The nasty bit about that is that if you assert twice then deassert once it's not clear what should happen. But yea, it does not hurt to put them in the archives. > > I don't address whether injecting an edge irqfd really needs an assert > followed by de-assert (I don't know). This new interface really > unties itself from caring. We might be able to consolidate inject > functions at some future point, but it doesn't change how we'd name > flags as it did in the previous version. Thanks, > > Alex -- 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
