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

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

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

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

> 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 >

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.

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

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 Andrew, That’s fine for me. Implementing 0 / 16 / 64 PMP entries is ok Tariq From: Andrew Waterman [mailto:andrew@...] Sent: 21 May 2020 17:50 To: Tariq Kurd <tariq.kurd@...> Cc:

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

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

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

This is not needed. We can easily probe number of PMP registers using illegal instruction traps. Look at latest OpenSBI sources. Regards, Anup From: tech-privileged@... <tech-privileged@...>On

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

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply. From: tech-privileged@... [mailto:tech-privileged@...]On Behalf Of Anup Patel Sent: Monday, May 25,

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

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

Thanks for this Andrew, it’s really useful. My only comment is: “Up to 64 PMP entries are supported. Implementations may implement zero, 16, or 64 PMP CSRs. All PMP CSR fields are WARL and

I see what you're getting at, but since some vendors will (rightly) choose to hardwire some PMP registers, the sentiment seems impractical to enforce.

I don’t think I understand the your comment, Andrew. I interpreted Tariq saying we essentially restrict RdOnly zero entries to always be the larger numbered ones. (Sort is the way that HartIndexes