On Thu, 2020-10-22 at 20:55 -0400, Sean Anderson wrote:

On 10/22/20 8:35 PM, Jonathan Behrens wrote:

On Thu, Oct 22, 2020 at 7:36 PM Sean Anderson via lists.riscv.org <
http://lists.riscv.org> <seanga2=gmail.com@...
<mailto:gmail.com@...>> wrote:

The initial state of software running in the SBI was not
specified.
Particularly egregious was the omission of the requirement that
a0
contain the hartid of the hart. That behavior was used to
justify not
including a function to get the current hartid (e.g. in #25
[1]), so it
should be specified.

Does it need to be specified in SBI specification or platform
specification ? Platform specification anyways should have a section
about state of machine while entering M/S mode.

Keeping the same information in SBI specification may be redundant.

SBI is intended as an interface for supervisor mode software,
however,
there is no technical reason why it cannot also be a "UBI."
This mode of
operation is currently supported by OpenSBI. I think it should
be
captured by this specification. There is a slight conflict with
the HSM
extension, in that harts are requires to start in S-mode. If a
system
only supports U-mode, then it would be impossible to start
harts with
the HSM extension, as it is currently written. If it is
undesired to
reference U-mode, then those references can be removed (or
split off
into a separate series).

This also specifies the return value of sbi_hart_status. This
is to
avoid a "slow start" situation where a hart is part of an
execution
environment, but starts much later than another hart. This
could cause
confusing behavior where it appeared to be stopped, and then
start
without a call to sbi_start_hart. Perhaps this sort of behavior
should
be explicitly disallowed by the HSM extension?

[1] https://github.com/riscv/riscv-sbi-doc/issues/25

Signed-off-by: Sean Anderson <seanga2@... <mailto:
seanga2@...>>
---

riscv-sbi.adoc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index d8cba88..0df3870 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -56,6 +56,23 @@ the value of the `mhartid` CSR on particular
harts.
All harts in the execution environment must comply with the
link:https://riscv.org/technical/specifications/[RISC-V <
https://riscv.org/technical/specifications/%5BRISC-V> ISA
specification].

+== Initial State
+
+If a hart supports supervisor mode, then it should begin
execution in (virtual)
+supervisor mode. Otherwise, harts shall begin execution in
(virtual) user mode.


How should the SBI user detect whether it is in supervisor mode or
user mode? Will this be indicated in the device tree?

Hm, I don't know. OpenSBI doesn't seem to provide this info to its
payloads (presumably whatever sets up fw_dynamic ensures that the
payload is intended for U-mode). Perhaps change

The stage prior to OpenSBI can specify this via fy_dynamic_info if
fw_dyanmic is used.

+If a hart supports supervisor mode, then it should begin
execution in (virtual)
+supervisor mode.

to

+If a hart supports supervisor mode, then it shall begin
execution in (virtual)
+supervisor mode.

and then have the payload determine the mode by running
`sbi_probe_extension('s')`. Alternatively, the mode could be passed
in
in a register.

+The entry point is unspecified, but must be the same for all
harts in the
+execution environment.

+
+If a hart begins execution in supervisor mode, then the `satp`
CSR must be set
+to 0, and the `sie` bit of the `sstatus` CSR must be cleared.
If a hart begins
+execution in supervisor mode, then the `uie` bit of the
`ustatus` CSR must be
+cleared. In both cases, the `a0` register must be set to the
*hartid*
+identifying the hart. The state of all other registers is
unspecified.


I believe current implementations all set/require that at
initialization register a1 holds the physical address of the
flattened device tree, so that should probably also be specified
here.

Do we want to specifically mandate an fdt?

IMHO, yes. Device tree should be one of the standard interface for
enumerating hardware. There can be others (ACPI/config) but there is a
lot of support for device tree in many OS/firmware/bootloader. I don't
see a point not standardizing device tree.

Having said that, this can be specified on profiles (the details are
under discussion). For example, a Linux distro profile can specify
whether it is DT based while other one is ACPI based.

Some implementations may just
want to provide a RISC-V config. Other unices may have their own
configuration structure that they expect. One option would be to just
specify a "config" of some kind, and let payloads determine what type
of
config by reading the magic number. Alternatively, we could specify
the
config type via some other manner.

--Sean

--
Regards,
Atish