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

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

On 09/10/2026 11:09 am, Vijayanand Jitta wrote:
> 
> 
> On 9/25/2026 4:23 AM, Jason Gunthorpe wrote:
>> On Thu, Sep 24, 2026 at 11:49:50AM -0700, Daniel Mentz wrote:
>>> On Wed, Sep 23, 2026 at 5:15 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>>>
>>>> On Mon, Sep 21, 2026 at 04:44:07PM +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, set CONT on every descriptor in that group so the hardware can
>>>>> combine translations and improve TLB reach.
>>>>>
>>>>> Advertise the supported CONT group sizes in pgsize_bitmap. Callers select
>>>>> those sizes through the normal page-size selection path; io-pgtable-arm
>>>>> then installs the corresponding tagged descriptors directly. A partial
>>>>> unmap of a tagged CONT group is rejected before modifying any descriptor,
>>>>> so a rejected request cannot leave the group partly unmapped.
>>>>>
>>>>> The IO_PGTABLE_QUIRK_ARM_NO_CONT_HINT quirk allows SMMU drivers to disable
>>>>> CONT support for hardware with implementation-specific errata.
>>>>
>>>> smmuv3 has this errata, it must be disabled there too. I didn't notice
>>>> it in this patch?
>>>
>>> SMMU is an architecture specification. I am not aware of errors in
>>> this architecture specification that would preclude the usage of the
>>> contiguous bit. I understand that Arm MMU-700 has the following
>>> erratum
>>>
>>> 3777127 Under invalidation in TBU possible when using contiguous page
>>> table entries
>>
>> And a neoverse one too.
>>
>>> The recommended workaround is described as
>>>
>>> "Ensure that contiguous page tables are removed using a single range
>>> invalidation. Arm recommends using range invalidations to remove
>>> contiguous entries anyway for performance reasons."
>>>
>>> and I believe we are already doing this.
>>
>> No we aren't. Go read my fix on this:
>>
>> https://lore.kernel.org/linux-iommu/1-v7-e84261bbe7cd+2ea80b-smmu_tlbi_jgg@nvidia.com/
>>
>> I have another patch that fixes it for iommu domain mappings too.
>>
>> Jason
> 
> Sure , will disable it for smmuv3 for now.

I still can't see how that would be necessary. Sure SVA has to cope with 
invalidating any old arbitarily-sized range that could have been a mix 
of pages, blocks, cont, whatever - that's fair enough. But for 
io-pgtable through the IOMMU API, a partial unmap of anyhthing which 
could have been mapped as a cont range would already be invalid and 
should fail. Thus for any unmap which could validly include any cont 
ranges, iommu_pgsize() would have already picked a granularity that is 
some multiple of the largest cont range size being unmapped, so even if 
the total gathered size exceeds a single command, we still wouldn't 
split it _within_ any single one of those ranges, only at a boundary 
between two unrelated ones.

Thanks,
Robin.