Re: [PATCH v2 0/2] iommu: Allow passing custom allocators to pgtable drivers

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Nov 14, 2023 at 12:27:48PM -0400, Jason Gunthorpe wrote:

> > Anyway, given you already thought it through, can I ask you to provide
> > a preliminary implementation for this IOVA range mechanism so I can
> > play with it and adjust panthor accordingly. And if you don't have the
> > time, can you at least give me extra details about the implementation
> > you had in mind, so I don't have to guess and come back with something
> > that's not matching what you had in mind.
> 
> Oh, I don't know if I can manage patches in any reasonable time frame,
> though I think it is pretty straightforward really:
> 
>  - Patch to introduce some 'struct iopte_page' (see struct slab)
>  - Adjust io pagetable implementations to consume it
>  - Do RCU freeing of iopte_page
>  - Add a reserve/unreserve io page table ops
>  - Implement reserve/unresereve in arm by manipulating a new refcount
>    in iopte_page. Rely on RCU to protect the derefs
>  - Modify iommufd to call reserve/unreserve around areas attachment
>    to have an intree user.
> 
> Some of this is a bit interesting, like reserving probably will
> ideally want to invoke the batch allocator for efficiency which means
> computing the number of radix levels required to fully populate the
> current empty level - that should be general code somehow

At LPC there was quite a lot if interest in improving the io page
table stuff to work better. Based on that I'm even more against adding
an external allocator at this time. :\

I may try to write a sketch of something but I'm not sure when..

Jason