Nick,

For security reasons, PMP exceptions will almost always be handled in
M-mode. sPMP exceptions typically want to be handled in S-mode. I
don't think it ever makes sense to have the two types routed to the
same exception code. So that seems out to me.

I don't think it ever makes sense to handle PMP access faults in
S-mode. It's the wrong privilege level (and S-mode can't write the
PMP either).

If we don't allow sPMP and paging at the same time, then the two can
use the same exception codes. Perhaps the only issue is the name.
The name "page fault" doesn't seem to fit with an sPMP exception. If
that's the issue, then let's see if we can solve that.

I'm going to push back against the proposal to allocate new cause
values for sPMP faults. Allocating new cause values has knock-on
effects and incremental costs throughout the architecture (with
respect to virtualization and delegation, in particular), and so the
bar for adding new ones needs to be set high.

Many of us do not believe that composing sPMP and paging is an
essential use case to support--and, in fact, some of us would prefer
the architectural economy of disallowing their composition. Even if
we do support it, software has sufficient information to distinguish
sPMP faults from page faults. The process is indeed cumbersome, as
y'all have discussed. But it need not be a performance sink--first of
all, because this isn't a common case, and second, because the checks
can be performed almost entirely off the critical path. (The sPMP
checks only need to be performed if the paging subsystem determines
the fault shouldn't have occurred--similar to Linux's existing
handling of spurious page faults due to lazy shootdowns on upgrades.)

Hi privileged group,

The TEE group are proposing the sPMP mechanism for S-mode physical memory protection. (As linked below)

The TEE group discusses the proposal for quite a while, and we believe that to handle faults generated by sPMP graciously, add three new exception codes for sPMP seems to be reasonable.

sPMP follows the strategy that uses different exception codes for different cases. Currently, sPMP will generate load/store/instruction sPMP faults for memory load, memory store and instruction fetch, respectively.

Since we want to delegate sPMP fault to S-mode rather than handle it in M-mode as PMP did, we wonder whether it is possible to use three bits in the medeleg register.

Please refer to section 2.5 of the sPMP proposal.

Link to the sPMP proposal:
https://docs.google.com/document/d/1x7esOSBFfpcbDHaRPpe5NEWmav1_8der_nB25Hd5hqs/edit#heading=h.rdbq3ygwk878

Best, 
Bicheng

On Mar 23, 2021, at 10:53 PM, Scott Johnson <scott.johnson@...> wrote:

The spec has very strict requirements on which bits of hedeleg must be writable. (medeleg, not so much.) See Table 5.2: except for bit 10 (ecall from VS-mode) there is no implementation flexibility on the bits of hedeleg.



On Tue, Mar 23, 2021 at 09:58 PM, Greg Favor wrote:

On Mon, Mar 8, 2021 at 1:22 PM James Robinson <jrobinson@...> wrote:

I see that the list of hedeleg writable bits includes bits which are not writable in medeleg in the spike implementation (Illegal Instruction, Load/Store address misaligned, Load/Store/Inst Access Fault).

Is it intended that these bits should be writable even if they are not writable in medeleg, and that the writability the corresponding bits in medeleg remains an implementation choice?

In which case, some exceptions, although writable in hedeleg, will never actually be delegated to VS-mode by the hardware?

Is machine mode software expected (under certain circumstances) to emulate delegation of the exception by setting up the correct state and executing mret?

 

On Wed, Mar 10, 2021 at 3:23 AM James Robinson <jrobinson@...> wrote:

Pinging to see if any of the architects can chime in to clarify whether H-extension cores are supposed to have bits which are writable in hedeleg but not medeleg, as per the current spec?

 

 

I can't speak to how Spike's modeling of the architecture is intended to relate to all the functionality and options that are allowed within the full architecture.  (Andrew would be the one to provide useful commentary.)    But the above medeleg implementation in Spike is restricted wrt what is allowed by the architecture, so one should be careful about what inferences about the overall architecture one draws from that.  (Although, for what it's worth, hardwiring the above medeleg bits is reasonable and not surprising.)

 

But from an arch spec perspective:

 

What M-mode is "expected" to do for exceptions from lower privilege modes that it receives and doesn't delegate down, is a software choice (and not something to be specified by the architecture).  RISC-V architecture just tries to provide the flexibility to address a wide range of systems designs and software environments.

 

Within the few constraints specified for medeleg, bits can be implemented as hardwired or writeable (although for many systems there are sensible/preferable choices even though the arch spec doesn't require them).  Ditto for hedeleg.  And the two are architecturally orthogonal.  Although, of course, if a medeleg bit is hardwired to 0 in particular, then the implementation of the corresponding hedeleg bit is a don't care.  And an implementation could choose to support that, but probably would also hardwire the hedeleg bit to 0.

 

Ultimately this is all primarily a software architecture issue, and in a complete system M-mode and S/HS-mode software (along with the underlying hardware platform) have to behave in a coordinated manner.  Which will be different for different class systems.

 

Greg

 

On Mon, Mar 8, 2021 at 1:22 PM James Robinson <jrobinson@...> wrote:

I see that the list of hedeleg writable bits includes bits which are not writable in medeleg in the spike implementation (Illegal Instruction, Load/Store address misaligned, Load/Store/Inst Access Fault).

Is it intended that these bits should be writable even if they are not writable in medeleg, and that the writability the corresponding bits in medeleg remains an implementation choice?

In which case, some exceptions, although writable in hedeleg, will never actually be delegated to VS-mode by the hardware?

Is machine mode software expected (under certain circumstances) to emulate delegation of the exception by setting up the correct state and executing mret?

 

On Wed, Mar 10, 2021 at 3:23 AM James Robinson <jrobinson@...> wrote:

Pinging to see if any of the architects can chime in to clarify whether H-extension cores are supposed to have bits which are writable in hedeleg but not medeleg, as per the current spec?

 

 

I can't speak to how Spike's modeling of the architecture is intended to relate to all the functionality and options that are allowed within the full architecture.  (Andrew would be the one to provide useful commentary.)    But the above medeleg implementation in Spike is restricted wrt what is allowed by the architecture, so one should be careful about what inferences about the overall architecture one draws from that.  (Although, for what it's worth, hardwiring the above medeleg bits is reasonable and not surprising.)

 

But from an arch spec perspective:

 

What M-mode is "expected" to do for exceptions from lower privilege modes that it receives and doesn't delegate down, is a software choice (and not something to be specified by the architecture).  RISC-V architecture just tries to provide the flexibility to address a wide range of systems designs and software environments.

 

Within the few constraints specified for medeleg, bits can be implemented as hardwired or writeable (although for many systems there are sensible/preferable choices even though the arch spec doesn't require them).  Ditto for hedeleg.  And the two are architecturally orthogonal.  Although, of course, if a medeleg bit is hardwired to 0 in particular, then the implementation of the corresponding hedeleg bit is a don't care.  And an implementation could choose to support that, but probably would also hardwire the hedeleg bit to 0.

 

Ultimately this is all primarily a software architecture issue, and in a complete system M-mode and S/HS-mode software (along with the underlying hardware platform) have to behave in a coordinated manner.  Which will be different for different class systems.

 

Greg