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

[Robin Murphy]

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

Conversely though, I really wouldn't want to have to maintain arm-smmu 
supporting two completely different pagetable APIs simultaneously either :/

Thanks,
Robin.