Gregory Haskins wrote:
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.
But again, you're forcing everyone who uses irqfd to require eventfd.
Maybe we should change eventfd_signal() to fall back to ->write if the
file happens not to be an eventfd. It could also handle the
nonpreemptible context as well.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
