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

I'd also strongly argue for there only being a single configuration for both virtualized and non-virtualized systems. The fewer different cases that software has to handle, the better for everyone.

Hi Alan, My statement “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” is because: Linux PMU updates counter value in-frequently only in start() callback The

Hi Anup, > The “bypass-sbi” DT property will break QEMU virt machine No, it won’t. Why should QEMU virt machine’s PMU follow this flag? The platform can totally choose not to support

The “bypass-sbi” DT property will break QEMU virt machine for KVM because same QEMU virt machine is used with both TCG and KVM acceleration. This is yet another work-around for doing things

> I think I am repeating myself here but still don’t see any benefit of allowing HPMCOUNTER CSR write access to S-mode. On the contrary, it will make context switching expensive for hypervisors. I