On Mon, Oct 05, 2015 at 01:20:11PM +0300, Avi Kivity wrote:
On 10/05/2015 12:49 PM, Greg KH wrote:So you really want a driver that behaves exactly like vfio.
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:The intended user is dpdk (http://dpdk.org), which is a family of userspace
Of course it has to be documented, but this just follows vfio.That's nice and wonderful, but it's not how UIO works today, so this is
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.
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.
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).
Which immediately begs a question: why not extend vfio
to cover your usecase.