Re: [PATCH 0/1] SBI: Introduce Physical Memory Protection Extension


atishp@...
 

On Tue, 2020-03-10 at 07:25 -0700, Bin Meng wrote:
S-mode software needs a way to know memory used by SBI firmware so
that it can correctly mark such memory as reserved.

This patch was already posted on github as a PR [1], and I was told
to send this patch to this mailing list for broader discussion.

For details on why and possible solutions to debate, please visit
the github PR. Comments are welcome!

[1] https://github.com/riscv/riscv-sbi-doc/pull/37


Bin Meng (1):
Introduce Physical Memory Protection Extension

riscv-sbi.adoc | 65
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
Let's continue the discussion here as it has a wider audience than
github PR. I have also cc'd all the possible stakeholders.

The other alternatives propsed so far

1. Just parse the deveice tree node in S-mode software.

Pros: No additional SBI extensions are required.
Cons: U-Boot is responsible for copying the reserved-memory node from
the DT passed by OpenSBI and set it to the final DT if it is a
different one. OpenSBI also need to provide the DT where the previous
stage (FSBL/U-Boot SPL) doesn't provide a DT.

IMHO, this is not a very difficult problem to solve. The U-Boot
implementation is available here (just ~40 lines of code).
https://patchwork.ozlabs.org/patch/1254740/

2. Trap-n-Emulate PMP CSR reads from S-mode. The details are available
here.

https://github.com/riscv/riscv-sbi-doc/pull/37#issuecomment-596944084

Pros: No SBI extension or prior DTB fixup required in U-Boot.
Cons: As PMP extensions proposals are already in place, this may need
to be extended. Privilege spec may need to be modified to explicitly
say that M-mode can provide PMP csr emulation.


Any thoughts ?

--
Regards,
Atish

Join {tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.