RISC-V privileged level walk

[Jim Kenua]

Hello,

I am working on a less formal definition/explanation of how privileged-level walking is working. (Spec: RISC-V Privileged Architectures V20211203)

As far ask the spec is saying we have 3 methods of changing the current privileged mode: 1) ECALL, 2) xRET Instructions, 3) Interrupts (medeleg, midelege)

1) ECALL:
Spec Definition: "The ECALL instruction is used to make a request to the supporting execution environment.
When executed in U-mode, S-mode, or M-mode, it generates an environment-call-from-U-mode
exception, environment-call-from-S-mode exception, or environment-call-from-M-mode exception,
respectively, and performs no other operation."

Spec Notes: "ECALL generates a different exception for each originating privilege mode so that environment
call exceptions can be selectively delegated. A typical use case for Unix-like operating systems is
to delegate to S-mode the environment-call-from-U-mode exception but not the others."

Therefore the ECALL can make a change from a Privileged Mode like M to S with support from "medeleg" & "medeleg"?
Then what is the purpose of bits 14:12 (Privileged Spec - Page 46) that are noted with PRIV?
Should these bits hold the value in current privileged mode and if they don't should this instruction generate an Illegal Instruction Trap?  
Should these bits have the value of the privileged mode to whom the instruction could generate a jump without the use of delegation?


2) MRET / SRET / URET:
Spec Definition: "To return after handling a trap, there are separate trap return instructions per privilege level,
MRET and SRET. MRET is always provided. SRET must be provided if supervisor mode is
supported, and should raise an illegal instruction exception otherwise. SRET should also raise an
illegal instruction exception when TSR=1 in mstatus, as described in Section 3.1.6.5. An x RET
instruction can be executed in privilege mode x or higher, where executing a lower-privilege x RET
instruction will pop the relevant lower-privilege interrupt enable and privilege mode stack."

What is the purpose of bits 14:12 (Privileged Spec - Page 47) that are noted with PRIV?
When executing an xRET instruction in a mode, the xRET instruction will always change the current privileged mode the mode written in the xPP register? (EX: current privileged mode is M, MRET will change the current privileged mode to the mode written in MPP)
Therefore an SRET cant go from a mode like S to M?
MRET can be executed in S mode and it will use the configuration from mstatus, but SRET can not be used in M mode?


3) Interrupts (medeleg, mideleg):
Spec Definition: "By default, all traps at any privilege level are handled in machine mode, though a machine-mode handler can redirect traps back to the appropriate level with the MRET instruction (Section 3.3.2).

To increase performance, implementations can provide individual read/write bits within medeleg and mideleg to indicate that certain exceptions and interrupts should be processed directly by a
lower privilege level. The machine exception delegation register (medeleg) and machine interrupt delegation register (mideleg) are MXLEN-bit read/write registers.

In systems with S-mode, the medeleg and mideleg registers must exist, and setting a bit in medeleg or mideleg will delegate the corresponding trap, when occurring in S-mode or U-mode, to the S-
mode trap handler. In systems without S-mode, the medeleg and mideleg registers should not
exist.

When a trap is delegated to S-mode, the scause register is written with the trap cause; the sepc register is written with the virtual address of the instruction that took the trap; the stval register is written with an exception-specific datum; the SPP field of mstatus is written with the active privilege mode at the time of the trap; the SPIE field of mstatus is written with the value of the SIE field at the time of the trap; and the SIE field of mstatus is cleared. The mcause, mepc, and mtval registers and the MPP and MPIE fields of mstatus are not written."

Therefore, each delegate trap will write inside SPP of mstatus the current privileged mode (the mode that was active prior to the trap)?
Since each trap normally goes back to M mode then unless it is delegated to the appropriate privileged mode, from each mode a trap can change to any other mode?

These might be very wrong assumptions, but unfortunately, I couldn't find a specific explanation on how to walk from mode to mode, these might exist but I didn't find them.

I would appreciate a lot some clarifications, if possible.

Thank you all!

Best regards,
JK 

[Greg Favor]

Regarding #1 and #2, 'PRIV' represents an encoding constant (just as 'ECALL' and 'SYSTEM' represent encoding constants).  See the instruction encodings in Unpriv chapter 26.

Regarding #3:

 

Therefore, each delegate trap will write inside SPP of mstatus the current privileged mode (the mode that was active prior to the trap)?

In general (not just for delegated traps), the spec (3.1.6.1) says: When a trap is taken from privilege mode y into privilege mode x, xPIE is set to the value of x IE; x IE is set to 0; and xPP is set to y.

 

Since each trap normally goes back to M mode then unless it is delegated to the appropriate privileged mode, from each mode a trap can change to any other mode?

