WFI Illegal in User Mode

[chadzy]

3.3.3 Wait for Interrupt
The Wait for Interrupt instruction (WFI) provides a hint to the implementation that the current
hart can be stalled until an interrupt might need servicing. Execution of the WFI instruction
can also be used to inform the hardware platform that suitable interrupts should preferentially be
routed to this hart. WFI is available in all privileged modes, and optionally available to U-mode.
This instruction may raise an illegal instruction exception when TW=1 in mstatus, as described
in Section 3.1.6.5.

The platform I am running on allows WFI to execute in usermode without an exception, but there is no flag in OVPsim to allow this.
`
Info 27735: 'riscvOVPsim/cpu', 0x00000000012649f6(snippet_id_8_start_SNP_ISA_WFI_run_block0_3_8_0_hv_0): User 10500073 wfi
Warning (RISCV_UDM) CPU 'riscvOVPsim/cpu' 0x012649f6 10500073 wfi: Illegal in User mode
Info mstatus 00000088 -> 00000080
Info mepc 0126332c -> 012649f6
Info mcause 00000008 -> 00000002

`

Is there a way to avoid trapping on WFI in user mode?

Thank you

[chadzy]

Note: This is showing up with --override riscvOVPsim/cpu/wfi_is_nop=T
Would it make sense to disable this wfi trap when this flag is set?

[duncangraham-Imperas]

I have investigated what you are asking.
In the specification it states that in User mode the wfi will cause an exception unless it completes within an implementation-specific bounded time limit.
We model a time limit of 0 for the wfi to complete; which is a legal implementation choice.
This means that wfi in U mode will always cause an exception.
What is the time limit for the User mode wfi for your implementation?

[chadzy]

@duncangraham-Imperas The implementation that I am working on has implemented WFI as a NOP, so I do not believe that the instruction should cause a trap even with a time limit equal to 0.

The implementation I am working on has TW (Timeout Wait in mstatus) set to read only 0, so the time limit equal 0 should not apply from what I understand.

The TW (Timeout Wait) bit is a WARL field that supports intercepting the WFI instruction (see
Section 3.3.3). When TW=0, the WFI instruction may execute in lower privilege modes when
not prevented for some other reason. When TW=1, then if WFI is executed in any less-privileged
mode, and it does not complete within an implementation-specific, bounded time limit, the WFI
instruction causes an illegal instruction exception. The time limit may always be 0, in which case
WFI always causes an illegal instruction exception in less-privileged modes when TW=1. TW is
read-only 0 when there are no modes less privileged than M.

[chadzy]

WFI
WFI will halt the processor until an interrupt occurs. It can instead be configured as a NOP using parameter "wfi_is_nop". WFI timeout wait is implemented with a time limit of 0 (i.e. WFI causes an Illegal Instruction trap in Supervisor mode when mstatus.TW=1).
https://www.ovpworld.org/library/wikka.php?wakka=RiscvRV32FreeRTOS

According to OVPsim's webpage, the overall understanding aligns with the RISC-V Architecture sections that I have provided in the original post and the message prior to this.
However, the implementation does not seem to line up

[chadzy]

The platform I am operating on is compliant to the 1.12 version of the privilege architecture.

If you disagree with WFI should not result in a trap when operating in User Mode and TW=0, could you provide the privilege architecture version and a quote for your understanding?

[chadzy]

It seems ilke if --override riscvOVPsim/cpu/wfi_is_nop=T, the time limit=0 should not cause a trap since a NOP should not affect the system's state.

The NOP instruction does not change any architecturally visible state, except for advancing the
pc and incrementing any applicable performance counters. NOP is encoded as ADDI x0, x0, 0.
RISC-V Unprivileged Arch 2.4

Is this a possible update?

[duncangraham-Imperas]

After some internal discussion regarding your comments we believe that our initial interpretation of the privilege specification for WFI may not be correct for all conditions.
We now believe that if S-mode is absent or disabled then WFI in User mode is legal if mstatus.TW=0. If S-mode is present then it is not legal (or at least must complete within a "bounded time", which we model as 0).
I think this change, that we will make available in a future release, satisfies your requirement.
Thank you for the feedback.
I will discuss you final comment and see if this also requires an update.

[duncangraham-Imperas]

Please could you let us know if your implementation includes supervisor mode and if this is enabled when the WFI instruction is executing?

[chadzy]

Our implementation does not include Supervisor mode