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

From: Will Deacon

Date: Wed Jul 15 2026 - 08:11:42 EST


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 <prakash.gupta@xxxxxxxxxxxxxxxx>
> > >>
> > >> 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.

Will