2025-05-05T14:39:25-07:00, Atish Patra <atishp@xxxxxxxxxxxx>: > This series adds support for enabling hstateen bits lazily at runtime > instead of statically at bootime. The boot time enabling happens for > all the guests if the required extensions are present in the host and/or > guest. That may not be necessary if the guest never exercise that > feature. We can enable the hstateen bits that controls the access lazily > upon first access. This providers KVM more granular control of which > feature is enabled in the guest at runtime. > > Currently, the following hstateen bits are supported to control the access > from VS mode. > > 1. BIT(58): IMSIC : STOPEI and IMSIC guest interrupt file > 2. BIT(59): AIA : SIPH/SIEH/STOPI > 3. BIT(60): AIA_ISEL : Indirect csr access via siselect/sireg > 4. BIT(62): HSENVCFG : SENVCFG access > 5. BIT(63): SSTATEEN0 : SSTATEEN0 access > > KVM already support trap/enabling of BIT(58) and BIT(60) in order > to support sw version of the guest interrupt file. I don't think KVM toggles the hstateen bits at runtime, because that would mean there is a bug even in current KVM. > 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. 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. Thanks.
