Re: [KVM PATCH v2 2/2] kvm: add support for irqfd via eventfd-notification interface

Avi Kivity wrote:
Avi Kivity wrote:

So what is your proposal for such interface?



->write().


Alternatively, a new fileop ->signal_event(), which would map to
eventfd_signal() or irqfd_signal(). This would be defined to work in
irq contexts. It may also be useful for uio interrupts.

Hmm...I'm not crazy about either of those. write() has obvious
limitations both from a interrupt execution context, as well as the
awkwardness of dealing with creating+passing a viable "userspace"
pointer from kernel code. On the other hand, a new fileop doesn't quite
seem appropriate either since it doesn't apply to the overall fileop
abstraction very well.

We could potentially have a separate vtable interface just for
event-type fds, and make eventfd and irqfd the first implementations.
But I am not sure it is worth it. What I suggest is that we work within
the existing eventfd interface. It was designed specifically to signal
events, after all.

If at some point in the future we need to ensure that the callbacks are
not invoked from a preempt-off/irq-off critical section, we can revist
the eventfd internals at that time. Note that since we would like to
support signaling from interrupt context anyway, trying to get rid of
the wqh critical section that we have today may be a fools errand (*).
Instead, we should probably focus on making the injection path support
non-preemptible contexts, as this will have the biggest benefits and
gains in the long run.

Thoughts?
-Greg

(*) The biggest benefit is that you can do tricks like
"if (preemptible()) do_it_now(); else
do_it_later();"


Attachment: signature.asc
Description: OpenPGP digital signature

Relevant Pages

  • Re: implementing roles in OOP......
    ... > e.g. a person is a member of a network of family members and a member ... > bla bla bla ... the fact that I have two different contexts ... > I can ask the object for a reference to an interface to that role (and ...
    (comp.object)
  • Re: Speed of interfaces vs inheritance
    ... on an external class in a tight loop. ... different contexts. ... and have the various different classes extend it. ... I seem to recall, in years past, that the interface approach was slower. ...
    (comp.lang.java.programmer)
  • Re: Speed of interfaces vs inheritance
    ... an external class in a tight loop. ... contexts. ... various different classes extend it. ... I seem to recall, in years past, that the interface approach was slower. ...
    (comp.lang.java.programmer)