On Tue, Feb 6, 2018 at 5:41 PM, Alex Williamson <alex.william...@redhat.com> wrote: > On Tue, 6 Feb 2018 17:20:08 +0200 > Ran Shalit <ransha...@gmail.com> wrote: > >> On Tue, Feb 6, 2018 at 4:56 PM, Alex Williamson >> <alex.william...@redhat.com> wrote: >> > On Tue, 6 Feb 2018 16:24:06 +0200 >> > Ran Shalit <ransha...@gmail.com> wrote: >> > >> >> Hello, >> >> >> >> I need to write vfio userspace driver for pci express. >> >> I've been searching for some examples of using vfio, but did not find any, >> >> Is there a git/examples of userspace application using vfio ? >> > >> > git://git.qemu.org/qemu.git >> > git://dpdk.org/dpdk >> > https://github.com/andre-richter/rVFIO >> > https://github.com/MicronSSD/unvme >> > https://github.com/awilliam/tests >> >> Thank you. >> I am trying to understand how to use it with dma. >> I've been checking now the links, but did not find yet in the above >> example how to both map DMA memory and read/write from that memory. >> I see that the above test git contains tests which map/unmap DMA, but >> not reading/writing from that dma memory afterwards (there is a >> seperate test which read/write from memory but without dma). >> Is that correct or did I miss something ? Is there any example which >> shows how to both map and then read/write ? > > Initiating DMA is device specific, you need to understand the > programming model of the device for that. The vfio DMA ioctls only map > the buffers through the IOMMU to allow that DMA, they don't control the > device. The unit tests in the last link doesn't have any device > specific code, they're only performing the mapping without actually > initiating device DMA. The QEMU examples also mostly configure DMA but > rely on native drivers within the guest VM to program the device to > initiate DMA. The rVFIO project is also just a wrapper to make vfio > more accessible to scripting languages, so I don't expect actual device > driver code there. DPDK and the NVME driver should have actual driver > code for the device though. In fact there's also an NVME project > within QEMU that makes use of vfio that might have driver code. The > simple logic though is that the DMA map ioctl takes a user provided > virtual buffer and maps it through the IOMMU at the user provided IOVA > (I/O virtual address). It's up to the user to make the device perform > DMA using that IOVA. Note that the IOMMU address width is typically > less than the user virtual address space, so identity mapping the IOVA > to the virtual address is not a good strategy. >
I try to see that I understand the tests code. Seems that I understand most of it except the following: in vfio-pci-device-open-igd.c there is : ... struct vfio_region_info *region; struct vfio_info_cap_header *header; buf = region = malloc(region_info.argsz); ioctl(device, VFIO_DEVICE_GET_REGION_INFO, region)) printf("First cap @%x\n", region->cap_offset); header = buf + region->cap_offset; printf("header ID %x version %x next %x\n", header->id, header->version, header->next); .... I don't understand some stuff here: region and bug point to the same place (vfio_region_info struct) , is it that (buf + region->cap_offset) is a pointer to virtual address which can be accessed just like that (without any allocation)? in dpdk pci_vfio I see that it is accessed in another way, through vfio_dev_fd: ret = pread64(fd, ®, sizeof(reg), VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) + cap_offset); Thank you, Ran >> Another question, just to be sure I'm on the right direction. I wanted >> to write pci express userspace driver (using real device, and not >> related to virtualization). Is vfio a proper solution for this kind of >> thing ? > > Yes, that's exactly what DPDK does. > >> I ask because there are no plenty of examples as I first expected, and >> I try to understand why there are no many, (probably license issues ?) > > vfio is of course part of the kernel and GPL, but userspace drivers are > not necessarily under the same license, so it is possible that the > drivers themselves are more private. DPDK supports several NICs and > I'd guess the NVME driver handles the standard NVME programming model > and could therefore support devices from many vendors. Thanks, > > Alex _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users