Messages in this thread | | | Subject | Re: [PATCH v2 0/6] kvm: level triggered irqfd support | From | Alex Williamson <> | Date | Wed, 27 Jun 2012 08:33:40 -0600 |
| |
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
| |