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 differently and do nothing. Registers

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

The idea of adding write enable bit without adding extra CSR in the read/write register range is that the setting of the write enable bit will change the read-only CSR to a read/write CSR. Chuanhua

Hi Anup, We did the experiment based on our own settings and not yet consider the SBI extension proposal. Please consider the approach in #278 with one additional condition: Any platform that supports

Hi Alan, Thanks for the data points. The proposed SBI_PMU_COUNTER_CONFIG_MATCHING will helps us minimize SBI calls for configuring HPMEVENT CSR. I am not sure if you have considered latest SBI PMU

Hi Anup, Fair enough. Of course, your conclusion is totally correct: "we CAN EASILY set the HPM* ...," but the real question here is in point 1: Are counter updates really that in-frequent so?

Allen Baum wrote: The interpretation is supposed to be the second one. Actually, no, for two reasons: First, supervisor-level interrupts are normally handled in S mode, and bit SEIP isn't writable

You say "The value that a CSR instruction reads from mip into the instruction'srd destination is not affected by which CSR instruction does the read, whether it's CSRR, CSRRW, CSRRC, or CSRRS. " but

Simon Davidmann wrote: The section you are quoting, 3.1.9, "Machine Interrupt Registers (mip and mie)", says nothing about the N extension. If you look at the figures for the mip register in that

Ken Dockser wrote a document on instruction encoding guidelines, but not the actual values of the minor/major opcodes, or sub-minor (functX) fields. Attached

Krste has said (correct me if I am wrong) that the unpriv SC owns the opcode space. I know there is a lot of overlap in the SC members but I suggest we get that SC officially in the loop. I have CC'ed

We posted this on https://groups.google.com/a/groups.riscv.org/g/isa-dev/ but had no response in 2 weeks - so maybe this is a better place: Looking forward to a response. Simon The Privileged

P extension instructions need to allocate opcode encoding space officially in the OP opcode space or other major opcode (such as reserved opcode). What is the best way to decide on this and

One could argue that the current spec and the sentence in question (with or without the suggested modification), is clear in calling out when an sfence.vma is not required. But I agree that adding a

Do you want to add more detail about the page-based virtual memory being disabled case? (that some implementations may require sfence.vma, depending on whether they do XXX with their TLB)? That

In section 3.6.2 of the Privileged spec discussing changing PMP settings, it currently says: I would like to suggest removing "or when it is disabled" and just say: The motivation is that

RISC V needs CMOs, and hence a CMO Working Group EditNew Page