The spec says: When executing an xRET instruction, supposing xPP holds the value y, x IE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1; and xPP is set to the least-privileged supported mode (U if U-mode is implemented, else M).

 

So yes, whatever is in xPP becomes the new privilege mode.

Greg

[Jim Kenua]

Hello Greg,

Thank you very much for your reply!

Just to make sure I understood, it would be really bad to teach the wrong information.

Inside mstatus MPP[1:0] can hold any privileged mode, SPP[0:0] can hold just S or U modes, and there is no UPP since this is the lowest privileged mode and we can't return to a higher privileged mode using a lower privileged return.

xRET:

- When SRET is executed should SPP bit from both mstatus and sstatus change?
- MRET can be executed in any mode, SRET just in S mode or U mode, URET just in U mode?
- MRET can walk M, S, or U, SRET can walk S, or U, URET just U mode? (walk -> move between, from/to)
- SRET will not affect MPP bits, just MRET? Each xRET changes just the xPP bit, MRET -> MPP, SRET -> SPP, URET -> None (lower privileged mode)?
- On xRET the jump PC will be xEPC.

ECALL:

- There is only 1 encoding for ECALL (the one from unprivileged spec)?
- ECALL will trigger a normal trap that can be delegated, unless it is delegated it will be changed to M mode and executed there?
- To delegate the ECALL bits 8, 9, 11 from medeleg will enable ECALL delegation, these bits will make the ECALL mode agnostic, eg. the bit 9 is set all the ECALLs will jump to S mode?

Thank you very much!

Best regards,
JK

[Greg Favor]

On Mon, Jul 10, 2023 at 12:08 AM Jim Kenua <jimk...@gmail.com> wrote:

Hello Greg,

Thank you very much for your reply!

Just to make sure I understood, it would be really bad to teach the wrong information.

Inside mstatus MPP[1:0] can hold any privileged mode, SPP[0:0] can hold just S or U modes, and there is no UPP since this is the lowest privileged mode and we can't return to a higher privileged mode using a lower privileged return.

xRET:

- When SRET is executed should SPP bit from both mstatus and sstatus change?

This follows from section 3.1.6 saying " A restricted view of mstatus appears as the sstatus register in the S-level ISA." and 5.1.1 saying "In a straightforward implementation, reading or writing any field in sstatus is equivalent to reading or writing the homonymous field in mstatus."

- MRET can be executed in any mode, SRET just in S mode or U mode, URET just in U mode?
- MRET can walk M, S, or U, SRET can walk S, or U, URET just U mode? (walk -> move between, from/to)
- SRET will not affect MPP bits, just MRET? Each xRET changes just the xPP bit, MRET -> MPP, SRET -> SPP, URET -> None (lower privileged mode)?
- On xRET the jump PC will be xEPC.

Yes.  These all should follow from the descriptions of these fields. 

ECALL:

- There is only 1 encoding for ECALL (the one from unprivileged spec)?

Yes.

 

- ECALL will trigger a normal trap that can be delegated, unless it is delegated it will be changed to M mode and executed there?

Yes, as stated by the spec when it says "By default, all traps at any privilege level are handled in machine mode ..." 

- To delegate the ECALL bits 8, 9, 11 from medeleg will enable ECALL delegation, these bits will make the ECALL mode agnostic, eg. the bit 9 is set all the ECALLs will jump to S mode?

Yes.

Greg 

[Jim Kenua]

Hello Greg,

Thank you very much for clarifying these!

Best regards,
Alin

[Allen Baum]

Hmm, URET no longer exists, does it?

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BQh7T%3DZafB6rk3s8Cz4vhZ%2B3mqS9h2foqORJbdCtJmJCR_xhw%40mail.gmail.com.

[Greg Favor]

On Mon, Jul 10, 2023 at 3:18 PM 'Allen Baum' via RISC-V ISA Dev <isa...@groups.riscv.org> wrote:

Hmm, URET no longer exists, does it?

Yes in that it never officially existed as a ratified instruction.

 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DDBmTO34z0yLQh2eHEr5Y2fv%3DG1zq%3DJqfF%3DadYM%3DFG91w%40mail.gmail.com.

[Greg Favor]

On Mon, Jul 10, 2023 at 3:50 PM ALin Parcalab <alinpa...@gmail.com> wrote:

Good question, I was wondering why the U mode was moved out of the privileged spec, is URET no longer supported?

U-mode is an unprivileged privilege level.  All unprivileged architecture extensions go into the Unprivileged ISA manual.

Separately, the extension that defined URET was a draft extension that was never ratified, and there is no current intention to complete it and ratify it (hence its removal from the ISA manuals).

Greg

 

Would it be improper to ask for a DFD-like representation of privileged routines? (like mode changes, interrupts, virtual memory, etc...)
Is there any available on the Internet?

Best regards,
JK