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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Sep 12, 2022 at 08:40:20PM +1000, David Gibson wrote:

> > > > +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
> 
> Hmm.. only slightly.  What about:
> 
>    Each opt_pages represents a logical linear array of full PFNs.  The
>    PFNs are ultimately derived from userspave VAs via an mm_struct.
>    They are cached in .. <describe the pined_pfns and iommu_domain
>    data structures>

Ok, I have this now:

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 an iommu_domain's IOPTEs or inside the pinned_pages
xarray if they are being "software accessed".

PFN have to be copied between all combinations of storage locations, depending
on what domains are present and what kinds of in-kernel "software access" users
exists. The mechanism ensures that a page is pinned only once.

Thanks
Jason