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

["Michael S. Tsirkin" <mst@redhat.com>]

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'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?


> 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.

>> 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.