Re: [PATCH 0/6] ONE_REG interface for SBI FWFT extension

["Radim Krčmář" <rkrcmar@ventanamicro.com>]

2025-08-19T21:22:27+05:30, Anup Patel <apatel@ventanamicro.com>:
> On Tue, Aug 19, 2025 at 5:13 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>>
>> 2025-08-19T12:00:43+05:30, Anup Patel <apatel@ventanamicro.com>:
>> > On Mon, Aug 18, 2025 at 3:59 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>> >>
>> >> 2025-08-14T21:25:42+05:30, Anup Patel <apatel@ventanamicro.com>:
>> >> > This series adds ONE_REG interface for SBI FWFT extension implemented
>> >> > by KVM RISC-V.
>> >>
>> >> I think it would be better to ONE_REG the CSRs (medeleg/menvcfg), or at
>> >> least expose their CSR fields (each sensible medeleg bit, PMM, ...)
>> >> through kvm_riscv_config, than to couple this with SBI/FWFT.
>> >>
>> >> The controlled behavior is defined by the ISA, and userspace might want
>> >> to configure the S-mode execution environment even when SBI/FWFT is not
>> >> present, which is not possible with the current design.
>> >>
>> >> Is there a benefit in expressing the ISA model through SBI/FWFT?
>> >>
>> >
>> > Exposing medeleg/menvcfg is not the right approach because a
>> > Guest/VM does not have M-mode hence it is not appropriate to
>> > expose m<xyz> CSRs via ONE_REG interface. This also aligns
>> > with H-extension architecture which does not virtualize M-mode.
>>
>> We already have mvendorid, marchid, and mipid in kvm_riscv_config.
>
> The mvendorid, marchid, and mipid are accessible via SBI BASE
> extension but not any other M-mode CSRs hence these are special.
>
>>
>> The virtualized M-mode is userspace+KVM.  (KVM doesn't allow userspace
>> to configure most things now, but I think we'll have to change that when
>> getting ready for production.)
>
> The RISC-V architecture is not designed to virtualize M-mode
> and there is no practical use-case for virtualized M-mode hence
> WE WON'T BE SUPPORTING IT IN KVM RISC-V.

Oh, sorry for the misunderstanding, I'll be clearer next time and talk
about implementation of the supervisor execution environment.
KVM+userspace provides SEE to the VS-mode, which is to VS-mode as what
M-mode is to S-mode, hence I called KVM+userspace a virtualized M-mode.

> FYI, the KVM ARM64 does not virtualize EL3 either and it is
> already in production so please stop making random arguments
> for requiring virtualized M-mode for production.

Yeah, I agree that we don't need it, I just had to provide so many
examples in the previous discussion that I went into quite niche cases.

The increased flexibility is similarly useful for more important cases:
we can't avoid "virtualized M-mode"/SEE, but we don't have to completely
implement it in HS-mode.

>> For general virtualization, we want to be able to configure the
>> following behavior for each exception that would go to the virtualized
>> M-mode:
>>   0) delegated to the guest
>>   1) implemented by userspace
>>   2-N) implementations by KVM (ideally zero or one)
>>
>> We can have medeleg, and another method to decide how to handle trapped
>> exceptions, but it probably makes more sense to have a per-exception
>> ONE_REG that sets how each exception behaves.
>>
>
> No pointing in discussing this further since we won't be supporting
> virtualized M-mode.

I understand, back to the current series:

I think we need to provide means with which userspace can control which
FWFT features are enabled, because KVM just exposes everything it know
and hardware supports right now:
 1) Migration between different systems would be hindered
 2) We couldn't add more FWFT features without breaking the SEE

The (2) is similar to how we must set ".default_disabled = true" to
current FWFT, because KVM can't be changing the SEE for userspace.

Do you want me to send a patch that inverts the default, to make all
future SBI extension start as disabled, so we can't easily repeat the
mistake in the future?

Thanks.

-- 
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv