Re: [PATCH 0/3] RFC: virtual device as irq injection interface

Michael S. Tsirkin
2009-05-31T20:10:57Z

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