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

The SBI SOFTWARE events will be treated same as SBI HARDWARE RAW events in Linux PMU driver. The Bit63 of perf_event_attr.config will be used by Linux PMU driver to distinguish between SBI SOFTWARE

A normal SBI call is perhaps 2x faster than doing trap-n-emulate, but something like 100x slower than a shared memory read. If the reads are going to be very frequent we should go with the shared

Given the cost / complications to support making M-mode software counters directly readable by non-M-mode software, this compromise is probably a good one to make. (It's easy to conceptualize what

Trap-n-emulate illegal instructions is bit expensive particularly when MTVAL/STVAL CSR does not have the illegal instruction encoding because in OpenSBI/Hypervisors we end-up doing unprivileged access

Instead of SBI_PMU_SOFTWARE_COUNTER_READ, we could even just trap-and-emulate accesses to HPMCOUNTERx. The performance difference should be relatively minimal (at least compared to the shared memory

Ahh, I didn't realize that these were only M-mode software counters, i.e. they are only controlled and incremented by M mode.. That makes things clearer now. In which case, why not go with the

Instead of having separate physical address for each SOFTWARE counter, we can have single base physical address for all SOFTWARE counters. Each SOFTWARE counter will be written at address = <base> +

What I imagine is that a block of memory is allocated up front for software counters, and with PMPv2 that is made from within a "shared" region of memory. Individual counters are then allocated from

How about "Non-zero values for event_info are reserved. Future versions of this specification may use them to pass configuration flags like event filter, overflow interrupt, etc." There likely

For SBI_PMU_COUNTER_GET_PHYS_ADDR call, both OpenSBI and Hypervisors will have to show SOFTWARE counter memory as reserved memory regions in device-tree. This is straight forward for OpenSBI but it

The SBI_PMU_SOFTWARE_COUNTER_READ call certainly has performance issue. The only benefit it provides is no shared mapping. Anyway, we can’t compromise performance so let’s drop this idea.

If my last comments are valid, then it seems like we're back to having either SBI_PMU_COUNTER_GET_PHYS_ADDR or SBI_PMU_COUNTER_SET_PHYS_ADDR. In which case (since both S/HS and M modes need to

Allowing event_info to be zero by default is OK. But as some of the higher bits of mhpmevent CSRs become standardized (or someone has non-standard bits up there), event_info will need to be non-zero

I realize that in my comments below to Jonathon's SBI_PMU_COUNTER_SET_PHYS_ADDR question, I should have asked (to Anup) whether all allocation of counters is to be done by OS/hypervisor and M-mode

Hi Jonathan, I agree “the event_info is optional and can be zero” is totally misleading for HARDWARE and CACHE events. Thanks for pointing. Eventually, the event_info will be used to pass

Thanks. That's what I was speculating in the second half of my question, i.e. software will have to call SBI_PMU_COUNTER_GET_CSR N times no matter what (after obtaining 'N' from a call to

Hi Greg, We want to allow RISC-V implementation specific CSRs (apart from various HPMCOUNTER CSRs) as HARDWARE counters. Due to this reason, we have decoupled counter_idx from CSR number and we

Anup, Wouldn't software want to more easily and directly know from SBI_PMU_NUM_COUNTERS how many hardware counters and software counters there are, instead of having to then call

Hi Greg, The SBI_PMU_NUM_COUNTERS call will return total number of counters (HARDWARE as well as SOFTWARE). We can distinguish between HARDWARE and SOFTWARE counters using the CSR_Number