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

[Schwarz, Konrad]

> -----Original Message-----
> From: Alistair Francis <Alistair.Francis at wdc.com>
> Sent: Friday, June 3, 2022 10:47
> > 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.

But this makes it incumbent on each hypervisor to provide such an
interface, and requires each OS to provide drivers for each
hypervisor it knows about.  You then have an N:M situation,
which is bad for the RISC-V platform.

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

The same argument applies to hypervisors. What fundamental difference
between M-mode and HS-mode software is there that makes the risk
so much different?

An implementation wishing to minimize its responsibilities can
always return run-time errors for functionality it does not
wish to support.

-- 
Konrad