On Wed, 21 Apr 2021 13:23:07 -0300 Jason Gunthorpe <j...@nvidia.com> wrote:
> On Wed, Apr 21, 2021 at 01:18:07PM +0000, Liu, Yi L wrote: > > > Ideally this new /dev/ioasid interface, and making use of it as a VFIO > > > IOMMU backend, should replace type1. > > > > yeah, just a double check, I think this also requires a new set of uAPIs > > (e.g. new MAP/UNMAP), which means the current VFIO IOMMU type1 related > > ioctls > > would be deprecated in future. right? > > This is something to think about, it might make sense to run the > current ioctls in some "compat" mode under /dev/ioasid just to make > migration easier Right, deprecating type1 doesn't necessarily mean deprecating the uAPI. We created a type1v2 with minor semantic differences in unmap behavior within the same uAPI. Userspace is able to query and select an IOMMU backend model and each model might have a different uAPI. The SPAPR IOMMU backend already takes advantage of this, using some ioctls consistent with type1, but also requiring some extra steps. Also note that the simple MAP and UNMAP uAPI of type1 has its limitations, which we already struggle with. See for example the massive performance issues backing a vIOMMU with this uAPI. The /dev/ioasid approach should alleviate some of that, using a page table for the 1st level, but a more advanced uAPI for the 2nd level seems necessary at some point as well. > In this sense /dev/ioasid would be a container that holds multiple > IOASIDs and every new format ioctl specifies the IOASID to operate > on. The legacy ioctls would use some default IOASID but otherwise act > the same. > > I'm assuming here there is nothing especially wrong with the /dev/vfio > interface beyond being in the wrong place in the kernel and not > supporting multiple IOASIDs? > > Then there may be a fairly simple approch to just make /dev/vfio == > /dev/ioasid, at least for type 1. > > By this I mean we could have the new /dev/ioasid code take over the > /dev/vfio char dev and present both interfaces, but with the same > fops. That's essentially replacing vfio-core, where I think we're more talking about /dev/ioasid being an available IOMMU backend driver which a user can select when available. The interface of making that selection might change to accept an external /dev/ioasid file descriptor, of course. Maybe you can elaborate on how the vfio device and group uAPI live (or not) in this new scheme were /dev/ioasid is the primary interface. Thanks, Alex _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
