Message-ID: <CAK9=C2Uk-mL251XUVNtbU52KFuu+=sUR5-_=haAHmTACVDBQhA@mail.gmail.com>
Date: Thu, 21 Aug 2025 11:56:21 +0530
From: Anup Patel <apatel@...tanamicro.com>
To: Radim Krčmář <rkrcmar@...tanamicro.com>
Cc: Atish Patra <atish.patra@...ux.dev>, Palmer Dabbelt <palmer@...belt.com>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Alexandre Ghiti <alex@...ti.fr>, 
	Andrew Jones <ajones@...tanamicro.com>, Anup Patel <anup@...infault.org>, 
	Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>, kvm@...r.kernel.org, 
	kvm-riscv@...ts.infradead.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-riscv <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH 0/6] ONE_REG interface for SBI FWFT extension

On Tue, Aug 19, 2025 at 11:05 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>
> 2025-08-19T21:22:27+05:30, Anup Patel <apatel@...tanamicro.com>:
> > On Tue, Aug 19, 2025 at 5:13 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
> >>
> >> 2025-08-19T12:00:43+05:30, Anup Patel <apatel@...tanamicro.com>:
> >> > On Mon, Aug 18, 2025 at 3:59 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
> >> >>
> >> >> 2025-08-14T21:25:42+05:30, Anup Patel <apatel@...tanamicro.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 FWFT features are defined to be backward compatible by SBI spec
and these features only affect after Guest/VM has configured them. This
means if a Guest/VM is not aware of SBI FWFT then it won't configure
FWFT features and Guest/VM should still work fine.

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

Not needed. We only keep an SBI extension disabled by default if
it is being forwarded to KVM userspace (e.g. DBCN, SUSP) because
KVM userspace needs to opt-in for such SBI extension handling. In other
cases, the SBI extension is enabled by default and KVM userspace can
explicitly disable it for Guest/VM using ONE_REG interface. This is true
for ISA extensions as well.

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

No need to send any patch. Please focus on your current assignments.

Regards,
Anup

Powered by blists - more mailing lists