Michael S. Tsirkin wrote:
Version N of irqfd actually had the kernel create the fd, due to
concerns about eventfd's flexibility (thread wakeup vs function call).
As it turned out these concerns were misplaced (well, we still want the
call to happen in process context when available).
I'm afraid there are deep lifetime issues there, and the recent patch
calling eventfd_fget seems to be just papering over the worst of them.
You'll have to be more specific.
I'd really like to stick with eventfd if we can solve all the problems
there, rather than creating yet another interface.
Especially if we want uio to communicate directly with kvm.
Actually, current irqfd might not be able to handle assigned pci devices
because of the trick it does with set_irq(1)/set_irq(0) trick.
Guest drivers for pci devices likely assume the interrupt
is level.
Right. I'm willing to have some userspace mediation for level-triggered
interrupts. It's a corner case anyway as we don't support shared
interrupts on the host, and PCI level-triggered interrupts are very
likely to be shared.
With virt devices, what we'd do is create a virt device that attaches to
uio driver. This would handle interrupts and everything else that needs
to live in kernel
With irqfd, what we do is attach an eventfd to the MSI we're interested
in. Given that eventfds are usable from userspace, we're adding a
non-virt-specific interface to uio that serves kvm well. Both uio and
kvm win.
--
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
