Thanks for the timely comment, we are aware of the htimedelta CSR in the hypervisor spec. Section 3 is meant to propose aliases available in VS-mode and VU-mode. Because they are meant to provide time

Note that Section 3 of your proposal already exists. The hypervisor spec says, "The htimedelta CSR is a read/write register that contains the delta between the value of the time CSR and the value

Hello Everyone, We have come up with some ideas about improving the performance of virtual machines on the RISC-V architecture. Here’s the first piece which proposes a dedicated clock source and

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