Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel


On Wed, Aug 3, 2022 at 1:27 PM 洛佳 Luo Jia <me@...> wrote:

Hi Group,

I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the
string address in a probable virtual address? In this way the supervisor won't need to convert it to physical
address, and we can save one argument for future designs to refer to. If machine mode firmware need to
read the supervisor accesible address, it uses mstatus.TVM bit to achieve this. By this way the machine
accesses the string parameter the same way the supervisor does.

Considering difference of physical and virtual address spacees (e.g. on RV32 Sv32 has 34-bit physical address),
if the supervisor does not use virtual memory, it only reads lower 32 bit of physical address, which is the
same limit of how machine mode firmware would read the memory.

By this way we have `usize` as parameter:

fn debug_console_print(supervisor_address: usize, length_bytes: usize) -> SbiRet { ... }
There are two major issues in passing virtual address of string:

1) A rogue supervisor software can pass a virtual address mapped to a
physical address not accessible to it.
2) To access a string by virtual address, the SBI implementation (M-mode
firmware and hypervisors) end-up using unpriv load/store instructions.
These unpriv load/store instructions can potentially trap for hypervisor
because the guest OS can swap-out pages while the hypervisor is
trying to access it. Further in-case of nested virtualization, the unpriv
load/store instructions always trap to the host hypervisor so accessing
string by virtual address becomes extremely slow for guest hypervisor.

Due to the above reasons, we avoid using virtual addresses as
parameters in newer SBI calls for SBI v0.2 (higher).


... other than combining different parts to form the final address.

Luo Jia

Join to automatically receive all group messages.