Why SBI runtime is specified to provide services that can be provided in S-mode?

[Eugene Sh.]

 Hello. I have a general, and perhaps a dumb question about the SBI specification. As far as I understand the SBI runtime is supposed to execute in M-mode and the functions it is providing are all called via ECALLs elevating to M-mode.

 This makes sense as long as the service provided is requiring machine-only register/instruction access, but it looks like the SBI spec is also listing services that do not seem to be limited to machine-only implementation, such as the console output and timer functions. (The SBI spec is explicitly stating that the function `sbi_set_time` function is manipulating the supervisor timer registers and interrupts).

Am I misunderstanding the intention of SBI or it might be over-specified offloading an unnecessary functionality on itself?

Thank you

[Stefan Wallentowitz]

The other reason to use SBI is abstraction for portability. Any
operating system or hypervisor that is ported to the SBI interface can
then (at least to some degree) be executed on platforms implementing
the interface, without having to worry about the base console and timer
functionality (others are supposed to be added too).

Cheers,
Stefan

> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to sw-dev+un...@groups.riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/301a5c66-a92f-47d9-b2fc-ad92bfc0dfeen%40groups.riscv.org
> .

[Eugene Sh.]

Thanks, but I wonder if that could be done differently. For instance the m-mode functionality will be handled by a runtime, but the functionality that does not require the escalation could be a part of linkable library. That would potentially both boost the performance and reduce the size of the runtime.

пятница, 23 декабря 2022 г. в 05:58:20 UTC-5, Stefan Wallentowitz:

[atish patra]

On Friday, December 23, 2022 at 2:58:20 AM UTC-8 Stefan Wallentowitz wrote:

The other reason to use SBI is abstraction for portability. Any
operating system or hypervisor that is ported to the SBI interface can
then (at least to some degree) be executed on platforms implementing
the interface, without having to worry about the base console and timer
functionality (others are supposed to be added too).

Cheers,
Stefan

On Thu, 2022-12-22 at 12:39 -0800, Eugene Sh. wrote:
>  Hello. I have a general, and perhaps a dumb question about the SBI
> specification. As far as I understand the SBI runtime is supposed to
> execute in M-mode and the functions it is providing are all called
> via ECALLs elevating to M-mode.
>  This makes sense as long as the service provided is requiring
> machine-only register/instruction access, but it looks like the SBI
> spec is also listing services that do not seem to be limited to
> machine-only implementation, such as the console output and timer
> functions. (The SBI spec is explicitly stating that the function
> `sbi_set_time` function is manipulating the supervisor timer
> registers and interrupts).
>

In addition to the portability reasons described above, the console output or sbi_set_time is present due to historical reasons.

sbi_set_time was present to program the mtiemcmp which was memory mapped register available in M-mode. That was the only

way to program a timer earlier. The sstc extension was ratified last year. Hence, the latest linux kernel or KVM guests will directly

program the timer using [v]stimecmp if the platform supports it.

The console output extension exists for easier debugging early in the product cycle where a proper uart may not be ready

or a hypervisor don't have a uart emulation available. That's why, its being replaced with DBCN console extension now.

You can find more details here

https://lists.riscv.org/g/tech-prs/message/45