Based on my previous reply… To monitor RAW event 0x12345678, user-space perf tool will create user space perf RAW event (i.e. perf_event_attr.type == 4 and perf_event_attr.config = =

Like Greg already mentioned, SBI PMU event_idx.type == 0x2 is HARDWARE RAW event. To monitor RAW events, user-space perf tool will create user space perf RAW event (i.e. perf_event_attr.type == 4

I think this need is covered by this excerpt from the v2 proposal: If event_idx.type == 0x2 then it is HARDWARE RAW event. For HARDWARE RAW event, both event_idx.info and event_idx.code are platform

My question is, let's say I know that putting the value 0x12345678 into the mhpmevent3 register gets me the event I want, and there is no support for that event in the SBI spec/API. Will this API

Follow this question, in our current proposal, s-mode software only knows the event_idx, and m-mode firmware takes care of the mapping, my question is that s-mode software doesn't seem to understand

Kindly send the proposal to the mailing list. We have enough topics now so that we can setup a meeting to discuss and finalize things. -- Regards, Atish

Would there be a raw style interface to access all the SBI-unaware events, like perf's rNNN support? How would this work on a multicore system -- would the SBI calls only handle the current hart's

The key is we need to know the range of HW counters and SW counters in countex_idxs. Even if we use continuous logical counter_idx, we still need knowing HW counters and SW counters respectively for

Based on the optimization as you mentioned, it is good to me if we have SBI call to get the number of HW and SW counters respectively. If s-mode OS can know the separating numbers, then s-mode OS can

I was suggesting to have fixed ranges for both event types. But I agree that it gets tricky with non-standard implementation specific counters. My concern is that it may increase the booting time.

Hi Atish,

Hi Brian, Please see my reply inline below.. Regards, Anup

Is there a reason you are limiting the event to 16 bits? On current designs, the mhpmeventX field is already >16 bits wide. I don't see an easy way to support that with this approach directly. (Or

That's what my understanding as well. Assigning continous counter_idx may put a restriction on M-mode implementation. How about assigning some ranges for software vs hardware counters. May be split

OK, I assume the logical number of counte_idx is sequential and started from zero here, so during initialization of s-mode software, we could get the total number 'N' of counters by

Is there more detail about counter_idx? I was wondering that 1. What is the ordering of logical numbers for HW and SW counters? I think that the logical numbers are assigned by OpenSBI. 2. How to know

Hi All, We don't have a dedicated RISC-V PMU extension but we do have HARDWARE performance counters such as CYCLE CSR, INSTRET CSR, and HPMCOUNTER CSRs. A RISC-V implementation can support monitoring