Ah, I see. The 'marked' bit is state associated with and managed by the code running, not associated with a counter. Then a counter could be configured (via its event selection) to count a selected

It's late; I'm missing something. How is "mark" being set/cleared on entry/exit different than "active" in Greg's proposal being set/cleared on entry/exit ?

Hi All, The proposed SBI PMU extension is a set of APIs between M-mode and HS-mode (also between HS-mode and VS-mode) such that no RISC-V spec changes are required for existing HPMCOUNTERs.

The 'marked bit' in my proposal is different from a per-counter active bit, and may be a bit hard to explain well, but I'll try. To me, there are two very different performance monitor approaches for

Hi, Alan. My proposal is still a work in progress, hence has not been shared publicly, but is significantly based on a proven architecture with about 30 years in the field and a few billion shipping

Bill, Hopefully my last email also answers your question. Greg

Alan, Hi. Comments below. At this surface it isn't, but in practice it is or wants to be for the following reasons: - One wants the 'Active' state to be with all the other state of a counter so that

Comments below: Switches to/from Bare mode should be rare. Typically one will switch from Bare mode to a translated mode as part of booting up an OS (e.g. Linux), and then will remain in that mode

Hi Greg, My sense is that the transitions from SvXX to Bare and from Bare to the same SvXX that was previously in force are special transitions. One reason seems to me the extreme simplicity of Bare

Brian, I'm curious whether the 'marked' bit is a significant improvement on the mcountinhibit CSR, which could be swapped to enable counters for multiple processes. Bill On 7/20/20 1:54 PM,

Hi Greg, Questions: - Is Active (bit[31]) any different from the inhibit register, functionally speaking? - Assume that we are making this HPM as an extension (maybe Zmhpm, Zshpm?). How is it possible

I would like to get people's views on the question of when is an sfence.vma required after changing the satp.mode field (to see what support there is for the following change/clarification in the

It's nice to see people starting to get serious about addressing this long standing issue. We (Ventana) also worked out a proposal for these issues - that is more in the vein of what Brian mentioned

It was just so poorly rendered in my mail client, so please forgive my spam. Hi Brian, > I have been working on a similar proposal myself, with overflow, interrupts, masking, and delegation. One of

Hi Brian, Thanks for sharing your experience and the elaboration. The overloading-hpmevent idea looks like the one in the SBI PMU extension threads in Unix Platform Spec TG by Greg. I have a bunch of

I had thought about reserving config bits in hpmevent as well, but thought that it would not be backwards compatible then. In practice, it might be (in practice, I suspect the MSU bits are already

I have been working on a similar proposal myself, with overflow, interrupts, masking, and delegation. One of the key differences in my proposal is that it unifies each counter's configuration control

Hi all, This proposal is a refinement and update of a previous thread: https://lists.riscv.org/g/tech-privileged-archive/message/488. We noticed the current activities regarding HPM in Linux

mcycle is considered part of the HPM facility. If the clock to the core is not running, mcycle does not need to increment. If part of the core is being clocked (including just mcycle), then mcycle can

Hi, The mcycle CSR is described in the RISC-V Privileged Architecture spec as: What does 'clock cycles executed by the processor' mean in the context of a WFI instruction? For example, if a core is