Re: Proposal v2: SBI PMU Extension
|
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 OpenSBI (M-mode runtime firmware). If a platform does not want to translate event_idx value then we will write event_idx as-in in mhpmeventX CSR.
Regarding total number of bits used by event_idx.type and event_idx.code, I am fine with both 16bits and 20bits approaches. If there is no further objection for using 20bits approach then I will go with that.
Regards, Anup
From: Greg Favor <gfavor@...>
Sent: 10 July 2020 04:48 To: Anup Patel <Anup.Patel@...> Cc: Brian Grayson <brian.grayson@...>; Zong Li <zong.li@...>; Atish Patra <Atish.Patra@...>; andrew@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] Proposal v2: SBI PMU Extension
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 (optionally) choose to implement their mhpmeventX's with this standardized format and avoid the need to provide implementation-specific code for translating event_idx to the value to write into the implementation's mhpmeventX's. Other past and future implementations can of course do whatever they want and provide a custom piece of "translation" code for use within OpenSBI.
In essence, this SBI PMU extension serves to standardize the low twenty bits (event_idx.type + event_idx.code) of mhpmeventX in a way that meshes fully and cleanly with what Linux perf currently supports (which is great). While type==RAW (and the event_idx.info field) provides support for whatever else an implementation wants to do with all the other bits of mhpmeventX.
Greg
On Thu, Jul 9, 2020 at 12:57 AM Anup Patel <Anup.Patel@...> wrote:
|
|
|