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

Avi Kivity
2009-05-31T20:30:41Z

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.