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. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
