Re: [PATCH v3] io: add io_pgtable abstraction

[Jason Gunthorpe]

On Fri, Dec 12, 2025 at 09:44:27AM +0100, Boris Brezillon wrote:

> > > +// 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.
> 
> Not too sure what you mean here. Are you saying that we should fork
> io-pgtable-arm.c (or rather a subset of it), and have it all
> implemented in panthor?

Not quite, probably next yearish some of iommu is going to stop using
io-pgtable-arm.c, and switch to the new stuff.

The new stuff has alot less duplication if you want to make your own
special stuff like this:

> against it. Now, I see good reasons to do that, like the fact we
> would be able to add features like batched repeat mapping updates
> (mapping the same page over a wide virtual range without having to
> duplicate the intermediate page table levels that are exactly the
> same), 

That's certainly a unique requirement and it could be implemented with
a gpusvm specific set of operations.

> or the ability to extend the mapping arguments with
> shareability/coherency info (that we can do by adding IOMMU_xx flags
> too). But there's also downsides to it, like the fact we wouldn't
> benefit from bugfixes materializing in io-pgtable-arm.c, if any.

The new stuff is significantly modular already so this risk is a lot
lower, and we could further modularize things that are actually
duplicated.

But doing something like repeating page table levels will require some
fairly different unmaping logic already...

You also had the special allocator asks (and presumably optimizations
are possible there too) and probably optimizations like taking page
lists directly out of GPU structures instead of multiple calls and so
on.

When 6.19 comes out go look in drivers/iommo/generic_pt and read the
documentation pages that will generate under the kernel docs site.

Then you can think about what is ideal for GPU and consider what the
work would be like. My uneducated feeling is with gpuvm trying to be
common code it could also have gpuvm provide shared common code that
directly builds page tables in CPU memory using the above framework.

> > 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.
> 
> We're not saying this will work for everyone, but rather, this is a
> default implementation that does nothing, and if you need to do
> something, override it with your own. I guess if that's really
> problematic, we can force the user to provide one and keep the NOP
> implementation on Tyr's side.

In my view there is no possible correct way to use this page table
code with HW unless you also provide flushing ops. I can't remark what
is more rusty to do but having a default full of NOPS should at least
come with a comment explaining that the driver still need to provide
something.

Jason