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

Jason Gunthorpe
2022-09-09T18:52:34Z

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