Re: [PATCH v4 04/17] iommufd: Document overview of iommufd

Jason Gunthorpe
2022-11-15T00:52:42Z

On Mon, Nov 14, 2022 at 09:50:56PM +0100, Eric Auger wrote:

> > +IOMMUFD is the user API to control the IOMMU subsystem as it relates to managing
> > +IO page tables from userspace using file descriptors. It intends to be general
> > +and consumable by any driver that wants to expose DMA to userspace. These
> > +drivers are eventually expected to deprecate any internal IOMMU logic if exists
> they may already/historically implement (eg. vfio_iommu_type1.c)?

Done

> > +2. IOMMUFD_OBJ_DEVICE is created when an external driver calls the IOMMUFD kAPI
> > + to bind a device to an iommufd. The driver is expected to implement proper a
> s/proper/properly?
> > + set of ioctls to allow userspace to initiate the binding operation.
> > + Successful completion of this operation establishes the desired DMA ownership
> > + over the device. The driver must also set the driver_managed_dma flag and
> > + must not touch the device until this operation succeeds.

I don't know what this was suppose to say, lets delete the word proper

> > +3. IOMMUFD_OBJ_HW_PAGETABLE is created when an external driver calls the IOMMUFD
> > + kAPI to attach a bound device to an IOAS. Similarly the external driver uAPI
> > + allows userspace to initiate the attaching operation. If a compatible
> > + pagetable already exists then it is reused for the attachment. Otherwise a
> > + new pagetable object and iommu_domain is created. Successful completion of
> > + this operation sets up the linkages among IOAS, device and iommu_domain. Once
> > + this completes the device could do DMA.
> > +
> > + Every iommu_domain inside the IOAS is also represented to userspace as a
> > + HW_PAGETABLE object.
> > +
> > + .. note::
> > +
> > + Future IOMMUFD updates will provide an API to create and manipulate the
> > + HW_PAGETABLE directly.
> > +
> > +A device can only bind to an iommufd due to DMA ownership claim and attach to at
> > +most one IOAS object (no support of PASID yet).
> > +
> > +Currently only PCI device is allowed to use IOMMUFD.
> is it still true? device_bind() now takes a struct device *
>
> In [PATCH v4 12/17] iommufd: Add kAPI toward external drivers for
> physical devices "PCI" is used at several places
> but shouldn't it be removed now?

Right, gone

> > +- struct io_pagetable holding the IOVA map
> > +- struct iopt_areas representing populated portions of IOVA
> > +- struct iopt_pages representing the storage of PFNs
> > +- struct iommu_domain representing the IO page table in the IOMMU
> > +- struct iopt_pages_access representing in-kernel users of PFNs
> > +- struct xarray pinned_pfns holding a list of pages pinned by in-kernel users
> > +
> > +Each iopt_pages represents a logical linear array of full PFNs. The PFNs are
> > +ultimately derived from userspave VAs via an mm_struct. Once they have been
> > +pinned the PFN is stored in IOPTEs of an iommu_domain or inside the pinned_pages
> s/is/are

Ah it should be "Once they have been pinned the PFNs are stored in
IOPTEs" as the whole thing is refering to plural PFNs

Thanks,
Jason