Hi Chuanhua,

Even if we ignore the RISC-V CSR range violation in allowing writes to HPMCOUNTER CSR from S-mode, still the “bypass-sbi” DT property is not an acceptable solution.

The “bypass-sbi” DT property will make Linux PMU driver do things differently for HS-mode and VS-mode. Further, it is totally unclear how “bypass-sbi” DT property should be used in nested virtualization because here we will have virtual VS-mode (Guest OS) running on virtual HS-mode (Guest Hypervisor) which in-turn runs on real HS-mode (Host Hypervisor). For a clean nested virtualization, both HS-mode (Hypervisor) and VS-mode (Guest) should write HPMCOUNTER CSR in the same way.

Further, the “bypass-sbi” DT property cannot be used for existing RISC-V platforms (SiFive Unleashed, Microchip PolarFire, etc) because existing HARDWARE don’t have proposed “write-enable” bit in HPMEVENT CSR. This means Linux PMU driver will again have to do things differently for existing RISC-V platforms.

I think if we want to allow S-mode direct writes to HPMCOUNTER CSRs along with clean nested virtualization then it is better to add separate HS-mode and VS-mode CSRs. Although, I am still wondering why we should allow S-mode direct writes to HPMCOUNTER CSRs considering Linux perf tools are only used for debugging and analysis.

Regards,

Anup