allenjbaum
commented
1 year ago Don't get me started on WARL fields.... But, there are numerous examples in the spec where non-normative text says that you should determine what is legal by writing a specific value, and then reading it back - and that applies here also. SW that writes ANY WARL field should always check that the value written was actually written. Essentially, the check is implemented in SW by an explicit CSR read-compare-branch, and not in HW by trapping. This is not a heavy burden, as CSRs are not often written.
And I would say that changing that aspect of the spec is very unlikely to occur. Note that WLRL fields are allowed to (but not required to) raise an illegal instruction exception There are very few WLRL fields defined in the spec (only xcause.EXC, and hstatus.VGEIN), and I'm not sure why those a called out separately)
On Wed, Dec 7, 2022 at 2:19 AM JJ-Gaisler @.***> wrote:
Hi!
I have a question regarding how WARL should be treated for the address matching field (A) in a PMP entry. The specification allows for an implementation specific PMP granularity and it also states that if the granularity > 0 then NA4 is not selectable. Not selectable is something I interpret as not being legal, is this correct? If the granularity > 0 and NA4 is written to a configuration, what should the read legal value be?
For some background, I came across this issue when comparing our RTL implementation which defaults to A = OFF, while Imperas OVPsim in the same case ignores the write to the A field. In this case the previous A value was TOR and this could have unexpected consequences since the meaning of PMP-addresses are quite different between TOR and NA4/NAPOT and thus one may intentionally grant permission to non-intended memory areas. Defaulting to OFF has some issues too, since a memory region which permissions were supposed to be granted, were not granted access. As some CPUs support a granularity of zero, testing PMP software on such CPUs could more easily miss the handling/checking of illegal configurations, and thus when deployed may cause memory protection issues.
What's the rationale for not taking an exception on an incorrectly written pmpcfg? Since PMP is a memory protection mechanism I would personally prefer it to fail loudly instead of silently. Could such an exception perhaps be added in a future standard?
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/933, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUNP6733ZY7NYQ6LZ3WMBQCFANCNFSM6AAAAAASWTXAV4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hi!
I have a question regarding how WARL should be treated for the address matching field (A) in a PMP entry. The specification allows for an implementation specific PMP granularity and it also states that if the granularity > 0 then NA4 is not selectable. Not selectable is something I interpret as not being legal, is this correct? If the granularity > 0 and NA4 is written to a configuration, what should the read legal value be?
For some background, I came across this issue when comparing our RTL implementation which defaults to A = OFF, while Imperas OVPsim in the same case ignores the write to the A field. In this case the previous A value was TOR and this could have unexpected consequences since the meaning of PMP-addresses are quite different between TOR and NA4/NAPOT and thus one may intentionally grant permission to non-intended memory areas. Defaulting to OFF has some issues too, since a memory region which permissions were supposed to be granted, were not granted access. As some CPUs support a granularity of zero, testing PMP software on such CPUs could more easily miss the handling/checking of illegal configurations, and thus when deployed may cause memory protection issues.
What's the rationale for not taking an exception on an incorrectly written pmpcfg? Since PMP is a memory protection mechanism I would personally prefer it to fail loudly instead of silently. Could such an exception perhaps be added in a future standard?