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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7719CC54EE9 for ; Tue, 20 Sep 2022 18:20:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 126414B637; Tue, 20 Sep 2022 14:20:07 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK-tj7Kv3P4v; Tue, 20 Sep 2022 14:20:05 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E25A54B62E; Tue, 20 Sep 2022 14:20:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E3B274B62C for ; Tue, 20 Sep 2022 14:20:04 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwwXwRD0g97l for ; Tue, 20 Sep 2022 14:20:02 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 8B1BC4B2A5 for ; Tue, 20 Sep 2022 14:20:02 -0400 (EDT) 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 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 Cc: Catalin Marinas , Zhang Lei , Andre Przywara , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm