On Fri, Apr 02, 2021 at 08:22:28AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Tuesday, March 30, 2021 9:29 PM > > > > > > > > First, userspace may use ioasid in a non-SVA scenario where ioasid is > > > bound to specific security context (e.g. a control vq in vDPA) instead of > > > tying to mm. In this case there is no pgtable binding initiated from user > > > space. Instead, ioasid is allocated from /dev/ioasid and then programmed > > > to the intended security context through specific passthrough framework > > > which manages that context. > > > > This sounds like the exact opposite of what I'd like to see. > > > > I do not want to see every subsystem gaining APIs to program a > > PASID. All of that should be consolidated in *one place*. > > > > I do not want to see VDPA and VFIO have two nearly identical sets of > > APIs to control the PASID. > > > > Drivers consuming a PASID, like VDPA, should consume the PASID and do > > nothing more than authorize the HW to use it. > > > > quemu should have general code under the viommu driver that drives > > /dev/ioasid to create PASID's and manage the IO mapping according to > > the guest's needs. > > > > Drivers like VDPA and VFIO should simply accept that PASID and > > configure/authorize their HW to do DMA's with its tag. > > > > I agree with you on consolidating things in one place (especially for the > general SVA support). But here I was referring to an usage without > pgtable binding (Possibly Jason. W can say more here), where the > userspace just wants to allocate PASIDs, program/accept PASIDs to > various workqueues (device specific), and then use MAP/UNMAP > interface to manage address spaces associated with each PASID. > I just wanted to point out that the latter two steps are through > VFIO/VDPA specific interfaces. No, don't do that. VFIO and VDPA has no buisness having map/unmap interfaces once we have /dev/ioasid. That all belongs in the iosaid side. I know they have those interfaces today, but that doesn't mean we have to keep using them for PASID use cases, they should be replaced with a 'do dma from this pasid on /dev/ioasid' interface certainly not a 'here is a pasid from /dev/ioasid, go ahead and configure it youself' interface This is because PASID is *complicated* in the general case! For instance all the two level stuff you are talking about must not leak into every user! Jason
