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 operational performance counter registers, though.

      Bill

On 8/20/20 9:26 PM, Allen Baum wrote:

EXTERNAL MAIL

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 the cycle, time, instret, or hpmcountern register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode). 

On Thu, Aug 20, 2020 at 3:29 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> 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 static, held in a CSR, not dynamic and selected by the instruction, as a GPR value would do. 

On Thu, Aug 20, 2020 at 12:35 PM Bill Huffman <huffman@...> wrote:

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 very carefully avoided.  I expect that avoidance to continue.

I'm not knowledgeable on the proposal.   I'm just commenting on CSR instruction exceptions based on additional bits.

      Bill

On 8/19/20 9:16 PM, Chuanhua Chang wrote:

EXTERNAL MAIL

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 instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

EXTERNAL MAIL

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 the cycle, time, instret, or hpmcountern register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege mode (S-mode if implemented, otherwise U-mode). 

On Thu, Aug 20, 2020 at 3:29 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> 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 static, held in a CSR, not dynamic and selected by the instruction, as a GPR value would do. 

On Thu, Aug 20, 2020 at 12:35 PM Bill Huffman <huffman@...> wrote:

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 very carefully avoided.  I expect that avoidance to continue.

I'm not knowledgeable on the proposal.   I'm just commenting on CSR instruction exceptions based on additional bits.

      Bill

On 8/19/20 9:16 PM, Chuanhua Chang wrote:

EXTERNAL MAIL

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 instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

EXTERNAL MAIL

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 static, held in a CSR, not dynamic and selected by the instruction, as a GPR value would do. 

On Thu, Aug 20, 2020 at 12:35 PM Bill Huffman <huffman@...> wrote:

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 very carefully avoided.  I expect that avoidance to continue.

I'm not knowledgeable on the proposal.   I'm just commenting on CSR instruction exceptions based on additional bits.

      Bill

On 8/19/20 9:16 PM, Chuanhua Chang wrote:

EXTERNAL MAIL

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 instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

EXTERNAL MAIL

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 instruction itself and the exception is generated based on these values or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).

The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation of an exception of the write operation of a counter CSR for S and U-mode.

This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.

Regards,
Chuanhua

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" CSR.

So fundamentally, I do not see any reason why a control bit cannot change a "read-only" CSR to a "read/write" CSR. It should be similar to the above case in terms of implementation complexity.

And regarding the aspect of a "user" CSR, I also do not see any reason why a higher privileged mode such as S-mode cannot write to a user register, once the write permission is allowed by M-mode.

Regards,
Chuanhua

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 configurations more than M-S-U should not provide a PMU with "bypass-sbi" attribute, like QEMU virt.  Neither VS- nor  HS- usage will be affected by this bit.  Then, you ask, what about emulating a platform that aims to only runs on M-S-U machines?  Well, the one who ports the platform to QEMU/other simulators should put some warning message when the attempt to write happens, rather than implement the whole save-restore just for the PMU status.

We don't need to add many CSRs.  Just one bit in hpmevent*.

Regards,
Alan

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?  So far, nobody provided any convincing pieces of evidence. Yet, I would like to share our findings from an out-of-the-box experiment.

The system for testing is a 4.17-based Linux branch which contains andes_pmu patch, running on our A27 design on FPGA.  The testing command was 

time perf record -e cache-references ./whestone

where "cache-references" is an andes_pmu cache event and the target program is a normal whestone executable.  We tested three different settings,

Baseline: all HPM CSRs are written in S-mode using plain csr_write.

SBI1: HPM counter CSRs are written with SBI calls.
SBI2: HPM counter and event CSRs are written with SBI calls.

We ran each of them 20 times and calculate the average of "real" part of the output.  It turns out that, (in seconds)
Baseline:  23.131
SBI1: 24.840 (increasing 7.4% more time from baseline)
SBI2: 25.691 (increasing 11.1% more time from baseline)

Considering the result, does the write-enable bit count as a benefit now?
Also, it's perfectly fine that QEMU virt platform doesn't support PMUs which allow S-mode to write HPM CSRs, so I don't think #279 answers #280 and #278.

Thanks,
Alan

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 attribute of its PMU.

Of course, I know the SBI route works.  If you don’t see the benefit, based on what did you say the feature is good? 

Your words were “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” So the issue here is if it will benefit much or marginally.

Writing from S-mode can skip the whole M-mode part every time the kernel wants to write CSRs.  Isn't that obvious?

Also, you didn't comment on my final part yet.

Thanks,

Alan