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

Ved Shanbhogue

On Thu, Jun 02, 2022 at 01:50:01PM -0700, Greg Favor wrote:
On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini <
stefano.stabellini@...> wrote:

On Thu, 2 Jun 2022, Vedvyas Shanbhogue via 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.
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 get interspersed
seems to be not so useful. In a production environment would we expect the
VMM to provide a console service and not need SBI calls into M-mode firmare
to emit VM output to a physical console?

I was thinking this was about early boot debug and not so much about needing
a console at early boot. In most production deployments there may not be someone sitting at a terminal watching prints and so it may make more sense
for VM console outputs to be logged into a persistent file somewhere for example.
Or be held in the VM itself - e.g. a kernel ring buffer that someone may want
to display using a tool like dmesg when needed but otherwise does not get emitted chattily to a physical console.

Hope I am understanding this right.


Join { to automatically receive all group messages.