On Fri, Nov 22, 2019 at 04:45:38PM +0800, Jason Wang wrote: > > On 2019/11/21 下午10:17, Jason Gunthorpe wrote: > > 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. > > That's not a compelling point. Well, this discussion is going nowhere. > > 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. > > I'm not sure which library did you mean here. Is any of those library used > by qemu? If not, what's the reason? I mean the library functions in the kernel that vfio uses to implement all the user dma stuff. Other subsystems use them too, it is not exclusive to vfio. > > Further, I do not think it is wise to design the userspace ABI around > > a simplistict implementation that can't do BAR assignment, > > Again, the vhost-mdev follow the VFIO ABI, no new ABI is invented, and > mmap() was kept their for mapping device regions. The patches have a new file in include/uapi. Everything in include/api is considered new user ABI. > > 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. > > I'm open to comments for sure, but looking at all the requirement for vDPA, > most of the requirement could be settled through existed modules, that's not > only a simplification for developing but also for management layer or > userspace drivers. We've already got disagreement that the GUID based mdev approach is desirable for management. Performing userspace DMA from a kernel driver is absolutely not a reason to use VFIO. Is there any technical justification? Jason
