On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote: > > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a PASID > > control char dev (eg /dev/sva, or maybe /dev/iommu) seems like a > > reasonable starting point for discussion. > > I am not sure what can really be consolidated in /dev/sva. More or less, everything in this patch. All the manipulations of PASID that are required for vIOMMU use case/etc. Basically all PASID control that is not just a 1:1 mapping of the mm_struct. > will have their own kerne-user interfaces anyway for their usage models. > They are just providing the specific transport while sharing generic IOMMU > UAPIs and IOASID management. > As I mentioned PASID management is already consolidated in the IOASID layer, > so for VDPA or other users, it just matter of create its own ioasid_set, > doing allocation. Creating the PASID is not the problem, managing what the PASID maps to is the issue. That is all uAPI that we don't really have today. > IOASID is also available to the in-kernel users which does not > need /dev/sva AFAICT. For bare metal SVA, I don't see a need to create this > 'floating' state of the PASID when created by /dev/sva. PASID allocation > could happen behind the scene when users need to bind page tables to a > device DMA stream. My point is I would like to see one set of uAPI ioctls to bind page tables. I don't want to have VFIO, VDPA, etc, etc uAPIs to do the exact same things only slightly differently. If user space wants to bind page tables, create the PASID with /dev/sva, use ioctls there to setup the page table the way it wants, then pass the now configured PASID to a driver that can use it. Driver does not do page table binding. Do not duplicate all the control plane uAPI in every driver. PASID managment and binding is seperated from the driver(s) that are using the PASID. Jason
