2025-05-30T12:29:30-07:00, Atish Patra <atish.patra@xxxxxxxxx>: > 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. (It is a gap to me. :]) > 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 says nothing about the implementation of said interface. Returning 42 in x21 as a response to an ecall with 0x10 in a7 and 0x3 in a6 is perfectly valid RISC-V implementation that KVM currently cannot virtualize. >> 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 ? This thread already has a lot of them, so to avoid repeating them, I have to go into quite niche use-cases: When developing M-mode software on RISC-V (when RISC-V has more useful implementations than QEMU), a developer might want to accelerate the S/U-modes in KVM. It is also simpler to implement an old SBI interface (especially with bugs/quirks) if virtualization just executes the old M-mode binary. Why must KVM prevent userspace from virtualizing RISC-V? > I am assuming you are not hinting Nested virtualization which can be > achieved with existing > ISA provided mechanisms and accelerated by SBI NACL. Right, I am talking about virtualization of RISC-V, because I don't have a crystal ball to figure out what users will want.
