This patch supports the iopgtable_dump function (similar to kernel_page_dump).
The IOMMU page table dump debugging function is added to the framework layer.
Different architectures only need to provide the implemented dump ops.
It also provides the implementation of ARM SMMUv3 and io-pgtable-arm.

Qinxin Xia (2):
  iommu/debug: Add IOMMU page table dump debug facility
  iommu/io-pgtable: Add ARM SMMUv3 page table dump support

 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  13 ++
 drivers/iommu/dma-iommu.c                   |  15 ++
 drivers/iommu/dma-iommu.h                   |   4 +
 drivers/iommu/io-pgtable-arm.c              | 169 +++++++++++++++++++
 drivers/iommu/iommu.c                       | 175 ++++++++++++++++++++
 include/linux/io-pgtable.h                  |   4 +
 include/linux/io_ptdump.h                   |  16 ++
 include/linux/iommu.h                       |  10 +-
 mm/Kconfig.debug                            |  19 +++
 mm/Makefile                                 |   2 +
 mm/io_ptdump.c                              |  24 +++
 mm/io_ptdump_debugfs.c                      |  17 ++
 12 files changed, 467 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/io_ptdump.h
 create mode 100644 mm/io_ptdump.c
 create mode 100644 mm/io_ptdump_debugfs.c

-- 
2.33.0

On Thu, Aug 14, 2025 at 05:30:03PM +0800, Qinxin Xia wrote:
> This patch supports the iopgtable_dump function (similar to kernel_page_dump).
> The IOMMU page table dump debugging function is added to the framework layer.
> Different architectures only need to provide the implemented dump ops.
> It also provides the implementation of ARM SMMUv3 and io-pgtable-arm.
> 
> Qinxin Xia (2):
>   iommu/debug: Add IOMMU page table dump debug facility
>   iommu/io-pgtable: Add ARM SMMUv3 page table dump support

I'd prefer we do this on top of iommu pt please, I don't want to
further deeping the hole of changing all the page table code in all
drivers for debugfs.

Jason

On 2025/9/3 00:10:28, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Aug 14, 2025 at 05:30:03PM +0800, Qinxin Xia wrote:
>> This patch supports the iopgtable_dump function (similar to kernel_page_dump).
>> The IOMMU page table dump debugging function is added to the framework layer.
>> Different architectures only need to provide the implemented dump ops.
>> It also provides the implementation of ARM SMMUv3 and io-pgtable-arm.
>>
>> Qinxin Xia (2):
>>    iommu/debug: Add IOMMU page table dump debug facility
>>    iommu/io-pgtable: Add ARM SMMUv3 page table dump support
> 
> I'd prefer we do this on top of iommu pt please, I don't want to
> further deeping the hole of changing all the page table code in all
> drivers for debugfs.
> 
> Jason
Ok, I see, my colleague Wang Zhou also released a version of io_ptdump
a long time ago, which is implemented in smmu debugfs. Will recommends 
that io_ptdump be implemented in a way similar to CPU page table dump. 
Using debugfs to expose the data and using format-specific callbacks to 
implement specific data dumps, I'll talk to him about this as well.

On Wed, Sep 10, 2025 at 11:20:08AM +0800, Qinxin Xia wrote:
> Ok, I see, my colleague Wang Zhou also released a version of io_ptdump
> a long time ago, which is implemented in smmu debugfs. Will recommends that
> io_ptdump be implemented in a way similar to CPU page table dump. Using
> debugfs to expose the data and using format-specific callbacks to implement
> specific data dumps, I'll talk to him about this as well.

I feel we should have a iommu subsystem debugfs and per-iommu_domain
directories to dump the page tables.

The smmu debugfs can report what iommu_domains each STE/CD is
referencing.

This also needs RCU freeing of page table levels as a locking
strategy.

Jason

On 2025/9/10 22:15:47, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Wed, Sep 10, 2025 at 11:20:08AM +0800, Qinxin Xia wrote:
>> Ok, I see, my colleague Wang Zhou also released a version of io_ptdump
>> a long time ago, which is implemented in smmu debugfs. Will recommends that
>> io_ptdump be implemented in a way similar to CPU page table dump. Using
>> debugfs to expose the data and using format-specific callbacks to implement
>> specific data dumps, I'll talk to him about this as well.
> 
> I feel we should have a iommu subsystem debugfs and per-iommu_domain
> directories to dump the page tables.
> 
> The smmu debugfs can report what iommu_domains each STE/CD is
> referencing.
> 
> This also needs RCU freeing of page table levels as a locking
> strategy.
> 
> Jason
> 

