On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote: > On Fri, May 14, 2021 at 10:31:43AM -0300, Jason Gunthorpe wrote: > > There is no place for "domain as a carrier of PASID" > > there. mdev_device should NOT participate in the IOMMU layer because > > it is NOT a HW device. Trying to warp mdev_device into an IOMMU > > presence is already the source of a lot of this hacky code. > > Having the mdev abstraction is way better than making the IOMMU code > IOASID aware. The later requires either new parameters to existing > functions or new functions. With the mdev abstraction no new functions > are needed in the core API. All that does it lock PASID to mdev which is not at all where this needs to go. > Yes, I know, We have the AUX-domain specific functions now, but I > suggested a while back to turn the mdev code into its own bus > implementation and let the IOMMU driver deal with whether it has an mdev > or a pdev. When that is done the aux-specific functions can go away. Yuk, no. PASID is not connected to the driver model. It is inherently wrong to suggest this. PASID is a property of a PCI device and any PCI device driver should be able to spawn PASIDs without silly restrictions. Fixing the IOMMU API is clearly needed here to get a clean PASID implementation in the kernel. > > IOASID represents the IOVA address space. > > No, when it comes to the IOMMU-API, a domain represents an address > space. Intel is building a new uAPI and here IOASID is the word they picked to represent the IOVA address space. How it is mapped to the kernel is TBD, I guess, but domain implies both more and less than a IOASID so it isn't a 1:1 correspondence. > > Two concepts that represent the same thing is not great :) > > Agreed, so an IOASID should be an IOMMU-domain, if its not used for > passing an mm_struct to a device. We aren't talking about mm_struct. As above a domain isn't an IOASID, it only does a few things an IOASID can do. Jason
