On Sun, May 31, 2009 at 10:40:59PM +0300, Avi Kivity wrote: > Michael S. Tsirkin wrote: >> As promised, here's a (compile-tested only) patchset that proposes >> an alternative interrupt injection interface, not using eventfd. >> >> The idea here is that we give user the ability to create "virtual >> device" file descriptors from kvm context, and bind them to in-kernel >> drivers. One kind of such device would be virt_irq which let the user >> inject interrupts. This seems to solve all potential lifetime >> and locking issues because we control file_operations for both kvm fd >> and the device(irq) fd. >> >> Another kind of device could be kernel-level virtio_net_host implementation >> (which is really why I started writing this code). >> >> As an attempt to make virtual devices more useful, they actually use an >> abstract virt_hypervisor interface. I have currently only implemented >> it in kvm, but it will be possible to have lguest implement it as well, >> and then lguest will be able to use e.g. in-kernel virtio-net. >> >> Let's discuss whether we want this, or eventfd, or both. >> > > Certainly not both. > > 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. > 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. 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. -- MST -- 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
