[sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

[Stefano Stabellini]

On Thu, 2 Jun 2022, Greg Favor wrote:
> On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini <stefano.stabellini at xilinx.com> wrote:
>       On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote:
>       > 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 would be needed for very early parts of the
>       > hypervisor where it does not even have the ability to master a uart on its own.
> 
>       Yeah, I think you are right that it is not a must-have feature but a
>       nice-to-have feature.
> 
> 
> 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 found that to be a risky presumption in certain production environments where boot
> time matters (especially with frequent standing up of VMs from scratch).  So a worthwhile sanity check question would be 1) what percentage
> of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage
> inflate due to SBI calls for every individual character.

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 non-DEBUG
builds.

On the other hand the per-string print interface might be usable in
production, even not just early boot. However, of course, a proper UART
driver would be even better.

This is why I think it is nice to have: it expands the potential uses of
the SBI console interface, and it is simple and easy to use. At the same
time it is not a must-have because you could get away with just putchat
in early boot for DEBUG builds, and nothing + UART driver in non-DEBUG
builds.

That is why I am in favor of this addition, although I recognize it is
not critical.