On 5/30/25 4:09 AM, Radim Krčmář wrote:
2025-05-29T11:44:38-07:00, Atish Patra <atish.patra@xxxxxxxxx>:
On 5/29/25 3:24 AM, Radim Krčmář wrote:
I originally gave up on the idea, but I feel kinda bad for Drew now, so
trying again:
I am sorry if some of my replies came across in the wrong way. That was
never
the intention.
I didn't mean to accuse you, my apologies. I agree with Drew's
positions, so to expand on a question that wasn't touched in his mail:
Even if userspace wants SBI for the M-mode interface, security minded
This is probably a 3rd one ? Why we want M-mode interface in the user
space ?
It is about turning KVM into an ISA accelerator.
A guest thinks it is running in S/HS-mode.
The ecall instruction traps to M-mode. RISC-V H extension doesn't
accelerate M-mode, so we have to emulate the trap in software.
We don't need to accelerate M-mode. That's the beauty of the RISC-V H
extension.
The ISA is designed in such a way that the SBI is the interface between
the supervisor environment (VS/HS)
and the supervisor execution environment (HS/M).
The ISA doesn't say that M-mode means SBI. We try really hard to have
SBI on all RISC-V, but I think KVM is taking it a bit too far.
We can discuss how best to describe SBI, so userspace can choose to
accelerate the M-mode in KVM, but I think that the ability to emulate
M-mode in userspace should be provided.
I am still trying to understand the advantages of emulating the M-mode
in the user space.
Can you please elaborate ?
I am assuming you are not hinting Nested virtualization which can be
achieved with existing
ISA provided mechanisms and accelerated by SBI NACL.
