Message-ID: <CANXhq0qmc+vo6uX3ySqqQOPTHxKHJB8t1XC6JuxWs3K5_qoTRg@mail.gmail.com>
Date: Mon, 9 Feb 2026 11:19:48 +0800
From: Zong Li <zong.li@...ive.com>
To: Lv Zheng <lv.zheng@...ux.spacemit.com>
Cc: tjeznach@...osinc.com, joro@...tes.org, will@...nel.org, 
	robin.murphy@....com, robh@...nel.org, pjw@...nel.org, palmer@...belt.com, 
	aou@...s.berkeley.edu, alex@...ti.fr, mark.rutland@....com, 
	conor+dt@...nel.org, guoyaxing@...c.ac.cn, luxu.kernel@...edance.com, 
	andrew.jones@....qualcomm.com, linux-kernel@...r.kernel.org, 
	iommu@...ts.linux.dev, linux-riscv@...ts.infradead.org, 
	linux-perf-users@...r.kernel.org, Jingyu Li <joey.li@...cemit.com>
Subject: Re: [PATCH v2 0/2] RISC-V IOMMU HPM support

On Mon, Feb 9, 2026 at 9:41 AM Lv Zheng <lv.zheng@...ux.spacemit.com> wrote:
>
> On 2/8/2026 2:38 PM, Zong Li wrote:
> > This series implements support for the RISC-V IOMMU hardware performance
> > monitor.
> >
> > The RISC-V IOMMU PMU driver is implemented as an auxiliary device driver
> > created by the parent RISC-V IOMMU driver. The child driver can obtain
> > resources and information from the parent device, such as the MMIO base
> > address and IRQ number.
> >
> > Custom event support is not included in this series and will be submitted
> > as a separate series. The idea is that custom events will be defined
> > through the driver data of the auxiliary driver. When the parent IOMMU
> > driver creates the auxiliary device, it should pass a vendor-specific
> > name as the device name in order to match the corresponding auxiliary
> > device ID.
> >
> > After my initial RFC and the v1 patch series were posted, similar patch
> > series also appeared on the mailing list.
> >
> > One was from Yaxing Guo:
> > https://lore.kernel.org/all/20250915020911.1313-1-guoyaxing@bosc.ac.cn/
> >
> > and another from Lv Zheng:
> > https://lore.kernel.org/all/30C7AD351DB55276+a8b03dac-c5af-4034-8631-ac1c352a469f@linux.spacemit.com/
>
> Please do not forget to Cc:
> Jingyu Li <joey.li@...cemit.com>
> I only provided T100 specific support in the posted series, and the
> new approach of the HPM driver in the same series is composed by her.

Sorry for missing Jingyu. I have looped her in this thread.

>
> >
> > Yaxing has agreed to pause his series, as discussed here:
> > https://lore.kernel.org/linux-iommu/2ce9d8be-10b3-48dd-b99e-7358347fc171@bosc.ac.cn/
> >
> > The motivation for sending this v2 version is not only to address the
> > feedback and suggestions from the previous round, but also to introduce
> > a major structural change: the PMU driver has been moved under
> > drivers/perf/, which has been mentioned repeatedly by several people.
> > This results in a different driver structure compared to my earlier
> > version and the other two series, and I'd like to gather feedback and
> > suggestions from the community on this approach. If the community would
> > prefer to go with Lv Zheng’s version instead, I am perfectly fine with
> > that as well.
>
> We'd like to know if there's any comments related to putting IOMMU HPM
> driver into drivers/perf folder and want to know if this is necessary.
> We also hesitated if riscv iommu hpm should be put into drivers/perf,
> and according to the followings, we finally decided to keep it in
> drivers/iommu:
> 1. drivers/iommu has already a folder maintaining all IOMMU stuffs.
> 2. drivers/iommu has already defined HPM related registers.
> 3. Unlike PMCG of SMMU which is located in a separate namespace, RISC-V
>     IOMMU only defines 5 registers in the same address space as its
>     translation schemes.
> 4. For HPM schemes that is not a standalone device, Intel has put its
>     perf driver under drivers/iommu/intel/perfmon.c.
>

As you mentioned, it’s not strictly required to place the PMU driver
under the drivers/perf/ directory. I think it would also be ok for us
to place the PMU auxiliary driver under drivers/iommu/.

The key point here is to make the IOMMU PMU driver an auxiliary device
driver. Our intention is for the IOMMU PMU driver to behave more like
an independent platform driver, where vendor-specific or
hardware-specific information can be provided through driver data.
Custom events are one example of this. Similarly, if future versions
of the RISC-V IOMMU introduce new hardware features that need to be
distinguished by the driver, we should be able to handle them through
these existing interfaces.

Overall, you might consider this approach as using an auxiliary driver
to prepare for vendor-specific functionality and to allow more
flexibility going forward. If you also agree that this is a reasonable
approach, it seems to me that it might be good for you to add your
T100 support on top of the mechanism provided by this series, and then
append your patch after it.

> Cheers,
> Lv
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists