That sounds good. Greg

Hi Greg, How about having event_idx as XLEN bits wide?? It can be encoded as follows (similar to what you suggested): event_idx[XLEN-1:16] = info event_idx[15:12] = type event_idx[11:0] =

Essentially, Yes. This is a little different that what I had described, but this is equally fine (if not a little simpler). One can eliminate the separate event_info parameter and just have one

Yes, I think this should be 4-steps for HW counters. The last step#3 will be broken down into programming hpmeventX CSR and optional platform specific progamming. Regards, Anup

You are correct, 16bit CSR_number is sufficient. I am thinking of using lower 12bit of CSR_number as absolute RISC-V CSR number. This way we can point to any (even implementation specific) CSR as

I agree HPMEVENT CSRs are sufficient for most RISC-V system assuming RV64 will be more common compared to RV32. The M-mode runtime firmware (OpenSBI) will have to deal with implementation specific

Hi Greg, I support your suggestion for re-using hpmeventX CSRs for both selecting and filtering events but I am worried about RV32 because hpmeventX CSRs will be 32bit on RV32. Due to this reason,

It was a deal in the last decade. There was concern for support for boot devices like non-64-bit addressing capable USB, 32-bit BARs in PCI and possibly other such older protocols. Without requiring

It seems to me that we should figure out the usage of event_idx. Who is responsible to translate the event_idx to the real hw event of each platform and how to translate it. 1. Monitor generic

In the following step #3, I think in most implementations the event selection would be a matter of writing the event_idx information into the hpmeventX CSR associated with hpmcounterX. The

Hi Greg, I disagree. Are you proposing a way for software to overload some CSRs that were specifically named HPMEVENT? No matter what ... Please check my comment at

Why have CSR_number be a 32-bit value? Even a 16-bit value would be way, way more than enough. One could argue that even a byte - providing for up to 256 counters - is more than enough. With a

But that is the point of the standard HPMEVENT CSRs - each HPMCOUNTER CSR has an associated HPMEVENT CSR. With the expectation that the HPMEVENT CSR, in some manner, selects the event to be counted

Anup, Just to clarify a couple of things as to where I was coming from (which I think would mirror other people that also want to have more than just an event selector field in the hpmevent CSR's): We

Sorry for unclear description in DT binding file. The event mapping of property maps generic HW events of kernel to particular HW events of platform, doesn't map to specific counters, so it doesn't

Hi Greg, Thanks for the feedbacks and requests. I had kept event_idx to be just 15bits so that all possible events can be represented by a bitmap of 2048 bytes. I certainly see the advantage

Anup, This is great to see - as part of standardizing how RISC-V HPM counters are configured and controlled by softare I have a modest but important request: Increase the size of the event_idx 'code'

Do we need the SBI calls to set the mcounteren and mcountinhibit (optional CSR)? OR these two CSRs shouldn't be changed at runtime from s-moe? I'm not sure whether I misunderstood the usage of