Hi all, I am for bit[28]. I tried to defend the idea but unfortunately my reply goes private to Anup only, and the system doesn't leave any backup. Please wait and see my comment once Anup replies.

That reduces the argument for bit [31]. I won't remove it yet (until I write up an updated proposal), but I imagine that bit will be dropped if no one else speaks up in support of it. (Although

Hi Greg, No issues with Bit[31] of your proposed MHPMEVENT definition. The SBI_PMU_COUNTER_START/STOP calls can either update MCOUNTINHIBIT Bits or these calls can update Bit[31] of appropriate

Hi Greg, We have SBI_PMU_COUNTER_START/STOP calls where the SBI implementation will update the MCOUNTINHIBIT bits. The SBI_PMU_COUNTER_START call also take parameter for initial value of counter

Anup, Thanks. Comments below. Greg This is up in the air for inclusion or not in the proposal. As solely a bit that software can set/clear to start/stop a counter, the argument for having this bit

Email accidentally sent early. Let me finish the email and then I'll send it again. Greg

Anup, Thanks. Comments below. Greg This is up in the air for inclusion or not in the proposal. As solely a bit that software can set/clear to start/stop a counter, the argument for having this bit

Hi Greg, Few comments on your proposal (https://lists.riscv.org/g/tech-privileged/message/205): 1. The BIT[31] is not required because we already have MCOUNTINHIBIT CSR 2. The BIT[28]

Hello, Background: You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or

On 8/3/20 7:01 AM, Jonathan Behrens wrote: Agreed, but the proposal doesn't assume that a custom implementation will use the bits of satp in the same way the priv spec uses them. The bits may well be

It depends on how you are using them. For x86-64, Linux actually only uses 4 ASID bits (out of the 12 available) because it assigns them per-core and recycles them aggressively. However, if you

>For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved. I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom. Are 7 bits enough , for ASID?

Looks appropriate to me. Bill On 7/31/20 4:22 PM, Andrew Waterman wrote:

I've written the idea up so it doesn't get lost, but others should still feel free to comment. In the meantime, can you sanity-check my patch?

Hello, Background: You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or

That sounds like a no brainer good idea. -Allen

Alan, I'm fine with taking the lead on this architecture extension. But it should follow a proper process as directed by the TSC. Thus far this would mean getting a new TG created or doing something

Hi all, Although there were some non-resolved discussions, it has little to do with what we should do for the next step. I believe Greg's proposal is superior to the original one in the starting

I support this proposal.

The satp register has reserved values. Some implementers will, no doubt, want to define non-standard behavior based on satp. I would like to propose that we define some of the reserved values in