Re: [PATCH 0/7] Use the generic iommu page table for SMMUv3

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Jul 24, 2026 at 07:36:16PM +0000, Mostafa Saleh wrote:
> On Mon, Jul 06, 2026 at 01:29:06PM -0300, Jason Gunthorpe wrote:
> > [ This is the last patch to move SMMUv3 over to the generic page
> >   table:
> > 1) Organize the SMMUv3 invalidation flow so iommupt can use it
> >   ..
> > 2) Use the generic iommu page table for SMMUv3
> > 
> > It depends on #1
> > 
> > The whole branch is here:
> >    https://github.com/jgunthorpe/linux/commits/iommu_pt_arm64/
> > ]
> > 
> > Introduce the generic page table for what the ARM spec calls VMSAv8-64
> > (ie the long 64 bit PTE page table, io-pgtable-arm.c) and use it for
> > SMMUv3. ARM is by far the most complex page table of all the ones
> > implemented, it has the most runtime behavior variations and a lot of
> > features.
> > 
> > Like the othe architectures, the page table itself is supported by a kunit
> > compare test that runs operations through both io-pgtable-arm.c and the
> > new code then checks for identical PTEs. This is on the github link above
> > but I don't intend to merge it.
> > 
> > The existing kunit tests for iommupt will automatically cover the new
> > format as well.
> > 
> > This is the final series migrating the SMMUv3 driver over to use the new
> > functions and remove io-pgtable-arm.c usage. In principle the other iommu
> > drivers that use io-pgtable-arm could be converted someday as well.
> > 
> > Robin once mentioned there were errata about contiguous bits, I only found
> > 3673557 and it is mitigated in this design by always using RIL. I'm
> > assuming that RIL is always available in SMMUs that are effected by
> > 3673557? I have a patch add a FEAT if for contiguous bits if that is
> > required.
> > 
> > Jason Gunthorpe (7):
> >   iommupt: Remove the sanity check for pt_num_items_lg2() at the top
> >     level
> >   iommupt/kunit: Skip test configs without supported features
> >   iommupt: Add the 64 bit ARMv8 page table format
> >   iommu/arm-smmu-v3: Remove io-pgtable-arm from sva.c
> >   iommu/arm-smmu-v3: Move the DMA API comment to flush_iotlb_all
> >   iommu/arm-smmu-v3: Use the generic iommu page table
> >   iommu: Remove pgsize from iommu_iotlb_gather
> 
> I went through the series, it seems the arm work plug in nicely with
> the iommupt stuff, I left some comments around, but I feel that
> patches 1,2 and 5 can be sent separately.

Yeah, I can probably do that

> And patch 8 it too large to review, it would be better to split into
> 3-6 patches, I was thinking: base support, dirty tracking, contig bit
> aarch32 and kunit.

I'd rather not have patches creating unique things that don't need to
exist eg a version without contig or something like that. It is too
much busy work to go and test all of that. Clean splits like around
the kunit and dirty tracking are OK, but I didn't feel it reduces the
reviewer burden.

But yeah, arm is uniquely large because of it's complexity.

Thanks,
Jason