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

[Will Deacon <will@kernel.org>]

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@oss.qualcomm.com>
> > >>
> > >> 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