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

[Alistair Francis]

On Fri, 2022-06-03 at 07:49 +0000, Schwarz, Konrad wrote:
> 
> > From:
> > sig-hypervisors at lists.riscv.org <sig-hypervisors at lists.riscv.org>
> > On Behalf Of Anup Patel via
> > lists.riscv.org
> > Sent: Friday, June 3, 2022 5:01
> 
> > 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 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
> > in
> > one SBI call.
> 
> 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.

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 instead just pass an
address and size to print.

> 
> > The legacy SBI v0.1 also had a getchar() call which is deprecated
> > and
> > does not need any newer SBI call replacing it because it is
> > expected
> > all platforms (including virtual platforms emulated by hypervisors)
> > will
> > have a proper interrupt driver console for supervisor software. The
> > proposed SBI debug console extension only tries to provide a
> > solution
> > for early prints.
> 
> Consider the case where we have more VMs than physical UARTs -- this
> will actually be the norm in most deployments.

In this case you should use virtIO or some other more powerful
interface

> 
> (To counter the argument that the hypervisor can provide virtual
> UARTs
> for its guests, note that a dedicated para-virtualized interface is
> much more
> efficient than trapping individual memory accesses to simulated HW
> registers).

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
> proposal,
> 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.

Alistair

> 
> 
> -- 
> Konrad
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#1747):
> https://lists.riscv.org/g/tech-unixplatformspec/message/1747
> Mute This Topic: https://lists.riscv.org/mt/91507495/1782774
> Group Owner: tech-unixplatformspec+owner at lists.riscv.org
> Unsubscribe:
> https://lists.riscv.org/g/tech-unixplatformspec/unsub [alistair.francis@wdc.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>