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

[Vijayanand Jitta]

On 7/16/2026 5:29 PM, Robin Murphy wrote:
> On 15/07/2026 7:09 pm, Jason Gunthorpe wrote:
>> On Wed, Jul 15, 2026 at 06:45:09PM +0100, Robin Murphy wrote:
>>
>>>> AFAICR the biggest issue with arm-smmu was it using IO_PGTABLE_ARMV7S
>>>> as well. I think it would be fine to implement all the unique LPAE
>>>> features it needs in iommupt, I did most of them already.
>>>>
>>>> I do have an ARMV7S implementation for iommupt, but I did not solve
>>>> the sub page problem. So while it is functionally working it is not
>>>> usable since it wastes so much memory. That's a tricky problem to
>>>> solve since the algorithms depend on the gather->freelist.
>>>>
>>>> I didn't spend any time trying to do anything about this as I was not
>>>> intending to touch arm-smmu
>>>
>>> Indeed between the irregular table sizes (before you even get to the
>>> Mediatek shenanigans...), and the awkward GFP_DMA limitations and/or reality
>>> that many of the systems using it really don't have memory to waste, I'd
>>> have considered v7s pretty much terminally incompatible with iommu_pages and
>>> the abstraction that iommupt is trying to be... :/
>>
>> At least Matthew has talked about having a sub page allocator with
>> meta data, maybe with the memdesc support someday. Even today we could
>> have iommu-pages allocate a companion struct pointed to from struct
>> page that was sized 4x so it could be used for the freelist.
>>
>> There are some other options for alterantive algorithms that could
>> work without requiring the free list. I had some thoughts about placing
>> the free list inside the data itself as a non-present entry.
>>
>> It is not insolvable, I'm just not sure it is worth doing vs leaving
>> arm-smmu to keep using iopgtable from ARMv7.
> 
> Yeah, if you did want to keep bashing at it, then ultimately there are at least a couple more short-descriptor inspired implementations in exynos and omap too, however at this point I don't see the cost:benefit ratio looking at all favourable...
> 
>> Otherwise to have arm-smmu use iommupt you'd end up with two
>> iommu_domains specialized to 32 and 64 bit page tables, with their own
>> ops and a shared invalidation like how the tlbi struct is providing
>> for smmuv3.
>>
>> It is not outrageously bad, but it certainly is a chunk of work.
>>
>> If the goal is arm-smmu support of CONT then maybe there is some merit
>> in doing iopgtable as a one off feature. But there have been many
>> attempts so far to add CONT and they all had troubles, I had the
>> impression is is not so easy..
> 
> I think now that partial unmaps are firmly ruled out and we already have the multi-page map/unmap design it should be pretty minor. I'm also more than happy to stop there, have dirty tracking, splitting/merging and all the fancy new IOMMUFD stuff require iommupt, and keep io-pgtable strictly for the GPUs and "media" IOMMUs that only need to keep providing map/unmap/iova_to_phys for iommu-dma or equivalent usage. By now I'd also say we can reasonably park arm-smmu in the latter category - while technically it could try to support stuff like nesting and vIOMMU (at least on MMU-500), the hardware is in embedded platforms which either don't care at all, or at worst where virtualisation is Xen's problem not ours. As far as I'm aware even the NXP Layerscape platforms are happy with the status quo of just basic VFIO type 1 for DPDK.
> 
> Thanks,
> Robin.


FYI, I've just posted v2 addressing the review comments from the
earlier round — it doesn't touch the io-pgtable/iommupt split discussed
above, just the CONT-hint quirk in the existing io-pgtable-arm code.

Thanks,
Vijay