Re: [PATCH v3] io: add io_pgtable abstraction

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Nov 12, 2025 at 10:15:00AM +0000, Alice Ryhl wrote:
> +    /// Map a physically contiguous range of pages of the same size.
> +    ///
> +    /// # Safety
> +    ///
> +    /// * This page table must not contain any mapping that overlaps with the mapping created by
> +    ///   this call.
> +    /// * If this page table is live, then the caller must ensure that it's okay to access the
> +    ///   physical address being mapped for the duration in which it is mapped.

All the iommu page table code runs with a caller provided locking
regime.

The caller must effectively hold a range lock over the IOVA it is
mapping/unmapping/iova_to_phys'ing and it is illegal to race those
three functions with overlapping IOVA.

For example the caller cannot map to IOVA A-B while unmapping C-B or
iova_to_physing(A).

This locking detail should be a safety statement.

> +// These bindings are currently designed for use by GPU drivers, which use this page table together
> +// with GPUVM. When using GPUVM, a single mapping operation may be translated into many operations

Now that we have the generic pt stuff I wonder if GPUVM should be
providing its own version of the page table implementation that
matches its semantics better.

> +// on the page table, and in that case you generally want to flush the TLB only once per GPUVM
> +// operation. Thus, do not use these callbacks as they would flush more often than needed.

This doesn't sound quite right to me, the flushing requirements are a
consequence of what flushing HW is available in the xTLB that is
caching this. The flushes generated by the common arm code match the
ARM64 architecture semantics. If the GPU has different semantics then
it can do something else, but one must be careful not to match a GPU
that is expecting ARM semantics with "do not use these callbacks"

IOW it doesn't seem right that common code would be making decisions
like this, the nature and requirements of the flushing are entirely up
to the driver binding to HW.

Jason