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

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