Michael S. Tsirkin wrote:
On Sun, May 31, 2009 at 11:30:48PM +0300, Avi Kivity wrote:
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.
My concern is that we do fget on eventfd and keep this reference until
fput is done on vm fd. This works as long as no one else does
similar tricks. Imagine for example eventfd or another fs/ change that makes
eventfd do fget on descriptor X and keep it until fput is done on eventfd.
We'll get resource leak if kvm fd is substituted for X.
What do you think?
I think it's unlikely that eventfd will start hanging on to fds. If it
does, it will have to deal with recursion anyway (eventfd holding on to
itself), so irqfd will be just a part of the problem.
It's better to have one big problem rather than many small problems.
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.
In other words, you want to keep using KVM_IRQ_LINE for this, as well?
We'll need something more than level-triggered interrupts since we need
to pass the acknowledge from the guest to the host somehow.
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.
If you think about virtio-net-host, there's no host interrupt there.
I was talking about uio, sorry.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
