I haven't gone through all of sections 3.1 and 3.2 yet, but it seems like 3.1 starts off on the wrong foot. It states that "the current RISC-V spec states that vsie.STIE is an alias of hie.VSTIE". I

Hi Everyone, This is an updated version of our previous proposal on the clock source and clock event source. We have aligned our ideas with the latest hypervisor extension specs, removed the

Works for me

No objections from me. Greg

Any objections with merging Ernie’s PR that allocates addresses for the *context CSRs? Note, it has been pared back from the original request and is only allocating one CSR per privilege mode,

To be fair, I said the same thing a month or so ago and had the same thing pointed out to me! -Allen

You're right, Allen. I didn't think that one was true. Delegation bits are presumably part of the core dispatch area and not kept somewhere else. It would be different to have exceptions depend on

Prvi spec v1.12 sec 3.1.12: When the CY, TM, IR, or HPMn bit in the mcounteren register is clear, attempts to read thecycle, time, instret, or hpmcountern register while

The CSRs can determine what happens on a write and what is read on a read. But they cannot control whether a read or write is legal as far as I know. Bill On 8/20/20 3:28 PM, Allen Baum wrote:

Well, I'd be a little bit more specific: access can be conditioned on more than the CSR number, as the existence of Mcounteren CSR proves. But, in that case, the register bit that controls access is

Chuanhua, The spec is set to determine writable (and required privilege) based entirely on CSR number. Anything that determined exceptions based on data or the current value of the register has been

Hi, Bill, I understand your timing concern for generating an exception based on data values. However, the concern is for data values directly read out from the general registers (GPR/FPR) by the

Hi, Anup, I am fine with dropping the proposal of letting the S-mode write HPMCOUNTER CSRs directly based on its limited use cases in debugging and analysis. Regards, Chuanhua

The potentially problematic case is that if one attempts to run M-mode-only code on a core that supports VM, it might not know that it needs to execute SFENCE.VMA at all. (This is not an especially

Here's the PR for this five-word tweak (as described below) to the spec: https://github.com/riscv/riscv-isa-manual/pull/568

On 8/18/20 8:19 AM, Chuanhua Chang wrote: They're not the same idea. The PMP L bit changes the meaning of a write. Rather than becoming a read-only register, it remains read-write, but writes behave

Hi Chuanhua, Even if we ignore the RISC-V CSR range violation in allowing writes to HPMCOUNTER CSR from S-mode, still the “bypass-sbi” DT property is not an acceptable solution. The

Hi, Anup, Regarding the aspect of a "read-only" CSR, in the RISC-V PMP design, a control bit "L" in the pmpcfg CSR, once set, will change the corresponding read/write pmpaddr CSR to a "read-only"

Hi Chuanhua, The fact that “write-enable” bit in HPMEVENT CSR makes corresponding HPMCOUNTER as writeable violates the RISC-V CSR numbering scheme of RISC-V privilege spec because it allows

Hi Alan, Like mentioned previously, having different mechanism for HS-mode and VS-mode to write HPMCOUNTER CSR is not acceptable. The “bypass-sbi” DT property only means that Linux PMU driver