I understand that mapping of event_idx to HPMEVENT CSR value is platform-dependent, and m-mode firmware of each platform knows how to translate it. But there are still some problems which are

I feel that RV32 designs are going to be more embedded oriented and more cost-conscious - such that they are not going to have all sorts of fancy features that would require 12 bits (plus unused

Great. Yes, that would also be good. Thanks, Greg

Hi Greg, We have already considered what you are requesting. In fact, that is the right way to go. Translating event_idx[XLEN-1:0] to platform specific mhpmeventX CSR value will be optional in

Hi Greg, My bad for the confusion. Yes, I had agreed for 16bits event_idx.code and 4bits event_idx.type. I choose 12bits event_idx.code and 4bits event_idx.type so that we need only 2bytes

Anup, Can I request that the default code path for turning an event_idx value into a value to write into mhpmeventX is to simply write event_idx[XLEN-1:0] into mhpmeventX. Future hardware can then

Anup, I missed a point in the v1 email thread where I was requesting for event_idx.code to be 16 bits along with a 4-bit event_idx.type (which you seemed to agree with), and then you asked whether it

Each element of Event_list consists of event_idx.type and event_idx.code, how does it present the raw event like above? (event_idx.info = 0x12345, event_idx.type = 0x2, event_idx.code = 0x678) It

The Linux PMU driver should be aware of this as well, because SBI_PMU_COUNTER_START takes a parameter for countex_idx which is fed by Linux PMU driver.

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