1. Messages
  2. comments on PMP enhancements

Re: comments on PMP enhancements

Greg Favor
 

It seems like the current trade-off in supported use cases is due to the combination of two constraints: backward compatibility and avoiding use of a Reserved PMP bit.  A year ago the exact degree of this trade-off may not have been obvious, but at this point adopting this new spec would then just lead to development of a PMPv3 spec that addresses the unaddressed use cases and uses a Reserved bit - thus still ending up architecturally at the place that the current spec tries to avoid.  (And tbd how easily that spec could maintain full backward compatibility with this spec.)

The key question is whether it is better to evolve/expand the current spec into what it ultimately wants or needs to be, or to follow a two-step approach (that architecturally, at least to me, seems messy)?  If we're only putting off using a Reserved bit for half a year or a year, let's just cleanly move to that architectural solution directly.

Greg

On Wed, Feb 12, 2020, 4:42 AM Joe Xie <joxie@...> wrote:
For 4..

As we discussed in the meeting we agree with the use case, lock is existing in current PMP.

The current PMP enhancement proposal tries to be back compatible and thus does not try to address this issue.

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On Behalf Of John Hauser
Sent: Wednesday, February 12, 2020 12:49 PM
To: tech-privileged@...; tech-tee@...; Nick Kossifidis <mick@...>
Subject: Re: [RISC-V] [tech-privileged] comments on PMP enhancements

External email: Use caution opening links or attachments


I wrote:
> 2.
> As Jonathan Behrens has already noted, some systems depend on being
> able to set mstatus.MXR = 1 temporarily to read S/U-executable
> instructions, for emulation purposes.  The proposal should be modified
> to say that any S/U-mode-only PMP region that grants execute
> permission to S/U modes (bit X is set), implicitly grants read
> permission to M mode when MXR = 1.

Correction:  I believe that should say "... implicitly grants read permission to S/U modes when in M mode and MXR = 1".  This is relevant only when MPRV = 1 and MPP = 0 or 1, so it's a rather narrow case.
Hopefully I've got it right this time.

    - John Hauser



-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.