On Wed, Aug 25, 2021 at 07:32:37AM +0200, Christoph Hellwig wrote: > On Tue, Aug 24, 2021 at 09:19:16PM -0300, Jason Gunthorpe wrote: > > The mechanism looks fine, but I think the core code is much clearer if > > the name is not 'mediated' but 'sw_iommu' or something that implies > > the group is running with a software page table. mediated has become > > so overloaded in this code. > > I thought that was sort of the definition of mediated - there needs to > ben entify that "mediates" access so that a user of this interface > can't trigger undmediated DMA to arbitrary addresses. My other choice > that I used for a while was "virtual". sw_iommu sounds a little clumsy. vfio mediated is really some toolbox of different features that a driver can use to build what it wants. For instance Intel is looking at this concept of a mediated device that uses PASID for the IOMMU. It would have a real IOMMU, use real IOMMU page tables and in this language it would create some PASID group, not a "sw_iommu" group. This feature is about creating a device that is not connected to a HW IO page table (at least by the VFIO iommu code) but the IO page table is held in software and accessed by the VFIO driver through the pin API. virtual_iommu is somewhat overloaded with the idea of a vIOMMU created by qemu and stuffed into a guest.. "domainless" might work but I also find it confusing that the iommu code uses the word domain to refer to a HW IO page table :\ Maybe "sw io page table" ? Jason
