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

[Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>]

On 9/8/2026 10:17 PM, Jason Gunthorpe wrote:
> On Tue, Sep 08, 2026 at 09:36:35AM -0700, Daniel Mentz wrote:
>>>> That said, install_leaf() is shared by other callers that reach it through
>>>> ops->map_pages() directly, without going through iommu_pgsize(). panthor_vm_map_pages()
>>>> (drivers/gpu/drm/panthor/panthor_mmu.c) is one -- it allocates its io_pgtable_ops via
>>>> alloc_io_pgtable_ops(ARM_64_LPAE_S1, ...), same as any other LPAE consumer, but does its
>>>> own chunking with a local get_pgsize() that only ever returns SZ_4K or SZ_2M, with no
>>>> notion of the 64K/32M CONT boundaries. That can hand install_leaf() exactly the mixed
>>>> iova=paddr=0x1000, pgcount=34 shape in a single call (panfrost's map loop uses the same
>>>> get_pgsize() and hits the same case). So the prefix/aligned-group/suffix handling in
>>>> install_leaf() is still needed for that path.
>>>
>>> Maybe other people can chime in here, but I feel, from an API
>>> perspective, we should have only one way to make of use iopgtable. I
>>> think we should just mandate that users honor the updated value for
>>> pgtbl_cfg.pgsize_bitmap (and pgtbl_cfg.ias) after the
>>> alloc_io_pgtable_ops() call and then choose page sizes appropriately.
>>> Otherwise, we end up with two pieces of code in the kernel solving the
>>> same problem. panthor_mmu won't be able to take advantage of the
>>> contiguous bit until it gets updated accordingly, and that's ok.
>>
>> On this note, I want to point out that I tried something similar in
>> 2025 (see https://lore.kernel.org/linux-iommu/20250430231924.1481493-1-danielmentz@google.com/).
>> The feedback I received from Jason at the time was:
>>
>> "Wouldn't it be better to use the pgsize_bitmap and rely on the core
>> code to indicate that a contiguous page size is being used, so it can
>> trivially set the PTE bit without doing all this extra work?"
> 
> Still think this is right, Panthor is not using it well if it doesn't
> jump through all the hoops. Probably there should be an general entry
> point for map/unmap that does the right stuff for the DRM drivers to
> call.
> 
> Jason

Thanks Daniel and Jason for the detailed feedback.

I agree that CONT-sized mappings should be selected by the caller using the
effective pgtbl_cfg.pgsize_bitmap, rather than having io-pgtable-arm perform a
second round of prefix/group/suffix splitting.

Based on this, I will remove that logic from arm_lpae_install_leaf(). The only
effect is that direct io_pgtable_ops users such as Panthor and Panfrost will not
benefit from the contiguous hint.

Updating Panthor/Panfrost and adding a common map/unmap entry point for direct
io_pgtable_ops users are separate API changes, I think this can be taken up
as a separate follow-up series.

Thanks,
Vijay