[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DC6L3PG5HP48.2J8TC1JZHMJVO@ventanamicro.com>
Date: Tue, 19 Aug 2025 19:35:44 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Anup Patel" <apatel@...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
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 (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.
Powered by blists - more mailing lists