[lkml]   [2009]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [KVM PATCH v4 2/2] kvm: add support for irqfd via eventfd-notification interface
Gregory Haskins wrote:
> One thing I was thinking here was that I could create a flag for the
> kvm_irqfd() function for something like "KVM_IRQFD_MODE_CLEAR". This
> flag when specified at creation time will cause the event to execute a
> clear operation instead of a set when triggered. That way, the default
> mode is an edge-triggered set. The non-default mode is to trigger a
> clear. Level-triggered ints could therefore create two irqfds, one for
> raising, the other for clearing.

That's my second choice option.

> An alternative is to abandon the use of eventfd, and allow the irqfd to
> be a first-class anon-fd. The parameters passed to the write/signal()
> function could then indicate the desired level. The disadvantage would
> be that it would not be compatible with eventfd, so we would need to
> decide if the tradeoff is worth it.

I would really like to keep using eventfd. Which is why I asked Davide
about the prospects of direct callbacks (vs wakeups).

> OTOH, I suspect level triggered interrupts will be primarily in the
> legacy domain, so perhaps we do not need to worry about it too much.
> Therefore, another option is that we *could* simply set the stake in the
> ground that legacy/level cannot use irqfd.

This is my preferred option. For a virtio-net-server in the kernel,
we'd service its eventfd in qemu, raising and lowering the pci interrupt
in the traditional way.

But we'd still need to know when to lower the interrupt. How?

error compiling committee.c: too many arguments to function

 \ /
  Last update: 2009-05-07 16:37    [W:0.067 / U:36.792 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site