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

[Robin Murphy <robin.murphy@arm.com>]

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

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

Thanks,
Robin.