-----Original Message-----
From: Alistair Francis <Alistair.Francis@...>
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