3 ms·
>"Each mode has a different ecall cause. If we make an ecall in machine mode (the most privileged mode), we get cause #11. Otherwise, if we make an ecall in sup
by bogomipz 7y ago
>"Each mode has a different ecall cause. If we make an ecall in machine mode (the most privileged mode), we get cause #11. Otherwise, if we make an ecall in supervisor mode (typically the kernel mode), we get cause #9."
Could someone say if the kernel runs in Supervisor mode what is the intention of machine mode in RISC-V?
- monocasa 7y agoStuff like "this board/chip needs real time response in order to not melt itself despite not being able to trust that the OS is hard real time" like System Management Mode was originally intended. It's also been handy for trying out supervisor mode concepts and adding software based support on chips that don't support all the features like hypervisor extensions.
- andrekandre 7y agoright, afaiui basically you can trap on unimplemented instructions and emulate risc-v extensions without hardware support (very cool imho) this short video explained it well (to me anyways): https://www.youtube.com/watch?v=4JIvnWEs_pA https://www.youtube.com/watch?v=4JIvnWEs_pA (hypervisor trap explanation at 11m20s mark)
- muricula 7y agoMachine mode is the equivalent of el3 on arm. That's where processor firmware tends to run. There is no paging and very little in the way of security boundaries or seatbelts.
- FullyFunctional 7y agoIt was supposed to be where vendors can patch up differences and provide platform bindings. The (standard) Linux kernel expects to be started in S mode and doesn’t include M mode code. OpenSBI is an example of template firmware that belongs in M mode, not OSes.