On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote: > On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote: > > 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. There will be no drivers for that, but an mdev is a container for resources of a physical device which can be assigned to a virtual machine or a user-space process. In this way it fits very well into the existing abstractions. > PASID is a property of a PCI device and any PCI device driver should > be able to spawn PASIDs without silly restrictions. Some points here: 1) The concept of PASIDs is not limited to PCI devices. 2) An mdev is not a restriction. It is an abstraction with which other parts of the kernel can work. > Fixing the IOMMU API is clearly needed here to get a clean PASID > implementation in the kernel. You still have to convince me that this is needed and a good idea. By now I am not even remotely convinced and putting words like 'fixing', 'clearly' and 'silly' in a sentence is by far not enough for this to happen. > We aren't talking about mm_struct. Passing an mm_struct to a device is another use-case for PASIDs, you should keep that in mind. The mdev abstraction was made for a different use-case. To be clear, I agree that the aux-domain specifics should be removed from the IOMMU-API, but the mdev-abstraction itself still makes sense. > As above a domain isn't an IOASID, it only does a few things an IOASID > can do. For example? Regards, Joerg
