When an application (such as `hello.c`) runs for the first time, it is executed in machine mode.

[weiso131]

Add the following function to hello.c:

static inline uint32_t read_csr_mstatus(void){
    uint32_t x;
    __asm__ volatile ("csrr %0, mstatus" : "=r"(x));
    return x;
}

Then, modify the printf statements in task0, task1, and task2 as follows:

printf("[task %d %ld], mstatus: %x\n", mo_task_id(), cnt++, read_csr_mstatus());

The result:

Linmo kernel is starting...
Heap initialized, 130012200 bytes available
task 1: entry=800001c0 stack=80002c48 size=4096 prio_level=4 time_slice=5
task 2: entry=80000204 stack=80003cfc size=4096 prio_level=4 time_slice=5
task 3: entry=8000017c stack=80004d7c size=4096 prio_level=4 time_slice=5
task0 has id 1
task1 has id 2
task2 has id 3
Scheduler mode: Preemptive
[task 1 100000], mstatus: 1808
[task 2 200000], mstatus: 1808
[task 3 300000], mstatus: 1808
[task 1 100001], mstatus: 88
[task 2 200001], mstatus: 88
[task 3 300001], mstatus: 88
[task 1 100002], mstatus: 88
...

According to The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, section 3.1.6 Machine Status Registers (mstatus and mstatush), the MPP field has a value of 11, which corresponds to M-mode.
It can be observed that during the first execution, any task has machine mode privilege, and only afterwards does it return to user mode.
This means that any task at startup can directly affect the execution of other tasks — for example, by modifying mstatus to disable interrupt enabling — which raises security concerns.

/* This causes task0 to never be preempted. */
void task0(void)
{
    int32_t cnt = 100000;

    while (1) {
        __asm__ __volatile__(
            "li      t0, 0x1800\n"
            "csrw    mstatus, t0\n"
        );
        printf("[task %d %ld], mstatus: %x\n", mo_task_id(), cnt++, read_csr_mstatus());
    }
}

In hal_context_init, CONTEXT_MSTATUS is explicitly set to MSTATUS_MPP_MACH, so this situation might have been intentional.
However, doesn’t doing so defeat the purpose of distinguishing between machine mode and user mode?

[Mes0903]

Hi @weiso131 ,

This is an nice question. First, this process has always been running in M-mode. An easy way to tell is that it can still read mstatus; if it were in U-mode, that would raise an illegal-instruction trap. For convenience in implementation and debugging, all of our code is currently written to run in M-mode.

As for seeing U-mode in mstatus, let me explain a little bit about it. The RISC-V privileged spec, section “3.1.6.1. Privilege and Global Interrupt-Enable Stack in mstatus register,” says:

An MRET or SRET instruction is used to return from a trap in M-mode or S-mode respectively. When executing an xRET instruction, supposing xPP holds the value y, xIE 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). If y≠M, xRET also sets MPRV=0.

In other words, suppose there are two M-mode tasks, A and B, that switch between each other:

1. A is running in M-mode → a timer interrupt occurs.
   Hardware does: mstatus.MPP ← M, mepc ← A.pc, and enters the M-mode trap handler.

2. The scheduler switches to B (also M-mode).
   The kernel restores B’s registers and sets:

   • mepc ← B.pc
   • mstatus.MPP ← M (usually already M, or set to M by hardware on trap)

   Then it executes mret → returns to B.pc in M-mode.
   After mret completes, per the spec quoted above, MPP is cleared to the least-privileged mode (U here), which is why you see mstatus showing U-mode. But at that moment the CPU is already executing B in M-mode.

3. If another interrupt occurs later,
   the hardware again sets mstatus.MPP to the current privilege level (M), so the next mret will still return to M; it won’t drop to U.

Finally, in RISC-V there is no way for code to directly get the privilege level it is currently executing at; if there were, it would constitute a virtualization hole.