tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Brian Grayson · #214 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Brian Grayson · #213 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Greg Favor · #212 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Greg Favor · #211 ·

Re: Caching and sfence'ing (or not) of satp Bare mode "translations"

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

By Greg Favor · #210 ·

Re: Caching and sfence'ing (or not) of satp Bare mode "translations"

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

By Bill Huffman · #209 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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,

By Bill Huffman · #208 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By alankao · #207 ·

Caching and sfence'ing (or not) of satp Bare mode "translations"

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

By Greg Favor · #206 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Greg Favor · #205 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By alankao · #204 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By alankao · #203 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Allen Baum · #202 ·

Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By Brian Grayson · #201 ·

A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

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

By alankao · #200 ·

Re: mcycle behavior during stalled wfi

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

By Krste Asanovic · #199 ·

mcycle behavior during stalled wfi

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

By Arjan Bink · #198 ·

Re: xTVAL Compliance restriction proposal

Yes: X (our implementation conforms to this constraint or implements XLEN bits) roger.

By Roger Espasa · #197 ·

Re: xTVAL Compliance restriction proposal

Also a good implementation approach - adding a second variation to what WARL compliance testing would probably need to allow for. At the end of the day, with both the "1-bit" and "2-bit" schemes, one

By Greg Favor · #196 ·

Re: xTVAL Compliance restriction proposal

One could view the effect of MPRV as changing the mode that is in effect for a memory access. For *tval purposes that end result is all that matters. Ditto for the new-ish HLV/HLVX/HSV

By Greg Favor · #195 ·

1121 - 1140 of 1334

Home Hashtags Subgroups Terms