[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1e2b448f-3a2a-4b1f-872d-a34f7bd53696@bosc.ac.cn>
Date: Mon, 9 Feb 2026 11:21:32 +0800
From: yaxing guo <guoyaxing@...c.ac.cn>
To: Lv Zheng <lv.zheng@...ux.spacemit.com>, Zong Li <zong.li@...ive.com>,
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, krzk@...nel.org, 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
Subject: Re: [PATCH v2 0/2] RISC-V IOMMU HPM support
在 2026/2/9 9:40, Lv Zheng 写道:
> 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@...ux.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.
>
>>
>> Yaxing has agreed to pause his series, as discussed here:
>> https://lore.kernel.org/linux-iommu/2ce9d8be-10b3-48dd-
>> b99e-7358347fc171@...c.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.
>
When I previously submitted my RISC-V IOMMU PMU series, Will(Will
Deacon<will@...nel.org>) suggested placing the RISC-V IOMMU PMU driver
under drivers/perf/, similar to the ARM implementation. He also
commented: "I'm sure Robin had fun dealing with shared MMIO regions
before" — referring to the discussion here:
https://patchwork.kernel.org/project/linux-riscv/patch/20250915020911.1313-1-guoyaxing@bosc.ac.cn/
> Cheers,
> Lv
>
Best regards,
Guo Yaxing
Powered by blists - more mailing lists