On Fri, May 14, 2021 at 12:58:10PM +0000, Tian, Kevin wrote: > This avoids changing every iommu ops to include a PASID and forcing > the upper-layer drivers to do it differently between pdev and mdev. > Actually this was a main motivation when working out aux domain > proposal with Joerg two years ago. Well, usually when people say stuff like that it means it is a hack.. Oh, this does look like a big hack, yes. /dev/ioasid is focused on IOASIDs. As an API you have to be able to use it to create all kinds of IOASID's *against a single HW struct device*. In this world you can't create domains for every struct device as hack to pass in the PASID. The IOASID itself must be an object that contains the HW struct device and the PASID. IOASID must be a first class object in the entire API. Remember, when a driver wants to connect to an IOASID it wants to make some very simple calls like: iommu_attach_ioasid_rid(&pci_device->dev, ioasid_ptr); iommu_attach_ioasid_pasid(&pci_device->dev, ioasid_ptr); Which is based *only* on what the PCI device does. If the device issues TLPs without PASID then the driver must use the first. If the device issues TLPs with a PASID then the driver must use the latter. 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. 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 reason is that iommu domain represents an IOVA address > space shareable by multiple devices. It should be created at the > point where the address space is managed. IOASID represents the IOVA address space. Two concepts that represent the same thing is not great :) Jason
