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 X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8A1BC433DB for ; Wed, 10 Feb 2021 17:56:26 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 430ED64D9E for ; Wed, 10 Feb 2021 17:56:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 430ED64D9E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=eSfHM4/1LzuQgfA1gHDApqpbvkKdwU8HTQjL0CEkLKg=; b=AOZtV13dcvvMR9LpgFBi5dPLU g6tZ4462UJEaFvn88Cg1P6Z3Yo9vur3sSJ7oOLOEI8MkcNxe6vtSIbnVsbyocXjNeITJCd7b0L/jN 0GBAy3F0Z5bhrrXiScxPKY+ikDU9t2GdDT0PnbXIiUB8CHPUQkRKdnh2fO63IEJBFMEt1M33pEL1Y ZAOLBIaporFHh4PoQaf6xtB8RhjlLHcA9Y678m9XZseFTJCdzIf/QXLMsst6gKZmhWUwqIWy15MP3 phpj/2bsl0dprEP9yfVfnNP7o2E8dBSdatKtRp3xM+gZPr2BcbKtd3f+K4ZnxAz/iDX5ChnGhMFsN cfVKVw3RQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9tho-0000By-H0; Wed, 10 Feb 2021 17:55:12 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9thl-0000BX-9c for linux-arm-kernel@lists.infradead.org; Wed, 10 Feb 2021 17:55:10 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CAC0364EDB; Wed, 10 Feb 2021 17:55:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612979708; bh=lrkMaLV6xRbroqhPNULdIckFaDiUmRdNuhmF3yNEhwo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=poDJvvmG26QkAMXEeV1iL1k6MVWfHk3jwD31segACord0NOViHNae/xhrpXbxt1aA 7Ksb9b80Dw9YY5gamB0U191DYQVPCDSGysJpsiThqPUIRIyLM/6ANPjbcWeHr874Mv tnbFz4WikshGUJXLzK+C2S+85KQbH3TPlUG1BHI4taGVWl+T1qTLLNDucWSCYiQfm2 I89Heyuex4sQq7hGvzoarBbwZoTx5C2z5ocyrTSBvspK+QRPXQ+k3cr7lIGKFZNZ9N xvZPfMu6sW1UZMyNO7xiVClrD2oEVUY9lHX8gugVJO1WS9Yw0fWUc7zPyU3PMLXi1q 7V7QfUrwdsvXw== Date: Wed, 10 Feb 2021 17:54:15 +0000 From: Mark Brown To: Dave Martin Subject: Re: [PATCH v7 2/2] arm64/sve: Rework SVE trap access to minimise memory access Message-ID: <20210210175415.GE4748@sirena.org.uk> References: <20210201122901.11331-1-broonie@kernel.org> <20210201122901.11331-3-broonie@kernel.org> <20210210110951.GJ21837@arm.com> MIME-Version: 1.0 In-Reply-To: <20210210110951.GJ21837@arm.com> X-Cookie: Are we live or on tape? 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-20210210_125509_727886_82BFAFBC X-CRM114-Status: GOOD ( 23.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Julien Grall , Catalin Marinas , Zhang Lei , Will Deacon , linux-arm-kernel@lists.infradead.org, Daniel Kiss Content-Type: multipart/mixed; boundary="===============3110396778776527848==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3110396778776527848== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Content-Disposition: inline --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 10, 2021 at 11:09:56AM +0000, Dave Martin wrote: > On Mon, Feb 01, 2021 at 12:29:01PM +0000, Mark Brown wrote: > > + /* > > + * When the FPSIMD state is loaded: > > + * - The return path (see fpsimd_restore_current_state) requires > > + * the vector length to be loaded beforehand. > > + * - We need to rebind the task to the CPU so the newly allocated > > + * SVE state is used when the task is saved. > > + */ > > + if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { > > + sve_set_vq(sve_vq_from_vl(current->thread.sve_vl) - 1); > Hmmm, I can see why we need this here, but it feels slightly odd. > Still, I don't have a better idea. > Logically, this is all part of a single state change, where we > transition from live FPSIMD-only state in the registers to live SVE > state with a pending flush. Although we could wrap that up in a helper, > we only do this particular transition here so I guess factoring it out > may not be worth it. Yes, such a helper would have exactly one user so it's a bit unclear if it's sensible to factor it out. > > + fpsimd_bind_task_to_cpu(); > > + } > > =20 > > put_cpu_fpsimd_context(); > From here, can things go wrong if we get preempted and scheduled out? > I think fpsimd_save() would just set TIF_SVE_FULL_REGS and save out the > full register data, which may contain stale data in the non-FPSIMD bits > because we haven't flushed them yet. > Assuming I've not confused myself here, the same think could probably > happen with Ard's changes if a softirq uses kernel_neon_begin(), causing > fpsimd_save() to get called. I think the issue here is actually in fpsimd_save() which as you said in one of your other mails shouldn't be forcing on TIF_SVE_FULL_REGS, it should just be saving whatever is specified by TIF_SVE_FULL_REGS. That way if we get scheduled between do_sve_acc() and returning to userspace only the FPSIMD registers will be saved and we'll set TIF_SVE_FULL_REGS and do the flush when reloading the registers prior to returning to userspace. --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmAkHcYACgkQJNaLcl1U h9BJlQf/bBV7qgH6MV8PaE0Ag64wBjaHCMexN2C5FlM/v7zBHjU+WoghgoheAug5 pOm8w+0piy197cIYdM6YBchN7Kj1FeWjyxnVuKma/PRSZ2y6rYSTdhRG0Bs2FqDk I8lFvv2qhAmm7iCvDPp5I4rH/wNsMqaHJIEhe4UeuOhnvvzFmk2MZRxyh1+7fdWT ciegN2c2p+863h3W6enyvNK0yU0zLBRrn+eDSUvfeqXUEqnQtRYoUb/13pSyMyw2 MOmvCv6HYj+WC3aLU4gHaXQ19V8+R26iC/fM7TclaotTfOX8tr06hZ34MM3V/dLr O6sgHYSxhVy7hRD4nFa9IoyqZB9l9w== =kaVW -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad-- --===============3110396778776527848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3110396778776527848==--