Of course a console is needed. But I was questioning the need for something much more elaborate than a putchar/getchar interface. I understand its needed to port the hypervisor but I undersatnd it

That is because it is useful to have debug console output when porting a hypervisor or baremetal code to a new board. Of course, if a hypervisor is already available for the board, then it would be

This could be done. As an example Xen provides the hypercall HYPERVISOR_console_io. The first parameter is the operation: CONSOLEIO_write or CONSOLEIO_read. The interface in RISC-V spec language

It's also helpful in early board bringup and early debugging as pointed out by Heiko as well. To address some of the concerns raised above, how about putting some restrictions on

We have a requirement in the OS-A platform spec to mandate a particular type of UART for early prints but there were objections on selecting one type of UART over another. This SBI debug console

Mark, In case you missed it from the agenda-email: we have the formation of a Firmware & Platforms Services SIG on the agenda for the (joint) Software HCs meeting today. Atish has kindly volunteered

Just remember that something that depends on an SBI change can't get ratified until the SBI change is ratified. If there is a roll up, there still needs to a TG governing it or it needs to be a fast

As per my discussions with Philip, there will be a Firmware & Platform Services SIG which will cover all the platform services specs (SBI, UEFI, ACPI). It can spin off separate TGs for SBI/ACPI which

Since this is for debug and really early phase debug till enough of the guest boots up to use a VFIO based char driver provided by the VMM, I am not sure that the slowness matters. Even this SBI call

That aligns w/ my recollection on how we'll handle updates to SBI.

My understanding is that different TGs or SIGs will propose their own SBI extensions. Once a set of changes for next SBI spec release are finalized, the SBI TG can collect all new SBI extensions and

The legacy SBI v0.1 putchar() and getchar() are byte-level send/receive calls. This is very slow for virtualized world particularly KVM RISC-V because each SBI v0.1 putchar() or getchar() will trap

we have seen a number of SBI changes proposed (debug console, ap tee, ...). will there be one big rev ala priv 1.12, small fast tracks , something else? I also suggest that this either needs to be

Hello! Glad to see a new proposal to the SBI standard. Besides to discussion before, I may (if possible or proper) suggest an idea of not implementing this extension, for SBI should provide

<heinrich.schuchardt@...> wrote: The shared memory area in case of this SBI extension will be shared across all HARTs so the SBI implementation will ensure atomicity in setting/reading

Should we keep this simple in the SBI - only have register based inputs - to send and receive 1 byte in each call? Keeping it a simple out_byte or in_byte - a serial port like interface seems the

The memory type should be 0 (i.e. PMA) for the shared memory between SBI implementation and supervisor software. Before MMU setup, the memory type is by default 0 (i.e. PMA) so we don't have to

Clearly, if we have a separate SBI extension to manage shared memory then we will end-up with such memory management calls. Memory allocators are generally hard to get it right and this also adds lot

Hi Anup, Here are my thoughts: * Guest memory access: I think this would be the first SBI extension to require access to guest memory. This needs to be considered carefully, but I think the higher

Am Donnerstag, 2. Juni 2022, 10:50:56 CEST schrieb Heiko Stübner: though, how does that relate to the time before MMU setup? I.e. in response to Heinrich's mail you talk about svpbmt, so I guess