On Thu, Sep 17, 2020 at 11:53:49AM +0800, Jason Wang wrote: > > > When VDPA is used by qemu it makes sense that the PASID will be an > > > arbitary IOVA map constructed to be 1:1 with the guest vCPU physical > > > map. /dev/sva allows a single uAPI to do this kind of setup, and qemu > > > can support it while supporting a range of SVA kernel drivers. VDPA > > > and vfio-mdev are obvious initial targets. > > > > > > *BOTH* are needed. > > > > > > In general any uAPI for PASID should have the option to use either the > > > mm_struct SVA PASID *OR* a PASID from /dev/sva. It costs virtually > > > nothing to implement this in the driver as PASID is just a number, and > > > gives so much more flexability. > > > > > Not really nothing in terms of PASID life cycles. For example, if user > > uses uacce interface to open an accelerator, it gets an FD_acc. Then it > > opens /dev/sva to allocate PASID then get another FD_pasid. Then we > > pass FD_pasid to the driver to bind page tables, perhaps multiple > > drivers. Now we have to worry about If FD_pasid gets closed before > > FD_acc(s) closed and all these race conditions. > > > I'm not sure I understand this. But this demonstrates the flexibility of an > unified uAPI. E.g it allows vDPA and VFIO device to use the same PAISD which > can be shared with a process in the guest. > > For the race condition, it could be probably solved with refcnt. Yep Jason
