[PATCH v3 9/9] RISC-V: KVM: Upgrade the supported SBI version to 3.0

[Atish Patra]

On 6/3/25 4:40 AM, Radim Krčmář wrote:
> 2025-05-30T12:29:30-07:00, Atish Patra <atish.patra at linux.dev>:
>> On 5/30/25 4:09 AM, Radim Krčmář wrote:
>>> 2025-05-29T11:44:38-07:00, Atish Patra <atish.patra at linux.dev>:
>>>> 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. :])
RISC-V H extension is designed to virtualize S-mode and U-mode. Not M-mode.
I don't think retrofitting M-mode virtualization has absolutely any 
benefit. It has
many challenges that will probably result in poor performance. It can be 
a hobby project
but I am not sure if it can be adopted in production.

Are there any similar use cases in other ISAs ? Does anybody support 
virtualizaing EL3 in ARM64 ?

>> 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.

If the concern is only supporting an older version of SBI version, we 
can support that with onereg
interface today. I think I already agreed on that earlier in this thread 
and revise this series to have
it ready for review.


>>> 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?

If there is a valid use case that can be put into production or
if you have any prototype that it has better performance then we can 
have it.
In absence of either, isn't it better to spend our energy on things that 
actually matter
right now and improve RISC-V virtualization performance rather than 
something that
may or may not be possible in the very far future.

>> 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.