On Wed, Apr 07, 2021 at 04:36:54PM -0300, Jason Gunthorpe wrote: > 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?
The vIOMMU is started in bypass, so the device can do DMA to the GPA space until the guest configures the vIOMMU, at which point each VF is either kept in bypass or gets new DMA mappings, which requires the host to tear down the bypass mappings and set up the guest mappings on a per-VF basis (I'm not considering nesting translation in the host kernel for this, because it's not supported by all pIOMMUs and is expensive in terms of TLB and pinned memory). So keeping a single VF per container is simpler, but there are certainly other programming models possible. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
