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

[Avi Kivity <avi@redhat.com>]

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.