On Mon, May 17, 2021 at 02:53:16PM +0200, Joerg Roedel wrote: > 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. There world is a lot bigger than just mdev and vfio. > > 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. Do I have to type PASID/stream id/etc/etc in every place? We all know this is gerenal, it is why Intel is picking IOASID for the uAPI name. > 2) An mdev is not a restriction. It is an abstraction with which > other parts of the kernel can work. mdev is really gross, new things should avoid using it. It is also 100% VFIO specific and should never be used outside VFIO. My recent work significantly eliminates the need for mdev at all, the remaining gaps have to do with the way mdev hackily overrides the iommu mechanisms in VFIO. Tying any decision to the assumption that mdev will, or even should, continue is not aligned with the direction things are going. > > 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. Well, I'm sorry, but there is a huge other thread talking about the IOASID design in great detail and why this is all needed. Jumping into this thread without context and basically rejecting all the conclusions that were reached over the last several weeks is really not helpful - especially since your objection is not technical. I think you should wait for Intel to put together the /dev/ioasid uAPI proposal and the example use cases it should address then you can give feedback there, with proper context. In this case the mdev specific auxdomain for PASID use is replaced by sane /dev/ioasid objects - and how that gets implemented through the iommu layer would still be a big TBD. Though I can't forsee any quality implementation of /dev/ioasid being driven by a one io page table per struct device scheme. Hopefully Intel will make the reasons why, and the use cases supporting the desgin, clear in their RFC. > 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. Expect mdev is basically legacy too. Jason
