wfi instruction with global interrupts disabled

[biosbob]

the risc-v instruction set manual states that WFI can be executed with global interrupts disabled.... the neorv32 datasheet, however, requires that global interrupt flag in the mstatus register has to be set....

when implemented a task scheduler (as i am), the kernel will typically disable global interrupts which (atomically) manipulating its internal data structures.... if no task is ready to run, the kernel will "idle" by executing WFI....

other CPUs (eg., Arm) will define the WFI instruction to enable global interrupts before waiting -- or else returning immediately if some interrupt is already pending.... the point here is that this is all happening atomically; there is no window of vulerability between enabling global interrupts and executing WFI....

in the case of the risc-v WFI, our kernel would executing this instruction with interrupts disabled.... as per the spec, the PC will advance to the next instruction once some interrupt if pending.... in my implementation, i'll conditionally enable global interrupts if mip is non-zero; the ISR(s) will then execute on mstatus has been written....

i suspect this is a trivial change to the RTL; and it certainly wouldn't impact any of the software examples, as this new implementation is more permissive....

but am i missing something????

[stnolting]

Hey there!

the neorv32 datasheet, however, requires that global interrupt flag in the mstatus register has to be set....

Well, it is not actually "required" - but without interrupts there is no way to wake up the CPU again.

By the way, the term "global interrupt" flag is a bit misleading in the NEORV32 documentation... If mstatus.mie is cleared, interrupts are globally disabled when the CPU is in machine-mode. When the CPU is in user-mode, interrupts are always globally enabled - even if mstatus.mie is zero.

when implemented a task scheduler (as i am), the kernel will typically disable global interrupts which (atomically) manipulating its internal data structures.... if no task is ready to run, the kernel will "idle" by executing WFI....

I am not sure if I really understand your setup.

When the scheduler disables all interrupts the "tick" timer interrupt, which is required for a context/task change, is also disabled, isn't it? 🤔

[biosbob]

my understanding is that waking the CPU from sleep occurs when corresponding bits are set in the mie and mip registers; that's what WFI is waiting for, and should cause the CPU to dispatch the next instruction.... if mstatus. mie is set, this would be the first instruction of the appropriate ISR; but if mstatus.mie is clear, then execution proceeds with the instruction following the WFI....

every other RISC-V CPU i've used has had this property (for example).... again, this seems counter-intuitive -- hence your question about missing a timer interrupt....

per the RISC-V spec, WFI is conceptually a NOP; and in fact you can implement a polling wait loop by simply checking mip + mie for a newly pending (enabled) interrupt.... this works even if mstatus.mie is 0 !!!!!

in determining the next task to run, the schedule will clear mstatus.mie before checking and updating its internal data structures.... in the case where no task is ready to run (and we want to wait for a future event triggered by the arrival of some mie-enabled interrupt), we certainly want to execute the WFI instruction....

but even if we set mstatus.mie immediately before the WFI instruction, there is small window of vulnerability; the expected interrupt (perhaps a one-shot event) could arrive before we dispatch WFI; and since we can't assume another interrupt might ever arrive, we're potentially deadlocked!!!!

instead, we use WFI to wait for a pending interrupt to arrive -- after which we can immediately set mstatus.mie and execute the ISR....

[stnolting]

Ah ok, now I understand what you mean.
The expected behavior of WFI for the situation you've described makes perfect sense.

my understanding is that waking the CPU from sleep occurs when corresponding bits are set in the mie and mip registers; that's what WFI is waiting for, and should cause the CPU to dispatch the next instruction
[...]
instead, we use WFI to wait for a pending interrupt to arrive -- after which we can immediately set mstatus.mie and execute the ISR....

I think you might be right here. Maybe I misunderstood that part of the RISC-V spec... 🙈 I'll check that again and then do a PR to fix this.

[stnolting]

You are right! There is a bug in the WFI implementation.
Thanks for discovering! 👍

-> #583