On Thu, Nov 21, 2019 at 03:21:29PM +0800, Jason Wang wrote: > > The role of vfio has traditionally been around secure device > > assignment of a HW resource to a VM. I'm not totally clear on what the > > role if mdev is seen to be, but all the mdev drivers in the tree seem > > to make 'and pass it to KVM' a big part of their description. > > > > So, looking at the virtio patches, I see some intended use is to map > > some BAR pages into the VM. > > Nope, at least not for the current stage. It still depends on the > virtio-net-pci emulatio in qemu to work. In the future, we will allow such > mapping only for dorbell. There has been a lot of emails today, but I think this is the main point I want to respond to. Using vfio when you don't even assign any part of the device BAR to the VM is, frankly, a gigantic misuse, IMHO. Just needing userspace DMA is not, in any way, a justification to use vfio. We have extensive library interfaces in the kernel to do userspace DMA and subsystems like GPU and RDMA are full of example uses of this kind of stuff. Everything from on-device IOMMU to system IOMMU to PASID. If you find things missing then we need to improve those library interfaces, not further abuse VFIO. Further, I do not think it is wise to design the userspace ABI around a simplistict implementation that can't do BAR assignment, and can't support multiple virtio rings on single PCI function. This stuff is clearly too premature. My advice is to proceed as a proper subsystem with your own chardev, own bus type, etc and maybe live in staging for a bit until 2-3 drivers are implementing the ABI (or at the very least agreeing with), as is the typical process for Linux. Building a new kernel ABI is hard (this is why I advised to use a userspace driver). It has to go through the community process at the usual pace. Jason
