On Thu, Jun 02, 2022 at 07:52:55PM +0530, Anup Patel wrote:
On Thu, Jun 2, 2022 at 6:29 PM Ved Shanbhogue <ved@...> wrote:Since this is for debug and really early phase debug till enough of the guest
boots up to use a VFIO based char driver provided by the VMM, I am not sure
that the slowness matters.
Even this SBI call I expected the VMM to intercept and if the VMM has all emulation in the user space VMM - e.g. the console tty is open by the user
space VMM, I am not sure this would avoid that trip to user space. If the motivation is primarily VM debug then perhaps a standardized set of
hypercalls implemented by KVM makes more sense than SBI calls that would
need to be built into the M-mode firmware?
Yes, and now that I understand the motivation better why dont we define this as a hypercall/pv-ops interface to a VMM than a SBI call to the M-mode firmware and needing to build a virt-io like framework in firmware.I worry about bugs/security issues that can be caused by M-mode firmware accessing strings in untrusted memory.The VirtIO based para-virt devices rely heavily on shared memory so I think
Thanks. I was not sure since we had all the discussion about Svpbmt.The API as defined does not say whether the address is a virtual address or a physical address.It is a physical address. I will clarify this in Draft v2.
Understand that better now. But if that is the main motivation thenBased on discussion it did not seem like it needs to be much fancier than this as this is for early OS/VMM code till it has enough functionality to directly interact with a uart.The goal of the shared memory based SBI call for early prints is to
I am not understanding why we would want to push all of this into
M-mode firmware vs. defining a set of standardized pv-ops to be used
by guest OSes.