which CSR holds current privilege mode ?

[Karthik Punukollu]

Seeking for some clarification on current privilege mode 

As per the privileged arch spec ,  based on what is described in MPRV usage that allows to do data accesses from other(prior to trap) mode .. the MPP[2] bits in  mstatus CSR  are written with originating mode at the boundary of entry/exits in M mode but not the mode we are going in to .. not sure if those get updated at the exit/MRET . On top of it there are vertical and horizontal traps , I am assuming these bits alone cannot determine the current mode .. 

In other words, Which CSR has the current privilege mode that the machine is running in ? Is there a specific CSR bit that gets written with the "mode that it is entering into " at the transition of privilege modes. Or do we have to use combination of mcause and mstatus to get the current mode

This is what I am referring to from the spec .

3.1.6.3 Memory Privilege in mstatus Register
The MPRV (Modify PRiVilege) bit modifies the effective privilege mode, i.e., the privilege level at which loads and stores execute. When MPRV=0, loads and stores behave as normal, using the translation and protection mechanisms of the current privilege mode. When MPRV=1, load and store memory addresses are translated and protected, and endianness is applied, as though the current privilege mode were set to MPP. Instruction address-translation and protection are unaffected by the setting of MPRV. MPRV is read-only 0 if U-mode is not supported.

An MRET or SRET instruction that changes the privilege mode to a mode less privileged than M also sets MPRV=0.

Appreciate the help

Thanks,

--Karthik

[Andrew Waterman]

The current privilege mode is not directly readable in a CSR.  We chose this design because it's the easiest way to close a virtualization hole.  (Software running within a VM should not be allowed to determine the actual privilege mode.)

Most RISC-V software should be written to assume a specific mode, rather than making decisions based on what the current mode happens to be.

--
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/5704410b-3084-46d3-aa0f-b3030c8061cen%40groups.riscv.org.

[Samuel Falvo II]

I remember asking this same question years ago, and Andrew gave me an
answer which was different, and which I think should be included here
for completeness. His answer then does not negate what he wrote
previously.

Andrew wrote above, "Most RISC-V software should be written to assume
a specific mode, ...". Note that you always know which privilege mode
you're currently running in (virtualization notwithstanding) based on
which trap has been taken. For example, any trap handler pointed at
by mtvec (or one of its interrupt vectors, if you're running with
vectored interrupts) must necessarily be running in machine-mode.
Likewise, any handler pointed at by stvec must be running in
supervisor mode, etc.

If you need to have a common procedure shared by a number of different
privilege mode trap handlers, you can explicitly set a variable as
part of each privilege mode entry point before dispatching to the
common handler.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0AR75_n2k9yaz7ySQTMAkLtPTMd-RCZF7UCVT1Y0jCKoQ%40mail.gmail.com.



--
Samuel A. Falvo II

[Karthik Punukollu]

Thanks Andrew/Samuel for the quick responses. 

I am talking more from HW perspective , how does HW know which code (U,M etc..) that it is running , Is everyone need to have their own implementation choice (be it adding custom CSR that gets updated at the privilege mode transition  or maintain the state in HW to track current mode). 

Looks like there are cases where we are defining the traps based on the current mode, for example the trapping SRET when mstatus.TSR=1 while executing in Smode, not sure if it is intended to trap all SRETs or only while running in S-mode . What if we are in M-mode and encountered an SRET etc.. Technically , we can have xRET when x<current privilege mode

Section 3.1.6.5

The TSR (Trap SRET) bit is a WARL field that supports intercepting the supervisor exception
return instruction, SRET. When TSR=1, attempts to execute SRET while executing in S-mode
will raise an illegal instruction exception. When TSR=0, this operation is permitted in S-mode.
TSR is read-only 0 when S-mode is not supported

Any guidance is greatly appreciated, just looking to leverage before we seek customizations/extensions for our use cases where we need to differentiate the code running in U-mode vs M-mode in HW 

Thanks,

--Karthik

[Karthik Punukollu]

Just a clarification that we chose to support only Bare mode with no translation and protection supporting only two levels (U-mode and M-mode) that are in two different virtual address spaces  , thus relying on Physical page attributes wont work here and it is beyond the scope of this core 

Thanks,

--Karthik

[K. York]

You could choose to think of it as a hidden CSR with no numeric address if you want.

If you're only implementing M and U mode, you only need 1 bit (vs 2 bits for S-mode, 3 bits for H-extension support) to store the current privilege mode. This flexibility in internal representation is why the current mode isn't explicitly exposed anywhere.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/9dae1156-ed35-4360-91f7-e420161507d1n%40groups.riscv.org.

[Allen Baum]

First: from a spec point of view, the current mode aremicroarchitectural state bit sthat is only indirectly accessible

(that is, you can try something that isn't allowed in some mode and see that it traps). 

And, even that doesn't work if the higher privileged mode trap handler fakes the result - which is precisely what virtualization does, and the primary reason for keeping it hidden, exactly as Andrew stated.

You could make it readable in a custom CSR, but best practice is to keep it hidden to avoid abuse.

Standard OS distributions should never need to read it (as evidenced by all the RISC-V implementations out the booting all kinds of OSes)

From the spec extract you quoted, executing SRET in S-mode with TSR=1 will trap.

But, executing SRET in U-mode will also trap, regardless of TSR,  since SRET requires at least S-mode privileges to execute.

Executing SRET in M-mode will not trap regardless of TSR; it just returns to where the last entry into S-mode came from

( as opposed to returning to where the entry into the M-mode handler came from).

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CABeNrKV2ajsSEEHX2amY7tKZdZmAw97D7BWa2CRtpHN6DvXrRQ%40mail.gmail.com.

[Karthik Punukollu]

Thanks Allen and York for responses. 

Yes, I was planning to choose internal CSRs which are updated at the boundary mode entry/exit conditions(ECALL, xRET, exceptions, interrupts etc..)  which are just written and read by HW but not accessible by Software. 

Allen, 

Thanks for the detailed write up . In regards to "SRET trap with TSR" that I quoted , I did comprehend the same way as you described. I was just hoping from the way it was spec'd out , that if the trap conditions are architecturally defined based on current mode (Trap on SRET only in Smode if TSR=1)  , so I thought the current mode would be an architectural state instead of a microarchitectural state. I am not denying or advocating to have the current mode to be architecturally visible  . I was just trying to avoid extra work in tracking this as a micro-architectural state, if it can be deduced from one or more CSRs :)  .. That's all. 

But, I think I got all answers I was looking for

Thanks a lot, It was very helpful 

--Karthik

--

KARTHIK PUNUKOLLU