Re: [PATCH 0/2] iommu: Add io_ptdump debug interface for iommu

[Jason Gunthorpe <jgg@ziepe.ca>]

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