2025-08-19T21:22:27+05:30, Anup Patel <apa...@ventanamicro.com>: > On Tue, Aug 19, 2025 at 5:13 PM Radim Krčmář <rkrc...@ventanamicro.com> wrote: >> >> 2025-08-19T12:00:43+05:30, Anup Patel <apa...@ventanamicro.com>: >> > On Mon, Aug 18, 2025 at 3:59 PM Radim Krčmář <rkrc...@ventanamicro.com> >> > wrote: >> >> >> >> 2025-08-14T21:25:42+05:30, Anup Patel <apa...@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.
