On Wed, 2012-06-27 at 12:58 +0300, Michael S. Tsirkin wrote: > 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. Yay! I'll work on the bugs you've spotted. > > 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. It's no different that KVM_IRQ_LINE in that sense. It's not an accumulator, it's a set state. 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
