Re: [PATCH RFC v2 02/13] iommufd: Overview documentation

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Sep 07, 2022 at 11:39:51AM +1000, David Gibson wrote:

> > +expected to deprecate any proprietary IOMMU logic, if existing (e.g.
> 
> I don't thing "propietary" is an accurate description.  Maybe
> "existing" or "bespoke?

How about "internal"

 These drivers are eventually expected to deprecate any internal IOMMU
 logic, if existing (e.g. vfio_iommu_type1.c).

> > +All user-visible objects are destroyed via the IOMMU_DESTROY uAPI.
> > +
> > +Linkage between user-visible objects and external kernel datastructures are
> > +reflected by dotted line arrows below, with numbers referring to certain
> 
> I'm a little bit confused by the reference to "dotted line arrows": I
> only see one arrow style in the diagram.

I think this means all the "dashed lines with arrows"

How about "by the directed lines below"

> > +The iopt_pages is the center of the storage and motion of PFNs. Each iopt_pages
> > +represents a logical linear array of full PFNs. PFNs are stored in a tiered
> > +scheme:
> > +
> > + 1) iopt_pages::pinned_pfns xarray
> > + 2) An iommu_domain
> > + 3) The origin of the PFNs, i.e. the userspace pointer
> 
> I can't follow what this "tiered scheme" is describing.

Hum, I'm not sure how to address this.

Is this better?

 1) PFNs that have been "software accessed" stored in theiopt_pages::pinned_pfns
    xarray
 2) PFNs stored inside the IOPTEs accessed through an iommu_domain
 3) The origin of the PFNs, i.e. the userspace VA in a mm_struct

Thanks,
Jason