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. 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. We are not there yet, but I think this is a cleaner abstraction than making the IOMMU-API ioasid-aware. Also because it separates the details of device-partitioning nicely from the IOMMU core code. > To juggle multiple IOASID per HW device the IOMMU API obviously has to > be made IOASID aware. It can't just blindly assume that a struct > device implies the single IOASID to use and hope for the best. The one-device<->one address-space idea is blindly assumed. Simply because the vast amount of devices out there work that way. When ioasids come into the game this changes of course, but we can work that out based on how the ioasids are used. For device partitioning the mdev abstraction work well if it is correctly implemented. The other use-case is device-access to user-space memory, and that is a completely different story. > IOASID represents the IOVA address space. No, when it comes to the IOMMU-API, a domain represents an address space. > 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. Regards, Joerg
