Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

From: Vlad Zolotarov
Date: Tue Oct 06 2015 - 10:43:59 EST




On 10/06/15 17:38, Michael S. Tsirkin wrote:
On Mon, Oct 05, 2015 at 01:20:11PM +0300, Avi Kivity wrote:
On 10/05/2015 12:49 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Of course it has to be documented, but this just follows vfio.

Eventfd is a natural enough representation of an interrupt; both kvm and
vfio use it, and are also able to share the eventfd, allowing a vfio
interrupt to generate a kvm interrupt, without userspace intervention, and
one day without even kernel intervention.
That's nice and wonderful, but it's not how UIO works today, so this is
now going to be a mix and match type interface, with no justification so
far as to why to create this new api and exactly how this is all going
to be used from userspace.
The intended user is dpdk (http://dpdk.org), which is a family of userspace
networking drivers for high performance networking applications.

The natural device driver for dpdk is vfio, which both provides memory
protection and exposes msi/msix interrupts. However, in many cases vfio
cannot be used, either due to the lack of an iommu (for example, in
virtualized environments) or out of a desire to avoid the iommus performance
impact.

The challenge in exposing msix interrupts to user space is that there are
many of them, so you can't simply poll the device fd. If you do, how do you
know which interrupt was triggered? The solution that vfio adopted was to
associate each interrupt with an eventfd, allowing it to be individually
polled. Since you can pass an eventfd with SCM_RIGHTS, and since kvm can
trigger guest interrupts using an eventfd, the solution is very flexible.

Example code would be even better...



This is the vfio dpdk interface code:

http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c

basically, the equivalent uio msix code would be very similar if uio adopts
a similar interface:

http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/eal_pci_uio.c

(current code lacks msi/msix support, of course).
So you really want a driver that behaves exactly like vfio.
Which immediately begs a question: why not extend vfio
to cover your usecase.

The only "like VFIO" behavior we implement here is binding the MSI-X interrupt notification to eventfd descriptor. This doesn't justifies the hassle of implementing IOMMU-less VFIO mode.





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/