But by definition RAW events are all implementation-specific (unless or until an arch extension standardizes a set of RAW events and their encodings). At best, the software discovery method that the

I like this proposal! A couple comments... In a couple places you say "the event_info is optional and can be zero". Does this mean that SBI providers must ignore the field, or that non-zero values are

Anup, What does SBI_PMU_NUM_COUNTERS return insofar as distinguishing hardware versus software counters? Greg

Hi All, We don't have a dedicated RISC-V PMU extension for all privilege modes but we do have M-mode HARDWARE performance counters such as MCYCLE CSR, MINSTRET CSR, and MHPMCOUNTER CSRs which are

Indeed, it was great working with you, and you will be missed. Thank you for all your hard work and know you’re always welcome in the RISC-V community! All the best, Stephano -- Stephano

Palmer, We are sad to see you go and you are always welcome back. I know I speak for everyone in thanking you for all you have contributed to RISC-V SW SC and Unux Platform TG. I know we have only

I'm resigning from my posts at the RISC-V Foundation (vice chair of the software standing committee and chair of the UNIX platform specification working group). I know it might seem a bit sudden, but

Thanks, Mark. This is very helpful. Krste, it would be good to get your take on Profiles as well. Arun From: <software@...> on behalf of mark <markhimelstein@...> Date: Thursday, July 30,

I suggest the charter include but not be limited to: 1. define the syntactic format for the content that is human readable. including things like macros etc. 2. define the globally unique record &

[Adding Software and Platform] I agree the Profiles TG will need to work closely with the Config and Platform TGs. Mark, I think it might be helpful if you (and maybe Krste also) could create

Hi Greg, The SBI PMU extension provider for HS-mode is M-mode runtime firmware (OpenSBI) and for VS-mode the provider is HS-mode (Hypervisor). We will enable HARDWARE counters in HCOUNTEREN

It looks like the m-mode firmware would be responsible for selecting a suitable counter and taking the allocation work for s-mode software? Could you elaborate or give a example to show how

Anup, What is the plan with regards to scounteren and hcounteren? Is the caller (whether an OS or a hypervisor) supposed to take into account the relevant *counteren CSR's when specifying counter_idx

Why not have SBI_PMU_COUNTER_SET_EVENT return a 32b hpmcounter bit mask when it fails (that - as Zong suggested - identifies hardware counters that do support the requested event)? Then

Could it put the bitmap of counters which support the given event into ret.value ($a1) if it fails for the given counter, then s-mode software can conveniently find which next one is a good counter

One SBI call to start/stop N counters will certainly be faster than N SBI calls. We did not include SBI calls to start/stop a set of counters because Linux perf drivers only require mechanism to

Should there also be a way to atomically specify start/stop for a set of counters, or is the latency of N SBI start/stop calls short enough that starting or stopping N counters will not take that