1. Messages
  2. Requirements on implementing cycle/instret/hpmcountern

Re: Requirements on implementing cycle/instret/hpmcountern

Allen Baum
 



On Thu, Jan 26, 2023 at 1:39 AM Greg Chadwick <gac@...> wrote:
> .....I still think a direct conversion to a memory access is fraught with issues (in particular how you deal with exceptions, say a software PMP mis-configuration causes mtime to be un-readable, what do you get when 'csrr time' is executed?).

We are not responsible for SW bugs - and that's clearly sa software bug. 
If it hurts when you do that, don't do that.
 
> It is inconsistent, but pretty easy to understand, and Mcode really has no need to use it if it can just do the load to the MMIO address.

I agree there's no reason from M-mode to execute 'csrr time' but it's still something that can happen so I'd like to understand the architecturally permissible behaviours when it does.

My understanding is that if it's listed in the spec, then it is required for M-mode (unless specifically called out, I guess).

This is a U-mode CSR, and the expectation is that it performs identically regardless which mode it is executed in. So, it is entirely legal for an Mmode access to time CSR to trap.

Similarly, if M-mode executes a Load or store with MPRV=1, and the translation is an illegal address (e.g. upper PA bits are non-zero, or PTE entry doesn't have the correct permissions) then that Mmode emulation access will trap - and if Mmode isn't prepared to handle that, you'll go into infinite trap hell.

If it hurts when you do that, don't do that.
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.