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

[Mostafa Saleh]

On Wed, Jul 15, 2026 at 09:28:30AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 15, 2026 at 01:03:22PM +0100, Will Deacon wrote:
> 
> > 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?
> 
> I briefly looked at Mali a while back and it didn't seem so bad, but
> that was for a GPU driver not the iommu so a bit different
> issue. Exactly what the GPU drivers should be doing is less clear to
> me, they don't really fit well with the iommu focused interface (eg
> the memory preload issues/etc).
> 
> >   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).
> 
> Yeah, I'm not sure here, it isn't great that is adding another user
> and open coding some of the logic (eg smmu_pgsize_idmap). It would be
> much better if it could just use all the existing flow more directly
> somehow.

I was under the impression that io-pgtable-arm will remain the same,
but if it is going to be removed (or at least the LPAE format) I need
to figure out an alternative for pKVM:
- Compile iommupt for the hypervisor (similar to what we do with
  io-pgtable-arm in the SMMUv3 pKVM series which compiles in both)
  I am not sure how easy is that for iommupt, I have the SMMUv3
  iommupt series on my review list, I will check that.
- Support the hypervisor page table in the IOMMU, that requires some
  extra support changes, I recently posted BBM support, but there is
  more as avoiding lazy mapping when unmapping, TLB hooks...).
  There is another problem with that for android, as we still need
  stage-1 as some SMMUs only support single stage (used with pv)
- Write a small IO page table implementation just for the hypervisor,
  that's not ideal as it would benefit also from features as CONTPTE.

I will look more into this, solution 1) seems the best case if
practical, otherwise, 2) might be reasonable for upstream.

Thanks,
Mostafa

> 
> >   3. Non-coherent walkers, although I think this might actually be fine
> >      because x86 needs it anyway?
> 
> This is done already, the smmuv3 conversion I've posted supports it.
> 
> > So, for now, I wouldn't require new drivers to use iommupt but I'm
> 
> The recently posted broadcom driver used iommupt and I thought it
> turned out very clean, it actually seems like less work to do it this
> way than try to write your own page table like that rockchip driver
> did which required several review rounds.
> 
> Jason