Thanks, I'll add RCU in the next version, but there's some confusion, Do 
you mean to create a directory for each domain? like：

/sys/kernel/debug/io_page_tables/domain_xxxx (xxxx=domain addr)

tree domain_xxxx like:
domain_xxxx
└── group x
│ └── device
└── io_ptdump

And the current design is such:

User Space Interface
└── DebugFS file: /sys/kernel/debug/io_page_tables
└── Operation: Reading this file triggers the entire debug information 
collection process

Kernel Space Components
├── Configuration option (CONFIG_IO_PTDUMP_DEBUGFS)
├── Initialization module (mm/io_ptdump.c)
│ └── device_initcall(io_ptdump_init)
│ └── io_ptdump_debugfs_register("io_page_tables")
├── DebugFS backend (mm/io_ptdump_debugfs.c)
│ └── DEFINE_SHOW_ATTRIBUTE(io_ptdump)
│ └── .show = io_ptdump_show
│ └── iommu_group_and_iova_dump(m)
└── IOMMU core extension (drivers/iommu/iommu.c)
└── iommu_group_and_iova_dump()
├── Traverse all IOMMU groups (via iommu_group_kset)
├── Filter groups with default domain using DMA_IOVA cookie
├── Build domain-group hierarchy
│ ├── domain_list: list head
│ ├── dump_domain: domain entry
│ │ ├── domain: pointer to iommu_domain
│ │ └── groups: list head of groups
│ └── dump_group: group entry
│ └── group: pointer to iommu_group
├── Output domain information
├── Output group and device information
└── Call iommu_iova_info_dump() to output IOVA mappings
└── Traverse IOVA red-black tree
└── Call domain->ops->dump_iova_prot() to get protection information
└── ARM SMMUv3 implementation (drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c)
└── arm_smmu_dump_iova_prot()
└── Call io_pgtable_ops->dump_iova_prot()
└── ARM LPAE implementation (drivers/iommu/io-pgtable-arm.c)
└── arm_lpae_dump_iova_prot()
├── Use __arm_lpae_iopte_walk() to traverse page tables
├── Obtain page table entry and level information
├── Format and output mapping range and information
└── Call dump_prot() to output protection flags
└── Use prot_bits array to parse permission bits

Do you mean that the interface in io-pgtable-arm.c is directly invoked 
during the process of obtaining page table information without passing 
through arm-smmu-v3.c?

I'll add STE and CD dumps to the next release. Any other suggestions?

On Thu, Sep 11, 2025 at 10:08:55PM +0800, Qinxin Xia wrote:
> 
> 
> On 2025/9/10 22:15:47, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Wed, Sep 10, 2025 at 11:20:08AM +0800, Qinxin Xia wrote:
> > > Ok, I see, my colleague Wang Zhou also released a version of io_ptdump
> > > a long time ago, which is implemented in smmu debugfs. Will recommends that
> > > io_ptdump be implemented in a way similar to CPU page table dump. Using
> > > debugfs to expose the data and using format-specific callbacks to implement
> > > specific data dumps, I'll talk to him about this as well.
> > 
> > I feel we should have a iommu subsystem debugfs and per-iommu_domain
> > directories to dump the page tables.
> > 
> > The smmu debugfs can report what iommu_domains each STE/CD is
> > referencing.
> > 
> > This also needs RCU freeing of page table levels as a locking
> > strategy.
> 
> Thanks, I'll add RCU in the next version, but there's some
> confusion,

Please don't, RCU is quite complicated, I don't really want to see
attempts to retrofit it into the existing page table code. This is why
I've said debugging like this needs to go along with the new iommu pt
work to consolidate the page table code.

> Do you
> mean to create a directory for each domain? like：
> 
> /sys/kernel/debug/io_page_tables/domain_xxxx (xxxx=domain addr)

Something like this could be a reasonable option.

> tree domain_xxxx like:
> domain_xxxx
> └── group x
> │ └── device

Though I would probably not include this information..

> └── DebugFS file: /sys/kernel/debug/io_page_tables
> └── Operation: Reading this file triggers the entire debug information
> collection process

I don't think we want to dump every page table in the system in one
file.

> Do you mean that the interface in io-pgtable-arm.c is directly invoked
> during the process of obtaining page table information without passing
> through arm-smmu-v3.c?

Yes, this is what iommu pt brings.

Jason