> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Thursday, November 17, 2022 5:01 AM > > This is the remainder of the IOAS data structure. Provide an object called > an io_pagetable that is composed of iopt_areas pointing at iopt_pages, > along with a list of iommu_domains that mirror the IOVA to PFN map. > > At the top this is a simple interval tree of iopt_areas indicating the map > of IOVA to iopt_pages. An xarray keeps track of a list of domains. Based > on the attached domains there is a minimum alignment for areas (which may > be smaller than PAGE_SIZE), an interval tree of reserved IOVA that can't > be mapped and an IOVA of allowed IOVA that can always be mappable. > > The concept of an 'access' refers to something like a VFIO mdev that is > accessing the IOVA and using a 'struct page *' for CPU based access. > > Externally an API is provided that matches the requirements of the IOCTL > interface for map/unmap and domain attachment. > > The API provides a 'copy' primitive to establish a new IOVA map in a > different IOAS from an existing mapping by re-using the iopt_pages. This > is the basic mechanism to provide single pinning. > > This is designed to support a pre-registration flow where userspace would > setup an dummy IOAS with no domains, map in memory and then establish > an > access to pin all PFNs into the xarray. > > Copy can then be used to create new IOVA mappings in a different IOAS, > with iommu_domains attached. Upon copy the PFNs will be read out of the > xarray and mapped into the iommu_domains, avoiding any pin_user_pages() > overheads. > > Tested-by: Nicolin Chen <nicolinc@xxxxxxxxxx> > Tested-by: Yi Liu <yi.l.liu@xxxxxxxxx> > Tested-by: Lixiao Yang <lixiao.yang@xxxxxxxxx> > Tested-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx> > Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx> > Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
