From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Fuad Tabba <tabba@google.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v4 3/4] KVM: arm64: Fix FFR offset calculation for pKVM host state save and restore
Date: Fri, 05 Jul 2024 14:27:01 +0100 [thread overview]
Message-ID: <868qyg3r6i.wl-maz@kernel.org> (raw)
In-Reply-To: <20240704-kvm-arm64-fix-pkvm-sve-vl-v4-3-b6898ab23dc4@kernel.org>
On Thu, 04 Jul 2024 18:28:18 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> When saving and restoring the SVE state for the host we configure the
> hardware for the maximum VL it supports, but when calculating offsets in
> memory we use the maximum usable VL for the host. Since these two values
> may not be the same this may result in data corruption. We can just
> read the current VL from the hardware with an instruction so do that
> instead of a saved value, we need to correct the value and this makes
> the consistency obvious.
Which value are we correcting?
>
> Fixes: b5b9955617bc ("KVM: arm64: Eagerly restore host fpsimd/sve state in pKVM")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/kvm_hyp.h | 1 +
> arch/arm64/kvm/hyp/fpsimd.S | 5 +++++
> arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> 4 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index b05bceca3385..7510383d78a6 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -113,6 +113,7 @@ void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
> void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
> void __sve_save_state(void *sve_pffr, u32 *fpsr, int save_ffr);
> void __sve_restore_state(void *sve_pffr, u32 *fpsr, int restore_ffr);
> +int __sve_get_vl(void);
Is there any case where you'd consider returning a signed value? Given
the multiplier of '1', I don't see it likely to happen.
>
> u64 __guest_enter(struct kvm_vcpu *vcpu);
>
> diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
> index e950875e31ce..d272dbf36da8 100644
> --- a/arch/arm64/kvm/hyp/fpsimd.S
> +++ b/arch/arm64/kvm/hyp/fpsimd.S
> @@ -31,3 +31,8 @@ SYM_FUNC_START(__sve_save_state)
> sve_save 0, x1, x2, 3
> ret
> SYM_FUNC_END(__sve_save_state)
> +
> +SYM_FUNC_START(__sve_get_vl)
> + _sve_rdvl 0, 1
> + ret
> +SYM_FUNC_END(__sve_get_vl)
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 0c4de44534b7..06efcca765cc 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -327,7 +327,7 @@ static inline void __hyp_sve_save_host(void)
>
> sve_state->zcr_el1 = read_sysreg_el1(SYS_ZCR);
> write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
> - __sve_save_state(sve_state->sve_regs + sve_ffr_offset(kvm_host_sve_max_vl),
> + __sve_save_state(sve_state->sve_regs + sve_ffr_offset(__sve_get_vl()),
> &sve_state->fpsr,
> true);
> }
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index f43d845f3c4e..bd8f671e848c 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -49,7 +49,7 @@ static void __hyp_sve_restore_host(void)
> * supported by the system (or limited at EL3).
> */
> write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
> - __sve_restore_state(sve_state->sve_regs + sve_ffr_offset(kvm_host_sve_max_vl),
> + __sve_restore_state(sve_state->sve_regs + sve_ffr_offset(__sve_get_vl()),
> &sve_state->fpsr,
> true);
> write_sysreg_el1(sve_state->zcr_el1, SYS_ZCR);
>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-07-05 13:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 17:28 [PATCH v4 0/4] KVM: arm64: Fix underallocation of storage for SVE state Mark Brown
2024-07-04 17:28 ` [PATCH v4 1/4] arm64/fpsimd: Introduce __bit_to_vl() helper Mark Brown
2024-07-04 17:28 ` [PATCH v4 2/4] arm64/fpsimd: Discover maximum vector length implemented by any CPU Mark Brown
2024-07-04 17:28 ` [PATCH v4 3/4] KVM: arm64: Fix FFR offset calculation for pKVM host state save and restore Mark Brown
2024-07-05 13:27 ` Marc Zyngier [this message]
2024-07-05 17:25 ` Mark Brown
2024-07-04 17:28 ` [PATCH v4 4/4] KVM: arm64: Avoid underallocating storage for host SVE state Mark Brown
2024-07-05 13:20 ` [PATCH v4 0/4] KVM: arm64: Fix underallocation of storage for " Marc Zyngier
2024-07-05 17:18 ` Mark Brown
2024-07-08 15:30 ` Dave Martin
2024-07-08 18:12 ` Mark Brown
2024-09-04 15:48 ` Mark Brown
2024-09-06 15:35 ` Fuad Tabba
2024-09-06 16:10 ` Mark Brown
2024-09-06 16:14 ` Fuad Tabba
2024-09-06 18:02 ` Mark Brown
2024-09-10 12:49 ` Fuad Tabba
2024-09-10 14:19 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=868qyg3r6i.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).