On Thu, 2 Jun 2022, Schwarz, Konrad via lists.riscv.org wrote:

Hi Anup,

From: sig-hypervisors@... <sig-hypervisors@...> On Behalf Of Anup Patel via
lists.riscv.org
Subject: [sig-hypervisors] SBI Debug Console Extension Proposal (Draft v1)

Below is the draft proposal for SBI Debug Console Extension.

Here are my thoughts:

* Guest memory access: I think this would be the first SBI extension to require access to
guest memory. This needs to be considered carefully, but I think the higher bandwidth afforded by
the interface is useful enough to allow this.

* API:
* Currently, only a write interface is provided. It would be much better to have a
read/write interface.

Benefits of this would be to allow a hypervisor to control an OS, e.g., for testing purposes
or to automate installation tasks. Inter-guest communication could also be realized
via such an interface.

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 would be something along these
lines:

struct sbiret sbi_debug_console_io(unsigned long operation, /* read or write */
unsigned long address,
unsigned long num_chars)

There is no memory area pre-registration required, however appropriate
checks on the validity of the address provided should always be done in
the implementation.

The good thing about getting rid of the pre-registration is that
multiple threads could make concurrent sbi_debug_console_io requests on
different CPUs.

I think it might be a good idea in the guest-side implementation (e.g.
Linux or Zephyr) to choose a specific memory area for this. However, it
doesn't have to be part of the interface. I think it should be an
implementation detail.

The firmware/hypervisor-side implementation of sbi_debug_console_io
can deal with any addresses provided as long as they are valid.