On Fri, Dec 20, 2019 at 7:04 PM Greg Favor <gfavor@...
<mailto:gfavor@...>> wrote:

This all looks very good, except for one issue with item 3b: "Adding
a new PMP rule with pmpcfg.L and pmpcfg.X bits set fails with
Security exception."

RISC-V architecture - rather nicely - currently avoids having any
"register-operate" instructions that cause architectural exceptions
based on data-dependent execution (e.g. based on the value of its
register operands).  Currently all computational instructions and
CSR rd/wr instructions conform to this.  In contrast, item 3b
violates this and would represent the first and only case in
which implementations have to signal an exception on a
"register-operate" instruction at execution time (versus based on
what can be checked at decode time).


Although I still haven’t grokked the proposal, I can say I agree with
your line of reasoning. This use case doesn’t justify crossing the
Rubicon of data-dependent traps. Your proposed solution below sounds
more consistent with both the PMP spec and the broader philosophy.