A proposal to enhance RISC-V HPM (Hardware Performance Monitor)


alankao
 

Hi Anup,

> Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit.

It doesn't matter where the kernel does the update.  What matters is how often kernel does add() and start().  Anyway, it may take a while but we will do the experiment mentioned in previous thread to give real evidence here.

> We should avoid a kernel feature which needs to be explicitly enabled by users and distros keeping it disabled by default. The “#ifdef” based feature checking should be replaced by runtime feature checking based on device tree OR something else.

Is there any way for a kernel to detect if it is in S-mode or VS-mode?  If so, then just don't go that route when writing HPM CSRs.  Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.


Allen Baum
 

I may be dense (I won't take a poll on that though), but if a kernel can detect that it is in S-mode vs. VSMode, that sounds like a buggy virtualization scheme. The kernel should (appear to) be in whatever mode it thinks it is, even if it is really in VU mode (with appropriate hypervisor work, and  performance penalties, etc).

On Tue, Aug 4, 2020 at 9:52 PM alankao <alankao@...> wrote:
Hi Anup,

> Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit.

It doesn't matter where the kernel does the update.  What matters is how often kernel does add() and start().  Anyway, it may take a while but we will do the experiment mentioned in previous thread to give real evidence here.

> We should avoid a kernel feature which needs to be explicitly enabled by users and distros keeping it disabled by default. The “#ifdef” based feature checking should be replaced by runtime feature checking based on device tree OR something else.

Is there any way for a kernel to detect if it is in S-mode or VS-mode?  If so, then just don't go that route when writing HPM CSRs.  Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.


Anup Patel
 

Hi Alan,

 

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.

 

The SBI PMU extension is designed such that kernel need not be aware of HS-mode or VS-mode. For Guest kernel (VS-mode), SBI is provided by Hypervisor so Hypervisor will act as mediator for Guest kernel. For Host kernel (HS-mode), SBI provider is M-mode runtime firmware (OpenSBI). The Linux PMU driver should not

care which mode it is running (HS-mode or VS-mode). The same rationale applies here, we use single Linux RISC-V kernel image for both Guest and Host.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 05 August 2020 10:23
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

Hi Anup,

> Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit.

It doesn't matter where the kernel does the update.  What matters is how often kernel does add() and start().  Anyway, it may take a while but we will do the experiment mentioned in previous thread to give real evidence here.

> We should avoid a kernel feature which needs to be explicitly enabled by users and distros keeping it disabled by default. The “#ifdef” based feature checking should be replaced by runtime feature checking based on device tree OR something else.

Is there any way for a kernel to detect if it is in S-mode or VS-mode?  If so, then just don't go that route when writing HPM CSRs.  Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.


Anup Patel
 

Yes, there is no way for kernel to know whether it is running in HS-mode or VS-mode. We would like to keep it that way.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Allen Baum
Sent: 05 August 2020 11:19
To: alankao <alankao@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

I may be dense (I won't take a poll on that though), but if a kernel can detect that it is in S-mode vs. VSMode, that sounds like a buggy virtualization scheme. The kernel should (appear to) be in whatever mode it thinks it is, even if it is really in VU mode (with appropriate hypervisor work, and  performance penalties, etc).

 

On Tue, Aug 4, 2020 at 9:52 PM alankao <alankao@...> wrote:

Hi Anup,

> Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit.

It doesn't matter where the kernel does the update.  What matters is how often kernel does add() and start().  Anyway, it may take a while but we will do the experiment mentioned in previous thread to give real evidence here.

> We should avoid a kernel feature which needs to be explicitly enabled by users and distros keeping it disabled by default. The “#ifdef” based feature checking should be replaced by runtime feature checking based on device tree OR something else.

Is there any way for a kernel to detect if it is in S-mode or VS-mode?  If so, then just don't go that route when writing HPM CSRs.  Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.


alankao
 

> 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 totally am aware of that.  That's why I don't think the same route should be taken in a guest OS.  But since the kernel should not be able to have that knowledge, that is not possible.  I am sorry that I mentioned a condition that confused everyone who shows many interests in H extension. 

Then, please allow me to refine my statement in my previous comment:

> (I asked) Is there any way for a kernel to detect if it is in S-mode or VS-mode?

The answer is no, and should always be not allowed to.

> (I derived) If so, then just don't go that route when writing HPM CSRs.  

But, I would like to claim that this is still possible.  As follows,

> (I stated) Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.

Let me elaborate more. The CONFIG_FPU is true by default.  During system booting, the ISA string in hart nodes in the DTB is checked.  If "fd" is presented, then a global variable has_fpu is set to true; otherwise, false.  Later, during signal handling or context switch, has_fpu is checked.

Why cannot we apply the same path? The CONFIG_RESTRICT_HPM_REG_ACCESS is true by default.  During system booting, the "bypass-sbi" attribute in PMU nodes in the DTB is checked.  If presented, then a global variable mhpm_writable is set to true; otherwise, false.  Later, in PMU life cycles, the variable is checked.  With that flag, the way to update to the desired registers can be decided.  Now the key is in DTB, you can decide that the PMU you are using contains no extra attributes like "bypass-sbi".


Anup Patel
 

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 differently for HS-mode and VS-mode in Linux PMU driver because kernel has no way of knowing which mode kernel is running (HS-mode or VS-mode).

 

The SBI_PMU_COUNTER_START() call can’t be by-passed because the bits which turn-on or turn-off counting are accessible to M-mode only. This SBI_PMU_COUNTER_START() call also takes counter start value provided by Linux PMU framework. We can easily write the counter start value in SBI implementation (M-mode runtime firmware) instead of writing it in S-mode. I still don’t see the benefit of directly writing counter value in S-mode.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 05 August 2020 13:16
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

> 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 totally am aware of that.  That's why I don't think the same route should be taken in a guest OS.  But since the kernel should not be able to have that knowledge, that is not possible.  I am sorry that I mentioned a condition that confused everyone who shows many interests in H extension. 

Then, please allow me to refine my statement in my previous comment:

> (I asked) Is there any way for a kernel to detect if it is in S-mode or VS-mode?

The answer is no, and should always be not allowed to.

> (I derived) If so, then just don't go that route when writing HPM CSRs.  

But, I would like to claim that this is still possible.  As follows,

> (I stated) Just like what we did with CONFIG_FPU, I suggest we can set CONFIG_RESTRICT_HPM_REG_ACCESS or something true by default, and detect if there is some attribute like "bypass-sbi" in a PMU node.  With static key feature and the followups, this runtime check is not expensive.

Let me elaborate more. The CONFIG_FPU is true by default.  During system booting, the ISA string in hart nodes in the DTB is checked.  If "fd" is presented, then a global variable has_fpu is set to true; otherwise, false.  Later, during signal handling or context switch, has_fpu is checked.

Why cannot we apply the same path? The CONFIG_RESTRICT_HPM_REG_ACCESS is true by default.  During system booting, the "bypass-sbi" attribute in PMU nodes in the DTB is checked.  If presented, then a global variable mhpm_writable is set to true; otherwise, false.  Later, in PMU life cycles, the variable is checked.  With that flag, the way to update to the desired registers can be decided.  Now the key is in DTB, you can decide that the PMU you are using contains no extra attributes like "bypass-sbi".


alankao
 

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


Anup Patel
 

Hi Alan,

 

My statement “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” is because:

  1. Linux PMU updates counter value in-frequently only in start() callback
  2. The SBI_PMU_COUNTER_START/STOP calls will be used to turn-on and turn-off counting in start() and stop() callbacks respectively
  3. Due to point1 and point2, we can easily set the HPMCOUNTER value in SBI implementation via SBI_PMU_COUNTER_START call.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 05 August 2020 14:11
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

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


Jonathan Behrens <behrensj@...>
 

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. This is especially true for smaller projects like research/teaching operating systems, which don't have the resources of something like the Linux kernel.

There is a long history of paravirtualization (virtualization where the guest kernel knows it is in a VM), but that is generally only done in cases where the original interface was poorly designed, or for exposing features that don't make sense on actual hardware. I don't think it should be used here.

Jonathan


On Wed, Aug 5, 2020 at 5:23 AM Anup Patel via lists.riscv.org <anup.patel=wdc.com@...> wrote:

Hi Alan,

 

My statement “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” is because:

  1. Linux PMU updates counter value in-frequently only in start() callback
  2. The SBI_PMU_COUNTER_START/STOP calls will be used to turn-on and turn-off counting in start() and stop() callbacks respectively
  3. Due to point1 and point2, we can easily set the HPMCOUNTER value in SBI implementation via SBI_PMU_COUNTER_START call.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 05 August 2020 14:11
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

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


alankao
 


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


Anup Patel
 

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 extension proposal for benchmarking.

 

My question in-context of Hypervisors is still unanswered. The existing HPMCOUNTER CSRs are in read-only CSR range. We will need separate CSR range from S-mode Read-Write CSRs. Further, we will also need separate CSRs from HS-mode to save-restore VS-mode HPMCOUNTER CSRs states.

 

A more general question is that is it worth to add so many CSRs and add increase overhead for Hypervisors just to make HPMCOUNTER writeable form HS-mode and VS-mode. We should also consider the fact the Linux perf will be mostly used for debugging and analysis.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 18 August 2020 14:12
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

 

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


alankao
 

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


Chuanhua Chang
 

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


Anup Patel
 

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 is now aware whether it is running natively or running inside Guest/VM. This is totally hacky and won’t be acceptable.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 18 August 2020 15:17
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

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


Anup Patel
 

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 S-mode writing to a CSR from “User-read-only” range.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Chuanhua Chang
Sent: 18 August 2020 15:35
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

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


Chuanhua Chang
 

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


Anup Patel
 

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 “bypass-sbi” DT property will make Linux PMU driver do things differently for HS-mode and VS-mode. Further, it is totally unclear how “bypass-sbi” DT property should be used in nested virtualization because here we will have virtual VS-mode (Guest OS) running on virtual HS-mode (Guest Hypervisor) which in-turn runs on real HS-mode (Host Hypervisor). For a clean nested virtualization, both HS-mode (Hypervisor) and VS-mode (Guest) should write HPMCOUNTER CSR in the same way.

 

Further, the “bypass-sbi” DT property cannot be used for existing RISC-V platforms (SiFive Unleashed, Microchip PolarFire, etc) because existing HARDWARE don’t have proposed “write-enable” bit in HPMEVENT CSR. This means Linux PMU driver will again have to do things differently for existing RISC-V platforms.

 

I think if we want to allow S-mode direct writes to HPMCOUNTER CSRs along with clean nested virtualization then it is better to add separate HS-mode and VS-mode CSRs. Although, I am still wondering why we should allow S-mode direct writes to HPMCOUNTER CSRs considering Linux perf tools are only used for debugging and analysis.

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Chuanhua Chang
Sent: 18 August 2020 20:49
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

 

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


Bill Huffman
 


On 8/18/20 8:19 AM, Chuanhua Chang wrote:
EXTERNAL MAIL

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.

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 with read-only numbers always take an exception on write.  The idea behind this is that exceptions do not depend on data in CSR registers to avoid difficult timing/layout issues.

       Bill


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


Chuanhua Chang
 

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


Chuanhua Chang
 

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