[PATCH v8 12/22] RISC-V: perf: Modify the counter discovery mechanism

Charlie Jenkins thecharlesjenkins at gmail.com
Mon Aug 10 20:50:31 PDT 2026


On Fri, Aug 07, 2026 at 01:08:31AM -0700, Atish Patra wrote:
> 
> On 7/20/26 12:21 AM, Charlie Jenkins wrote:
> > On Wed, 01 Jul 2026 01:47:00 -0700, Atish Patra <atish.patra at linux.dev> wrote:
> > > diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> > > index 74d934238821..c20f1e33c65d 100644
> > > --- a/drivers/perf/riscv_pmu_sbi.c
> > > +++ b/drivers/perf/riscv_pmu_sbi.c
> > > @@ -1599,13 +1658,23 @@ static int __init rvpmu_devinit(void)
> > > [ ... skip 15 lines ... ]
> > > +	 * in S-mode via Supervisor Counter delegation.
> > > +	 */
> > > +	if (riscv_isa_extension_available(NULL, SSCCFG) &&
> > > +	    riscv_isa_extension_available(NULL, SMCDELEG) &&
> > > +	    riscv_isa_extension_available(NULL, SSCSRIND))
> > > +		static_branch_enable(&riscv_pmu_cdeleg_available);
> > This needs to not only check that smcdeleg is supported in linux, but
> > also that it is supported in the SBI implementation correct? Trying to
> > boot this on OpenSBI before 6bb6b61c27eb ("lib: sbi: Add support for smcsrind and
> > smcdeleg") will fail on an illegal instruction in
> > rvpmu_deleg_find_ctrs() while trying to access the scountinhibit csr in
> > the patch "RISC-V: perf: Implement supervisor counter delegation
> > support". The proper mstateen bits need to be set for this to work
> > without crashing.
> 
> Yeah. We can do trap/detect to identify if smcdeleg is actually available
> but that is bit ugly.
> The firmware should make sure that it doesn't advertises an ISA extension if
> that is not avaialble
> to S-mode but that model only works for newer firmware.
> 
> if you are running very old firmware with new Qemu/platform, the default ISA
> extension may have
> smcdeleg while older firmware may not even know about it.
> 
> In reality, I am hoping chances of that happening are rare as OpenSBI
> patches have been available
> from a long time and Linux kernel patches are yet to merge. I have not
> addressed this in v9 as I am
> not sure which is the best worst approach yet :)

I had an old opensbi binary laying around and ran into this. This
unfortunately crashes the kernel, but since there is not a good way of
detecting it and newer firmware has handled it for 2 years now, I think
it is acceptable to leave this as-is.

- Charlie

> 
> > 



More information about the linux-arm-kernel mailing list