From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B21B22AE68; Tue, 29 Apr 2025 17:52:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745949122; cv=none; b=PjF8/K7WRiyy6a/ZUV4HsYFMNaVnNMOklWkgrNYoT/pbgC87LJlSi6zJhnqN3y2HAjRCxIAvOplbLuDviSUFxFFk8wnNYAYWTi7qS8Dl0LBrSuHyuc0g7ntSzVYcHni0mCDwhbeBHrBAi6H9usUsd1TmjZ08KXFaWdhWtEI31RU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745949122; c=relaxed/simple; bh=rdHNlVW5xeGHAbQ0r66YWhmRQIgDUK8Z19aOaSwBB88=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NII5NfHrXznsrE7ZL+3pgAr2P3RfFM/+TACjHhpAwCYpkQgAoKk2gMZaeOg11YKO1Aff6Je/kTiNBjOPWj3F1cmO2ZPv/fzg44VcAf+vLn1V6HdP0kX/le5Bs8kM3S4eAw9W4X3PWnTVnXGRkwJaDrXv5cYK6M77i7wiL0C7Epw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=rouuskpH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="rouuskpH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E4F9C4CEE3; Tue, 29 Apr 2025 17:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1745949122; bh=rdHNlVW5xeGHAbQ0r66YWhmRQIgDUK8Z19aOaSwBB88=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rouuskpHNMBPCSAI5JtvxyrfLMdM1aU/m+mtmGUa2PhU68XPE5jVebO4VI159zFYi sVsiQHkzLl+F06V9QR8g4f6lM2ks90kvPyjKc9ulQK4kGAuwD0ox02YxLe5IxGztYE 99+7a58R4439vqO4144Z+MnC26mFe7ld9GGgAPgM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Mark Brown , Catalin Marinas , Marc Zyngier , Will Deacon , Mark Rutland Subject: [PATCH 5.15 191/373] arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM Date: Tue, 29 Apr 2025 18:41:08 +0200 Message-ID: <20250429161131.021262090@linuxfoundation.org> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250429161123.119104857@linuxfoundation.org> References: <20250429161123.119104857@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Brown [ Upstream commit 62021cc36add7b2c015b837f7893f2fb4b8c2586 ] Now that we are explicitly telling the host FP code which register state it needs to save we can remove the manipulation of TIF_SVE from the KVM code, simplifying it and allowing us to optimise our handling of normal tasks. Remove the manipulation of TIF_SVE from KVM and instead rely on to_save to ensure we save the correct data for it. There should be no functional or performance impact from this change. Signed-off-by: Mark Brown Reviewed-by: Catalin Marinas Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20221115094640.112848-5-broonie@kernel.org Signed-off-by: Will Deacon [ Mark: trivial backport ] Signed-off-by: Mark Rutland Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kernel/fpsimd.c | 40 ++++++++++++++++------------------------ arch/arm64/kvm/fpsimd.c | 3 --- 2 files changed, 16 insertions(+), 27 deletions(-) --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -318,7 +318,13 @@ static void task_fpsimd_load(void) /* * Ensure FPSIMD/SVE storage in memory for the loaded context is up to - * date with respect to the CPU registers. + * date with respect to the CPU registers. Note carefully that the + * current context is the context last bound to the CPU stored in + * last, if KVM is involved this may be the guest VM context rather + * than the host thread for the VM pointed to by current. This means + * that we must always reference the state storage via last rather + * than via current, if we are saving KVM state then it will have + * ensured that the type of registers to save is set in last->to_save. */ static void fpsimd_save(void) { @@ -334,9 +340,15 @@ static void fpsimd_save(void) if (test_thread_flag(TIF_FOREIGN_FPSTATE)) return; - if (IS_ENABLED(CONFIG_ARM64_SVE) && - test_thread_flag(TIF_SVE)) { - if (WARN_ON(sve_get_vl() != last->sve_vl)) { + if ((last->to_save == FP_STATE_CURRENT && test_thread_flag(TIF_SVE)) || + last->to_save == FP_STATE_SVE) { + save_sve_regs = true; + vl = last->sve_vl; + } + + if (IS_ENABLED(CONFIG_ARM64_SVE) && save_sve_regs) { + /* Get the configured VL from RDVL, will account for SM */ + if (WARN_ON(sve_get_vl() != vl)) { /* * Can't save the user regs, so current would * re-enter user with corrupt state. @@ -347,26 +359,6 @@ static void fpsimd_save(void) } } - if (test_thread_flag(TIF_SVE)) { - save_sve_regs = true; - vl = last->sve_vl; - } - - /* - * Validate that an explicitly specified state to save is - * consistent with the task state. - */ - switch (last->to_save) { - case FP_STATE_CURRENT: - break; - case FP_STATE_FPSIMD: - WARN_ON_ONCE(save_sve_regs); - break; - case FP_STATE_SVE: - WARN_ON_ONCE(!save_sve_regs); - break; - } - if (IS_ENABLED(CONFIG_ARM64_SVE) && save_sve_regs) { sve_save_state((char *)last->sve_state + sve_ffr_offset(last->sve_vl), --- a/arch/arm64/kvm/fpsimd.c +++ b/arch/arm64/kvm/fpsimd.c @@ -110,7 +110,6 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm &vcpu->arch.fp_type, fp_type); clear_thread_flag(TIF_FOREIGN_FPSTATE); - update_thread_flag(TIF_SVE, vcpu_has_sve(vcpu)); } } @@ -151,7 +150,5 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcp sysreg_clear_set(CPACR_EL1, CPACR_EL1_ZEN_EL0EN, 0); } - update_thread_flag(TIF_SVE, 0); - local_irq_restore(flags); }