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 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