From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9EBBEC4828F for ; Fri, 9 Feb 2024 16:47:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=amE+9n0NeUObnJrYcZn7Bqwj7Nj/1kt7KrGkthXYj9o=; b=i68VPGunIZTmUf jEYVjD/H+bX6hBni8olaxkQnmoqpeeICvDcj+xPU/47gUYdYZd/3Yn6UlUnY2biLuGSC2PlfcFJKq QnNpGmnad0EyiBY0yYG6y1L/I8VdI0KW81Z2ft6aa7EmiBIWEO2Oma9YwpDMJ03Ulvyd5Ayk32BeN ApJqTMkszf0DrErwl9dJ0FKCJkHxEPdsB0DTWL47UUfckAkSdF0iXH01nL/dlouuOIxwQeJNZqn28 vvnVnbAf+oiQLUlZL5TqC/DGJblETfMzcMm0oMRmOF5sEGCTmo4/1z5Tr0Z6Gx64ZTwp7chgZlK0f 2QgideW5NZjuKlIpjdzw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rYU1j-0000000HZe7-0w41; Fri, 09 Feb 2024 16:46:59 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rYU1f-0000000HZcO-33qD for linux-arm-kernel@lists.infradead.org; Fri, 09 Feb 2024 16:46:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 03419CE2027; Fri, 9 Feb 2024 16:46:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3E3DC433C7; Fri, 9 Feb 2024 16:46:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707497213; bh=ZDSnHoSn9j8iFecbqrhC6wjO40hzxWdBix4sKB+WfyI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uNmqN0I7GXcBf92PEgQT9mcgWWcnoGI1RyUVGjEmEcQMHglJAz84xS23XSTuiubj1 DS1JqV7nYvObNfehyrYohYW0HVBjXfegp0kR9SWTzeaRbaY2+/P0ySPUEqF3DjrW+A neT8OALRnqklWmTESB/LqRlkrll3pmgWQLwtFTaEQk0CEAz+Hby61ctsfaEdipwnQ4 s+bi95xSILy7Nu4a5IvwlE3XJShTYwTWdTlxhcAdm8zF284KLZtOUMXMRGnRWk+34l PpCRaBPaIHCEtgJE8xiaoCBlZhGNbt1Vszd4AUH0JnxJCF8GZEl6gfvxfzyyTXqXBo zeN8t01FqUM7g== Date: Fri, 9 Feb 2024 16:46:48 +0000 From: Will Deacon To: Mark Brown Cc: Catalin Marinas , Dave Martin , Jackson Cooper-Driver , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] arm64/sme: Restore SMCR on exit from suspend Message-ID: <20240209164648.GA24829@willie-the-truck> References: <20240203-arm64-sme-resume-v2-0-a1fbaddc4425@kernel.org> <20240203-arm64-sme-resume-v2-1-a1fbaddc4425@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240203-arm64-sme-resume-v2-1-a1fbaddc4425@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240209_084656_140575_528BEF70 X-CRM114-Status: GOOD ( 22.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Feb 03, 2024 at 01:00:40PM +0000, Mark Brown wrote: > The fields in SMCR_EL1 reset to an architecturally UNKNOWN value. Since we > do not otherwise manage the traps configured in this register at runtime we > need to reconfigure them after a suspend in case nothing else was kind > enough to preserve them for us. > > The vector length will be restored as part of restoring the SME state for > the next SME using task. > > Fixes: a1f4ccd25cc2 (arm64/sme: Provide Kconfig for SME) > Reported-by: Jackson Cooper-Driver > Signed-off-by: Mark Brown > --- > arch/arm64/include/asm/fpsimd.h | 2 ++ > arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++ > arch/arm64/kernel/suspend.c | 3 +++ > 3 files changed, 19 insertions(+) > > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h > index 50e5f25d3024..7780d343ef08 100644 > --- a/arch/arm64/include/asm/fpsimd.h > +++ b/arch/arm64/include/asm/fpsimd.h > @@ -386,6 +386,7 @@ extern void sme_alloc(struct task_struct *task, bool flush); > extern unsigned int sme_get_vl(void); > extern int sme_set_current_vl(unsigned long arg); > extern int sme_get_current_vl(void); > +extern void sme_suspend_exit(void); > > /* > * Return how many bytes of memory are required to store the full SME > @@ -421,6 +422,7 @@ static inline int sme_max_vl(void) { return 0; } > static inline int sme_max_virtualisable_vl(void) { return 0; } > static inline int sme_set_current_vl(unsigned long arg) { return -EINVAL; } > static inline int sme_get_current_vl(void) { return -EINVAL; } > +static inline void sme_suspend_exit(void) { } > > static inline size_t sme_state_size(struct task_struct const *task) > { > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index a5dc6f764195..8d2a5824d5d3 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1311,6 +1311,20 @@ void __init sme_setup(void) > get_sme_default_vl()); > } > > +void sme_suspend_exit(void) > +{ > + u64 smcr = 0; > + > + if (!system_supports_sme()) > + return; > + > + if (system_supports_fa64()) > + smcr |= SMCR_ELx_FA64; > + > + write_sysreg_s(smcr, SYS_SMCR_EL1); > + write_sysreg_s(0, SYS_SMPRI_EL1); > +} Looking at the other places where we touch SMCR_EL1, it looks like we always use a read-modify-write sequence. However, doesn't that mean we inherit a bunch of unknown bits on cold boot? I'm basically wondering whether we should be initialising these registers to a well-known value earlier in the CPU init path, a bit like we do for the EL2 variants. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel