Re: comments on PMP enhancements

Joe Xie

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:
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 { to automatically receive all group messages.