linux-kernel - Re: [PATCH v3 0/2] RISC-V: KVM: VCPU reset fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DA3CUGMQXZNW.2BF5WWE4ANFS0@ventanamicro.com>
Date: Fri, 23 May 2025 09:17:34 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Atish Patra" <atish.patra@...ux.dev>, <kvm-riscv@...ts.infradead.org>
Cc: <kvm@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
 <linux-kernel@...r.kernel.org>, "Anup Patel" <anup@...infault.org>, "Atish
 Patra" <atishp@...shpatra.org>, "Paul Walmsley" <paul.walmsley@...ive.com>,
 "Palmer Dabbelt" <palmer@...belt.com>, "Albert Ou" <aou@...s.berkeley.edu>,
 "Alexandre Ghiti" <alex@...ti.fr>, "Andrew Jones" <ajones@...tanamicro.com>
Subject: Re: [PATCH v3 0/2] RISC-V: KVM: VCPU reset fixes

2025-05-22T14:43:40-07:00, Atish Patra <atish.patra@...ux.dev>:
> On 5/15/25 7:37 AM, Radim KrÄmÃ¡Å wrote:
>> Hello,
>> 
>> the design still requires a discussion.
>> 
>> [v3 1/2] removes most of the additional changes that the KVM capability
>> was doing in v2.  [v3 2/2] is new and previews a general solution to the
>> lack of userspace control over KVM SBI.
>> 
>
> I am still missing the motivation behind it. If the motivation is SBI 
> HSM suspend, the PATCH2 doesn't achieve that as it forwards every call 
> to the user space. Why do you want to control hsm start/stop from the 
> user space ?

HSM needs fixing, because KVM doesn't know what the state after
sbi_hart_start should be.
For example, we had a discussion about scounteren and regardless of what
default we choose in KVM, the userspace might want a different value.
I don't think that HSM start/stop is a hot path, so trapping to
userspace seems better than adding more kernel code.

Forwarding all the unimplemented SBI ecalls shouldn't be a performance
issue, because S-mode software would hopefully learn after the first
error and stop trying again.

Allowing userspace to fully implement the ecall instruction one of the
motivations as well -- SBI is not a part of RISC-V ISA, so someone might
be interested in accelerating a different M-mode software with KVM.

I'll send v4 later today -- there is a missing part in [2/2], because
userspace also needs to be able to emulate the base SBI extension.