It seems to me that the rationale and summary of the extension is insufficient, and non-normative commentary is lacking. The ensuing mailing list discussion suggests that there are additional

I agree With the current design there is no way for the supervisor software to reclaim the memory once it has shared it with OpenSBI. We can add a close() call, but it seems simpler and safer to

As I pointed out in an earlier message, the design using a shared memory block is a hindrance. Instead, each call should provide a pointer to the (virtual) address of the character buffer. Consider

A further use case requiring fast boot are automotive electronic control units, e.g., an infotainment unit. -- Konrad From: sig-hypervisors@... <sig-hypervisors@...>On Behalf Of Greg Favor

<heinrich.schuchardt@...> wrote: Ahh I see. Sorry I misunderstood your comment. The designated shared memory for debug console is shared across the platforms while STA or PMU use case will

I have no security concerns. My thought was that it might be better to manage shared memory in a separate extension for all use cases. Best regards Heinrich

<heinrich.schuchardt@...> wrote: I would like to understand more about the security concerns you raised. Can you please elaborate on this ? As you pointed out, there are other possible use

Hi Stefano, <stefano.stabellini@...> wrote: We have legacy SBI v0.1 calls where most of them are replaced by newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does not have a

The numbers you asked will help but I just wanted to add that in my opinion a per-character putchar interface is not suitable for production due to the reasons you mentioned. I would compile it out in

I think the extension was proposed to be a Debug console extension. In a production environment if 10's of VMs were booting having them emit to the physical console - where all of those outputs will

Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have

Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.

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