[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D9QTOYMN362W.398FE9SQB0S4X@ventanamicro.com>
Date: Thu, 08 May 2025 15:45:03 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Atish Patra" <atish.patra@...ux.dev>, "Anup Patel"
<anup@...infault.org>, "Atish Patra" <atishp@...shpatra.org>, "Paul
Walmsley" <paul.walmsley@...ive.com>, "Palmer Dabbelt"
<palmer@...belt.com>, "Alexandre Ghiti" <alex@...ti.fr>
Cc: <kvm@...r.kernel.org>, <kvm-riscv@...ts.infradead.org>,
<linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
"linux-riscv" <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH 0/5] Enable hstateen bits lazily for the KVM RISC-V
Guests
2025-05-07T17:34:38-07:00, Atish Patra <atish.patra@...ux.dev>:
> On 5/7/25 7:36 AM, Radim Krčmář wrote:
>> 2025-05-06T11:24:41-07:00, Atish Patra <atish.patra@...ux.dev>:
>>> On 5/6/25 2:24 AM, Radim Krčmář wrote:
>>>> 2025-05-05T14:39:25-07:00, Atish Patra <atishp@...osinc.com>:
>>>>> This series extends
>>>>> those to enable to correpsonding hstateen bits in PATCH1. The remaining
>>>>> patches adds lazy enabling support of the other bits.
>>>> The ISA has a peculiar design for hstateen/sstateen interaction:
>>>>
>>>> For every bit in an hstateen CSR that is zero (whether read-only zero
>>>> or set to zero), the same bit appears as read-only zero in sstateen
>>>> when accessed in VS-mode.
>>> Correct.
>>>
>>>> This means we must clear bit 63 in hstateen and trap on sstateen
>>>> accesses if any of the sstateen bits are not supposed to be read-only 0
>>>> to the guest while the hypervisor wants to have them as 0.
>>> Currently, there are two bits in sstateen. FCSR and ZVT which are not
>>> used anywhere in opensbi/Linux/KVM stack.
>> True, I guess we can just make sure the current code can't by mistake
>> lazily enable any of the bottom 32 hstateen bits and handle the case
>> properly later.
>
> I can update the cover letter and leave a comment about that.
>
> Do you want a additional check in sstateen
> trap(kvm_riscv_vcpu_hstateen_enable_stateen)
> to make sure that the new value doesn't have any bits set that is not
> permitted by the hypervisor ?
I wanted to prevent kvm_riscv_vcpu_hstateen_lazy_enable() from being
able to modify the bottom 32 bits, because they are guest-visible and
KVM does not handle them correctly -- it's an internal KVM error that
should be made obvious to future programmers.
>>> In case, we need to enable one of the bits in the future, does hypevisor
>>> need to trap every sstateen access ?
>> We need to trap sstateen accesses if the guest is supposed to be able to
>> control a bit in sstateen, but the hypervisor wants to lazily enable
>> that feature and sets 0 in hstateen until the first trap.
> Yes. That's what PATCH 4 in this series does.
I was thinking about the correct emulation.
e.g. guest sets sstateen bit X to 1, but KVM wants to handle the feature
X lazily, which means that hstateen bit X is 0.
hstateen bit SE0 must be 0 in that case, because KVM must trap the guest
access to bit X and properly emulate it.
When the guest accesses a feature controlled by sstateen bit X, KVM will
lazily enable the feature and then set sstateen and hstateen bit X.
Powered by blists - more mailing lists