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 maybe I'm missing something?)

[Anup] The event_idx defined here is for providing uniform platform independent view of various HARDWARE/SOFTWARE events

[Anup] Actual number of bits in mhpmenventX will be platform dependent. The M-mode runtime firmware (OpenSBI) will translate event_idx to platform specific value for mhpmeventX CSR.

Are your event listings intended to represent a layer of mapping between SBI event numbers and actual how-to-program-the-silicon numbers (which would get around the issue above)? They do not match up with Rocket events, for example. Given the number of potential implementers, it is likely impossible to get agreement on a common base set of hardware-compatible events unless we act now, or yesteryear. :)

[Anup] Yes, event listings defined here are generic events. These SBI event numbers (i.e. event_idx) will be translated to platform specific value and then programmed into mhpmeventX CSR.

[Anup] It is not mandatory for a RISC-V platform to implement all generic events listed here. The M-mode runtime firmware (OpenSBI) will determine set of events (i.e. set of event_idx) supported for given counter from platform specific code.

[Anup] We don’t need to put efforts on standardizing generic events for RISC-V world because Linux perf_event subsystem has already done that for us. The generic event listed here are aligned with generic events defined in Linux perf_event user-space ABI defined in at <linux_source>/include/uapi/linux/perf_event.h. These generic Linux perf_events are common across architectures.

I would also recommend at least discussing adding an SBI call that allows one to do a wide write of many/all registers, otherwise writes become incredibly more expensive than reads. I can think of two use-cases that would be writing many of the counters at least several hundred times a second, and maybe even more rapidly. 

[Anup] The SBI calls defined here are only for configuring and starting a counter.

[Anup] Both HARDWARE and SOFTWARE counter will be directly accessible to S-mode software (Linux)

[Anup] The Linux perf_event only expects interface to read a counter. Although, we should certainly have a parameter in SBI_PMU_COUNTER_START call to specify initial value of counter before it is used by S-mode software.

Brian