On Wed, Jun 27, 2012 at 08:33:40AM -0600, Alex Williamson wrote: > 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 Yes but eventfd semantics are that of an accumulator so this does not match what a normal eventfd does very well. Anyway, as it's not required now we can argue about it when we get to it. -- 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
