On Fri, 2022-06-03 at 07:49 +0000, Schwarz, Konrad wrote:
On Behalf Of Anup Patel via
Sent: Friday, June 3, 2022 5:01
We have legacy SBI v0.1 calls where most of them are replaced byAs I pointed out in an earlier message, the design using a shared
newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does
have a replacement. This putchar() was being used in various cases
for early prints from OSes and bootloaders.
The SBI debug console extension is an attempt to replace the legacy
SBI v0.1 putchar(). The use of shared memory in this proposal is
motivated by the need to allow users to print multiple characters
one SBI call.
is a hindrance. Instead, each call should provide a pointer to the
address of the character buffer.
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 instead just pass an
address and size to print.
The legacy SBI v0.1 also had a getchar() call which is deprecatedConsider the case where we have more VMs than physical UARTs -- this
does not need any newer SBI call replacing it because it is
all platforms (including virtual platforms emulated by hypervisors)
have a proper interrupt driver console for supervisor software. The
proposed SBI debug console extension only tries to provide a
for early prints.
will actually be the norm in most deployments.
In this case you should use virtIO or some other more powerful
(To counter the argument that the hypervisor can provide virtual
for its guests, note that a dedicated para-virtualized interface is
efficient than trapping individual memory accesses to simulated HW
Agreed, but tha seems up to the Hypervisor to implement an effient
virtual UART implementation. For example the Xen HYPERVISOR_console_io
that Stefano mentioned earlier. Plus then we can leverage existing
implementations insted of inveting a another virtual serial device.
By making the interface a bit richer, as discussed in my earlier
a hypervisor can cover a much larger set of use cases.
Which we also then need to support in M-mode firmware. The more complex
the firmware becomes the more exposed it is.