The current code does not set the stack pointer for hart alone. The Linux kernel runs in s-mode and cannot set the stack pointer for m-mode. If m-mode does not have a separate stack for hart, then m-mode cannot save any state about the current hart.
Is it necessary to initialize the stack pointer for each hart?
Looking forward to your reply. Thank you.
WangXiang
In short: Because it was easier to delay the problem until later.
On Thu, May 17, 2018 at 03:55:37PM +0800, 王翔 wrote:
The current code does not set the stack pointer for hart alone. The Linux kernel runs in s-mode and cannot set the stack pointer for m-mode. If m-mode does not have a separate stack for hart, then m-mode cannot save any state about the current hart.
Is it necessary to initialize the stack pointer for each hart?
Yes, I think this needs to be implemented.
Note also, that the new SBI based on the ecall instruction is not implemented in coreboot.
Jonathan Neuschäfer
In short: Because it was easier to delay the problem until later.
On Thu, May 17, 2018 at 03:55:37PM +0800, 王翔 wrote:
The current code does not set the stack pointer for hart alone. The Linux kernel runs in s-mode and cannot set the stack pointer for m-mode. If m-mode does not have a separate stack for hart, then m-mode cannot save any state about the current hart.
Is it necessary to initialize the stack pointer for each hart?
Yes, I think this needs to be implemented.
Note also, that the new SBI based on the ecall instruction is not implemented in coreboot.
Jonathan Neuschäfer
Is coreboot's payload a bootloader running in m-mode ? If not, how does the SBI interrupt service be implemented ?
WangXiang
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.
Jonathan Neuschäfer
[1]: https://github.com/ARM-software/arm-trusted-firmware/ [2]: https://github.com/riscv/riscv-pk/tree/master/bbl [3]: https://review.coreboot.org/cgit/coreboot.git/commit/?h=3ca8b598ed4ea16fd55d...
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
-
Jonathan Neuschäfer -
ron minnich -
王翔