Same understanding here Anup. The most of uses are runtime debug, trace, compliance validation and POST time firmware (configures H/W and also builds up DT for the software you mentioned). Abner

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it. All these software will: Either use

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

Andrew, the intention of Configuration Structure task group is to define RISC-V core/hart hardware features in the configuration structure and retrieved by M-mode software without probing the

This is not needed. We can easily probe number of PMP registers using illegal instruction traps. Look at latest OpenSBI sources. Regards, Anup

The situation hasn't changed: it has always been straightforward to write M-mode software to detect the number of PMP registers at runtime, relying on precise exceptions. IMO, that means this stuff

Just writing to confirm that there is no information regards to the # of PMP entries supported by hart mentioned in privilege spec . If my understanding is correct, then this information is good to go

I've made a pull request to extend the number of PMP entries, and have attached the compiled PDF for convenience. Feedback and error detection are appreciated: the fact that there used to be 16 PMP

Hi Andrew, That’s fine for me. Implementing 0 / 16 / 64 PMP entries is ok Tariq

The other option here is to allocate all 48 at once (and for your example 20-63 would be read-only-zero). This might be slightly easier for software portability and is neutral for HW cost. 👍

Hi everyone, Can we allocate more CSRs so that we can have more PMP entries available? We already have one implementation which requires 20 PMP entries, for example. Currently the CSR address

Agreed that the counter in your example can be important to system operation. OK, I'm fine with this. I still think this PMA confounds the notion of idempotency with speculation control (i.e.

> That sounds a bit like a performance counter to me, but it does > raise an interesting question whether "idempotent" in the > architectural sense is idempotent in a mathematical sense >

Of course I meant “non-idempotent”... discouraging page-table accesses to idempotent regions might raise some hackles.

To clarify, in my previous email, I was taking a rather narrow view of the idempotent/non-idempotent attribute as applied to a memory location. One could broaden that definition to include system

P.S. This stripped down ARMv8 definition goes a little further than what is currently in the Privileged spec - which only says that accesses are non-idempotent if reads and/or writes have any side

For reference here is ARMv8's definition of idempotency (which includes side-effects): Put very concisely (and stripped down a bit): Reads and writes can be repeated without side-effects, and reads

On 5/18/20 5:10 PM, David Kruckemyer wrote: I've always assumed that it included any side-effects that mattered to the program. It obviously does not include bringing the demise of a chip nearer with

That sounds a bit like a performance counter to me, but it does raise an interesting question whether "idempotent" in the architectural sense is idempotent in a mathematical sense (i.e. operations are

Although I haven't seen any such implementation, I would imagine that a non-idempotent region that was, say, counting accesses to each address as a side-effect of each access may be a "benign" kind of