On Fri, May 18, 2018 at 3:19 AM Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Fri, May 18, 2018 at 11:46:54AM +0800, 王翔 wrote: [...]
Is coreboot's payload a bootloader running in m-mode ? If not, how does the SBI interrupt service be implemented ?
Previously, coreboot implemented the SBI, and launched the payload in S-mode. The SBI implementation implemented the old version of the SBI (a page mapped at a certain virtual address), so I removed it in commit 3ca8b598ed ("arch/riscv: Remove the current SBI implementation")[3]. The payload is still launched in S-mode, because noone has changed that.
So the new version of the SBI needs to be implemented.
There are two options:
Implement the new SBI in coreboot, and keep launching the payload in S-mode.
Implement the new SBI in a payload or some other kind of module, akin to ARM Trusted Firmware[1] or bbl[2]; Launch the code that implements the SBI in M-mode.
What I'd still most prefer: make the M mode code part of the kernel, so we avoid the temptation vendors will feel to re-implement SMM on RISCV. There were proposals in the ARM community to reimplement SMM on ARM; luckily those died.
So I'd much rather see the payload starting in M mode, and owning M mode, for maximum control. There's no reason for coreboot to include the M mode code. If the payload (e.g. Linux) owns the M mode code, then it's easy to fix M mode bugs: load a new kernel. Further, it's easier to ensure SMM never happens on RISCV. Finally, it makes it far easier to improve SMP startup over time.
ron