On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote: > "its own special way" is arguable, VFIO is just making use of what's > being proposed as the uapi via its existing IOMMU interface. I mean, if we have a /dev/sva then it makes no sense to extend the VFIO interfaces with the same stuff. VFIO should simply accept a PASID created from /dev/sva and use it just like any other user-DMA driver would. > are also a system resource, so we require some degree of access control > and quotas for management of PASIDs. This has already happened, the SVA patches generally allow unpriv user space to allocate a PASID for their process. If a device implements a mdev shared with a kernel driver (like IDXD) then it will be sharing that PASID pool across both drivers. In this case it makes no sense that VFIO has PASID quota logic because it has an incomplete view. It could only make sense if VFIO is the exclusive owner of the bus/device/function. The tracking logic needs to be global.. Most probably in some kind of PASID cgroup controller? > know whether an assigned device requires PASIDs such that access to > this dev file is provided to QEMU? Wouldn't QEMU just open /dev/sva if it needs it? Like other dev files? Why would it need something special? > would be an obvious DoS path if any user can create arbitrary > allocations. If we can move code out of VFIO, I'm all for it, but I > think it needs to be better defined than "implement magic universal sva > uapi interface" before we can really consider it. Thanks, Jason began by saying VDPA will need this too, I agree with him. I'm not sure why it would be "magic"? This series already gives a pretty solid blueprint for what the interface would need to have. Interested folks need to sit down and talk about it not just default everything to being built inside VFIO. Jason
