On Tue, Sep 27, 2022 at 02:33:31PM -0300, Jason Gunthorpe wrote: > 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. LGTM, thanks. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
