On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote: > * Get a container handle out of /dev/ioasid (or /dev/iommu, really.) > No operation available since we don't know what the device and IOMMU > capabilities are. > > * Attach the handle to a VF. With VFIO that would be > VFIO_GROUP_SET_CONTAINER. That causes the kernel to associate an IOMMU > with the handle, and decide which operations are available. Right, this is basically the point, - the VFIO container (/dev/vfio) and the /dev/ioasid we are talking about have a core of similarity. ioasid is the generalized, modernized, and cross-subsystem version of the same idea. Instead of calling it "vfio container" we call it something that evokes the idea of controlling the iommu. The issue is to seperate /dev/vfio generic functionality from vfio and share it with every subsystem. It may be that /dev/vfio and /dev/ioasid end up sharing a lot of code, with a different IOCTL interface around it. The vfio_iommu_driver_ops is not particularly VFIOy. Creating /dev/ioasid may primarily start as a code reorganization exercise. > * With a map/unmap vIOMMU (or shadow mappings), a single translation level > is supported. With a nesting vIOMMU, we're populating the level-2 > translation (some day maybe by binding the KVM page tables, but > currently with map/unmap ioctl). > > Single-level translation needs single VF per container. Really? Why? Jason
