Re: [PATCH] iommu/io-pgtable-arm: Add support for contiguous hint bit

On Wed, Jul 15, 2026 at 01:14:18PM +0100, Robin Murphy wrote:
> On 15/07/2026 1:03 pm, Will Deacon wrote:
> > On Wed, Jul 15, 2026 at 08:39:13AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jul 15, 2026 at 11:25:42AM +0530, Vijayanand Jitta wrote:
> > > > On 7/3/2026 9:42 PM, Jason Gunthorpe wrote:
> > > > > On Thu, Jun 18, 2026 at 02:32:09PM +0530, Vijayanand Jitta wrote:
> > > > > > From: Prakash Gupta <[email protected]>
> > > > > > 
> > > > > > Add support for the contiguous hint (CONT) bit in ARM LPAE page tables.
> > > > > > When a set of consecutive PTEs map a naturally-aligned contiguous block
> > > > > > of memory, the CONT bit can be set on all entries in the group to allow
> > > > > > the hardware to combine them into a single TLB entry, improving TLB
> > > > > > utilization.
> > > > > > 
> > > > > > The contiguous hint sizes per granule are:
> > > > > > 
> > > > > >    Page Size | CONT PTE |  PMD  | CONT PMD
> > > > > >    ----------+----------+-------+---------
> > > > > >        4K    |   64K    |   2M  |   32M
> > > > > >       16K    |    2M    |  32M  |    1G
> > > > > >       64K    |    2M    | 512M  |   16G
> > > > > 
> > > > > My series to convert smmuv3 to the iommupt takes care of this and
> > > > > supports all the orders too. I'd rather we move forward with that then
> > > > > try to patch up this.
> > > > 
> > > > Thanks for details, I have gone through your series. As this patch
> > > > targets io-pgtable-arm.c directly and would benefit all its users (SMMUv2,
> > > > Apple DART, etc.), not just SMMUv3. I think there will still be value in
> > > > this patch for the other users.
> > > 
> > > If other users care they should also be converted to iommupt, there
> > > are many benefits to this besides just cont support.
> > 
> > I really have no interest in maintaining two copies of the page-table
> > code, so I agree that we should convert users of the architectural (long
> > descriptor) page-table format over to iommupt with a view to removing
> > the io-pgtable implementation eventually. If you want two parallel
> > implementations, then one should really be in rust :)
> > 
> >  From what I can tell, the fiddly parts for iommupt will be:
> > 
> >    1. Hardware bugs / quirks. Some of the simpler ones could probably be
> >       handled but for the more invasive stuff like the Mali format
> >       format, io-pgtable will probably need to hang around. Perhaps
> >       it becomes io-pgtable-mali.c?
> > 
> >    2. The pKVM work from Mostafa. We'll probably end up with something
> >       separate at EL2 for this (ideally, just reusing the CPU page-table
> >       code when it learns about BBML3).
> > 
> >    3. Non-coherent walkers, although I think this might actually be fine
> >       because x86 needs it anyway?
> > 
> > So, for now, I wouldn't require new drivers to use iommupt but I'm not
> > particularly keen about teaching io-pgtable new architectural tricks
> > either.
> 
> Conversely though, I really wouldn't want to have to maintain arm-smmu
> supporting two completely different pagetable APIs simultaneously either :/

Yeah, we'll have to see how it pans out. I suppose the first step is for
somebody to go through Jason's iommupt series for SMMUv3 and get that
driver converted. Once we've got that working, we should have a better
idea about what to do with arm-smmu.

If we can't get to a point where drivers are no longer using the long
descriptor io-pgtable implementation, then we'll obviously not get rid
of it, but I think it will become "fixes only" or something like that.

Will