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

Jason Gunthorpe
2022-09-27T17:33:50Z

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