On Thu, Sep 11, 2025 at 10:08:55PM +0800, Qinxin Xia wrote:

On 2025/9/10 22:15:47, Jason Gunthorpe [off-list ref] wrote:

quoted

On Wed, Sep 10, 2025 at 11:20:08AM +0800, Qinxin Xia wrote:

quoted

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