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


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!


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).

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

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 ?


Join to automatically receive all group messages.