[PATCH v5 0/8] iommu/riscv: Add HPM support for RISC-V IOMMU
Lv Zheng
lv.zheng at linux.spacemit.com
Sat Feb 28 19:36:46 PST 2026
On 3/1/2026 9:58 AM, Zong Li wrote:
> On Sat, Feb 28, 2026 at 10:44 PM Lv Zheng <lv.zheng at linux.spacemit.com> wrote:
>>
>> Includes HPM support for RISC-V IOMMU. The HPM hardware mechanism can be
>> found in the recent announced SpacemiT SoCs (K3, V100), where T100
>> (SpacemiT distributed IOMMU) is shipped.
>>
>> The RISC-V IOMMU specification defines optional HPM registers (IOHPMEVT,
>> IOHPMCTR, etc.) for performance monitoring of transactions through the
>> IOMMU. SpacemiT T100 implements this specification with a distributed
>> architecture: the main IOMMU (IOATS) is complemented by up to 64 IOATC
>> units that cache IOTLBs adjacent to DMA masters. Each IOATC has its own
>> HPM counters and PMIV interrupt.
>>
>> This series introduces an auxiliary bus framework to allow the HPM
>> functionality to be implemented as a separate perf driver, keeping the
>> IOMMU core focused on translation. Vendor-specific extensions (SpacemiT
>> T100) are layered on top of the generic HPM infrastructure.
>>
>> History:
>> The first revision of this series is posted without the awareness of
>> other on-going discussions. There are other postings providing same
>> functionality as [PATCH 2-3] in this thread:
>> 1. Zong Li:
>> https://lore.kernel.org/all/20250115030306.29735-1-zong.li@sifive.com/
>> We aligned with Zong in the community here:
>> https://lore.kernel.org/all/CANXhq0q8N5eHx9ytabZR97Y7AULKwgS2-uEGhcaOOGp9mvbtRQ@mail.gmail.com/
>> >> Perhaps I can first post my next revision to the mailing list (hope
>> >> it won't waste the community resource), so that you could have a
>> >> chance to review it and see whether that version is architecturally
>> >> closer to what the community is looking for, while also addressing
>> >> your issue. If you also feel that my next revision meets your needs,
>> >> perhaps you could append your additional implementations on top of
>> >> it.
>> >> Of course, if the community would prefer to go your version, I'm
>> >> perfectly fine with that as well.
>> His newest version can be found here:
>> https://lore.kernel.org/all/20260208063848.3547817-1-zong.li@sifive.com/
>
> I don’t think this v5 series is appropriate. In the beginning, you
> posted a similar implementation without sufficient discussion, but it
> might be ok because as you mentioned, you did so because you were not
> aware at the time. However, in this v5 series, you have again included
> our implementation concept without prior discussion or agreement
> (i.e., separates the IOMMU PMU driver into drivers/perf/ through the
> auxiliary framework). This may not fully align with the long-standing
> open-source collaboration model in the Linux community, In addition,
> our v2 series is still waiting for feedback and responses from the
> community. I believe it may not be appropriate to directly take our
> implementation and include it in your series.
> https://lists.infradead.org/pipermail/linux-riscv/2026-February/085349.html
I just followed the following comment and got the original Will's
suggestion:
https://lore.kernel.org/all/1e2b448f-3a2a-4b1f-872d-a34f7bd53696@bosc.ac.cn/
It looks to me like a community idea.
And we need a framework to dynamically "enumerate" devices rather than a
simple modulized approach.
> If you would like to build on top of our implementation and add your
> own changes, I think a better approach would be to first communicate
> with us, and then at least cherry-pick our implementation as the
> initial patches (i.e., patch 1 and patch 2). After that, you could
> place your own changes starting from the third patch.
Let's just focus on the technical discussion and let the community do
the final decission.
Did you see any problem in the Cced patches? We can change that Cc to
any other SOB keywords if you wish to.
Best regards
Lv
>
>
>> 2. Yaxing Guo:
>> https://lore.kernel.org/all/20250915020911.1313-1-guoyaxing@bosc.ac.cn/
>> Yaxing and Zong aligned each other in the community here:
>> https://lore.kernel.org/linux-iommu/2ce9d8be-10b3-48dd-b99e-7358347fc171@bosc.ac.cn/
>> >> Hi Zong Li,
>> >> Of course yes, absolutely - I wasn't aware of your earlier
>> >> submission. Please go ahead with your version.
>> This is the newest revision of this patchset, and [PATCH 2-3] is the one
>> that is competing with other contributions.
>>
>> Revisions:
>> v1
>> Initial release.
>> v2 (sent as v1.1)
>> Split and cleanup DT-bindings.
>> v3
>> 1. Refactor using vendor specific compatible.
>> 2. Implement vendor events with a userspace identifier.
>> v4
>> 1. Drop ICVEC check which is not that usful as WSI device tree can use
>> only 1 vector for IOATS CIV/FIV/PIV/PMIV.
>> 2. Solve DT binding check of "interrupts/maxItems" attribute.
>> 3. Address Robin's comments for an old revision sent by "Zong Li".
>> 4. Limit IOATC enumeration by referencing spacemit,riscv-iommu.
>> v5:
>> 1. Use correct style SoC/IP specific compatible.
>> 2. Address all on-going comments in other threads.
>> 3. Split compatible into SoC specific and IP specific.
>> 4. Switch to use auxiliary device framework.
>>
>> The tested result can be found as follows:
>>
>> root at sdfirm:# perf stat --timeout 5000 -a -e spacemit_ioats_hpm_0/dd_walk,config1=0x20c0010000000000/ dmatest; sleep 1
>> [ 453.426404] dmatest: Started 1 threads using dma0chan0
>> [ 453.437152] dmatest: dma0chan0-copy0: summary 1 tests, 0 failures 212.04 iops 212 KB/s (0)
>>
>> Performance counter stats for 'system wide':
>>
>> 3 spacemit_ioats_hpm_0/dd_walk,config1=0x20c0010000000000/
>>
>> 0.190412000 seconds time elapsed
>>
>> root at sdfirm:~# perf stat --timeout 5000 -a -e spacemit_ioatc_hpm_1/tlb_mis,config1=0x20c0010000000000/ dmatest; sleep 1
>> [ 117.599620] dmatest: Started 1 threads using dma0chan0
>> [ 117.610698] dmatest: dma0chan0-copy0: summary 1 tests, 0 failures 186.07 iops 186 KB/s (0)
>>
>> Performance counter stats for 'system wide':
>>
>> 7 spacemit_ioatc_hpm_1/tlb_mis,config1=0x20c0010000000000/
>>
>> 0.196982000 seconds time elapsed
>>
>> Jingyu Li (3):
>> iommu/riscv: Enable IOMMU DMA mapping support
>> iommu/riscv: Add auxiliary bus framework and HPM device support
>> iommu/riscv: Add HPM support for performance monitoring
>>
>> Lv Zheng (5):
>> dt-bindings: iommu: Add spacemit/t100 features
>> spacemit/t100: Add global filter awareness for RISC-V IOMMU HPM
>> iommu/riscv: Add SpacemiT T100 IOATC HPM support
>> iommu/riscv: Add vendor event support for RISC-V IOMMU HPM
>> perf vendor events riscv: Add SpacemiT T100 HPM event aliases
>>
>> .../bindings/iommu/riscv,iommu.yaml | 58 +-
>> MAINTAINERS | 5 +
>> drivers/iommu/Kconfig | 2 +-
>> drivers/iommu/riscv/Kconfig | 1 +
>> drivers/iommu/riscv/iommu-bits.h | 12 +
>> drivers/iommu/riscv/iommu-pci.c | 8 +-
>> drivers/iommu/riscv/iommu-platform.c | 7 +-
>> drivers/iommu/riscv/iommu.c | 306 +++++
>> drivers/iommu/riscv/iommu.h | 25 +-
>> drivers/perf/Kconfig | 9 +
>> drivers/perf/Makefile | 1 +
>> drivers/perf/riscv_iommu_hpm.c | 1012 +++++++++++++++++
>> include/linux/riscv_iommu.h | 83 ++
>> .../arch/riscv/spacemit/iommu/sys/ioatc.json | 30 +
>> .../arch/riscv/spacemit/iommu/sys/ioats.json | 163 +++
>> 15 files changed, 1715 insertions(+), 7 deletions(-)
>> create mode 100644 drivers/perf/riscv_iommu_hpm.c
>> create mode 100644 include/linux/riscv_iommu.h
>> create mode 100644 tools/perf/pmu-events/arch/riscv/spacemit/iommu/sys/ioatc.json
>> create mode 100644 tools/perf/pmu-events/arch/riscv/spacemit/iommu/sys/ioats.json
>>
>> --
>> 2.43.0
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
More information about the linux-riscv
mailing list