- [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
Schwarz, Konrad <konrad.schwarz@...>
toggle quoted messageShow quoted text
From: Alistair Francis <Alistair.Francis@...>
Sent: Friday, June 3, 2022 10:47
Consider the case where we have more VMs than physical UARTs -- thisIn this case you should use virtIO or some other more powerful
will actually be the norm in most deployments.
Agreed, but tha seems up to the Hypervisor to implement an effient
(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
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 earlierWhich we also then need to support in M-mode firmware. The more complex
a hypervisor can cover a much larger set of use cases.
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.
Join email@example.com to automatically receive all group messages.