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

[Avi Kivity <avi@redhat.com>]

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.

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

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

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.