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 ABEEDC6FA82 for ; Tue, 20 Sep 2022 18:21:06 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Qa5kTZIxARPJpqDz658SolfczEFKRXTv6zYPzUICOUU=; b=34HU32IBSC8tjg 2rlaaBFO/0VMLzEyGfH0mEh0ZxbV9UpmY03PkRVNKxDEFYVmW6snUdTLj+Cs9UbvKjcZb9fSFEYzt XtN4KSaJwkysLSMVssVpKvJvBxM1EptXtNxvsmdPn/5eAPMY1ivz1kGHe1adD7cVQRGQ7ZgJ4BLRl 4RPEU2JwHdb0M6fcp2lCVDKSpQ7h0V0prE4317t5oPWVoIDZUd9KSuPS+sSPSR164iD/xHv1WRDVL JWZYLTtkoDImjBSHSJgocXtX3Xw0uGcGYQKcjPfczE3r5Ghoa6k7EqHRPnJyu+uH+RnIgWMqG7IdQ hVBqRgVPnioX3ykIxPPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oahqn-005h6l-AB; Tue, 20 Sep 2022 18:20:05 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oahqk-005h5s-5e for linux-arm-kernel@lists.infradead.org; Tue, 20 Sep 2022 18:20:03 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 91FB562BFB; Tue, 20 Sep 2022 18:20:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFFBDC433D6; Tue, 20 Sep 2022 18:20:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663698001; bh=3IuOSASXp6ftLoghtz8EBhswlJ3tQxqpUPcErhsnsoo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fVMAJJwU4SbA4tqHpOTcwDTMfvR7Vh8wbgNH1qDj2vK65GvKM0kRAITmWf+KzJJQR Z/25SyOjDoZw2M08Iykeo96N0I0z+yy38ly5he0Gx6j8q8cFYM6D0gbykekcvJjcYN 6Nwm003HdZ/pL/gPIkntYiO05oa37KQWqxmjxRnBwswpgfl0wgPVPW8VXDo50esa1Z Jibk8tIFN3Ul/6iLfHDOAKa5Rvm2CzznSeZi7zUb1fAFOKDGpcNvDpsM1I2QxNHgVa fq39qf/BOhj7uSoRXMD6BM2EVDV69s/l3c3a3pjY6FJX22Y3TFdQ7TuQ6cXT+xpCvb ehLXpYZ/4iuRg== Received: from 185-176-101-241.host.sccbroadband.ie ([185.176.101.241] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oahqg-00BTFc-O6; Tue, 20 Sep 2022 19:19:58 +0100 Date: Tue, 20 Sep 2022 19:19:57 +0100 Message-ID: <87tu51kiwi.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Zhang Lei , James Morse , Alexandru Elisei , Andre Przywara , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 5/7] arm64/fpsimd: Load FP state based on recorded data type In-Reply-To: <20220815225529.930315-6-broonie@kernel.org> References: <20220815225529.930315-1-broonie@kernel.org> <20220815225529.930315-6-broonie@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.176.101.241 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, zhang.lei@jp.fujitsu.com, james.morse@arm.com, alexandru.elisei@arm.com, andre.przywara@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220920_112002_371172_E78FE5E5 X-CRM114-Status: GOOD ( 34.08 ) 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 Mon, 15 Aug 2022 23:55:27 +0100, Mark Brown wrote: > > Now that we are recording the type of floating point register state we > are saving when we save it we can use that information when we load to > decide which register state is required and bring the TIF_SVE state into > sync with the loaded register state. Really, this sentence makes zero sense to me. Please at least add some punctuation, because the only words that spring to mind here are "DOES NOT COMPUTE". > > The SME state detauls are already recorded directly in the saved > SVCR and handled based on the information there. > > Since we are not changing any of the save paths there should be no > functional change from this patch, further patches will make use of this > to optimise and clarify the code. > > Signed-off-by: Mark Brown > --- > arch/arm64/kernel/fpsimd.c | 39 ++++++++++++++++++++++++++++++-------- > 1 file changed, 31 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index aaea2dc02cbd..4096530dd4c6 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -392,11 +392,36 @@ static void task_fpsimd_load(void) > WARN_ON(!system_supports_fpsimd()); > WARN_ON(!have_cpu_fpsimd_context()); > > - /* Check if we should restore SVE first */ > - if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) { > - sve_set_vq(sve_vq_from_vl(task_get_sve_vl(current)) - 1); > - restore_sve_regs = true; > - restore_ffr = true; > + if (system_supports_sve()) { > + switch (current->thread.fp_type) { > + case FP_STATE_FPSIMD: > + /* Stop tracking SVE for this task until next use. */ > + if (test_and_clear_thread_flag(TIF_SVE)) > + sve_user_disable(); > + break; > + case FP_STATE_SVE: > + if (!thread_sm_enabled(¤t->thread) && > + !WARN_ON_ONCE(!test_and_set_thread_flag(TIF_SVE))) > + sve_user_enable(); > + > + if (test_thread_flag(TIF_SVE)) > + sve_set_vq(sve_vq_from_vl(task_get_sve_vl(current)) - 1); > + > + restore_sve_regs = true; > + restore_ffr = true; > + break; > + default: > + /* > + * This should never happen, we should always > + * record what we saved when we save. We > + * always at least have the memory allocated > + * for FPSMID registers so try that and hope > + * for the best. > + */ > + WARN_ON_ONCE(1); > + clear_thread_flag(TIF_SVE); > + break; What makes it impossible for FP_STATE_TASK to reach this point? If that's indeed an impossible case, please document it. > + } > } > > /* Restore SME, override SVE register configuration if needed */ > @@ -412,10 +437,8 @@ static void task_fpsimd_load(void) > if (thread_za_enabled(¤t->thread)) > za_load_state(current->thread.za_state); > > - if (thread_sm_enabled(¤t->thread)) { > - restore_sve_regs = true; > + if (thread_sm_enabled(¤t->thread)) > restore_ffr = system_supports_fa64(); > - } > } > > if (restore_sve_regs) { Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel