[coreboot] Why coreboot for riscv does not support multi-core?

[ron minnich]

On Fri, May 18, 2018 at 3:19 AM Jonathan Neuschäfer <j.neuschaefer at 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:
>
> 1. Implement the new SBI in coreboot, and keep launching the payload in
>    S-mode.
>
> 2. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180518/8d76fed4/attachment.html>