Re: [PATCH v3] io: add io_pgtable abstraction

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 12 Dec 2025 05:21:11 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:

> 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.

Ah, nice! I will certainly have a look when it's out. Thanks for the
heads-up.

> 
> 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.

So, gpuvm is one level up (it doesn't deal at all with any HW
representation), but I guess we could provide helpers for UMA-GPUs,
where preparing the page table on the CPU is a thing, and it could be
that MSM would be interested in using those helpers too.

> 
> > > 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.

I'll let Alice decide, but I'm perfectly fine with both options
(NOP default with a disclaimer, or no default at all).

Thanks,

Boris