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 0E0D7EB64DA for ; Thu, 20 Jul 2023 10:53:02 +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=5QQnsl6GIIeUhW+iXipmeL3hZ7+S/ntGBDeeCkNPW/c=; b=N7UH4Jz4KZ3/st 3rS3IlrapoX4DU7RBCtwLtCaOuovZvjnrCNE53c3bbQjQr8gji6KPTs0EfysuqCWIhIgWrkJbl0xg 5cjAeZHwnPlg/F2C5WgAqlHNoubaybgKhx2DM6EP3AKdt4SmdIOx8Y+UEmqt9YwW2hDnoc3FM4zJ2 vvsyaebWDg5iENNGPRVDZK3weDB1yWEs5enQwPmhq9v4Vt1xCKbrtcdiH3Sl4lUjYAog/eLZVRk1R iva1OCbnUro6a+LjA00NyyUdhs4iSt9FyiboevgxnQZcjN6vK6VT2DTC8x0to5SXmhsBIF4hSERa1 o13ohLcCwV5r7eTo29ag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMRH3-00Atcl-0D; Thu, 20 Jul 2023 10:52:45 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qMRH0-00AtcA-2h for linux-arm-kernel@lists.infradead.org; Thu, 20 Jul 2023 10:52:44 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 43EC761A0C; Thu, 20 Jul 2023 10:52:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 053B3C433C8; Thu, 20 Jul 2023 10:52:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689850361; bh=PiRPsNTu3ZoxabFGwoYJ4bs4XlF9WqCHpONj7mkDnk8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X2kSefCsQUr6rv7Myphpg5jQl+JDzG9RNrwiQWlrGbNOWMqhge0LNb/s/yo4kA/d7 vQl+7zWRcyUzfZzxlnUyCBmJGH+8QIO1K9H3S0gRUfSdtnxp1dpqHEXR4wksJbyCFG nUFlC8RsVGkMl1J7l/k6sa7PzQSH/ydMk42obYYYrs6Wbdxikzu186hE0wpsZjkZwX JG9HfU3rzvh7xVWJAFQYBtHMT8afV3bksmMojC7nF+QXMpA7HhOJRi+bwGysZjdVc3 KDcQXIL1uPdd6ekjKDhNL8SY18kX1xMnHdGEpL7jaubKiOOOoBRdSX5KRddhNXendO KweixedEavBsQ== Date: Thu, 20 Jul 2023 11:52:36 +0100 From: Will Deacon To: Mark Brown Cc: Catalin Marinas , Shuah Khan , David Spickett , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/3] arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes Message-ID: <20230720105235.GD11034@willie-the-truck> References: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@kernel.org> <20230713-arm64-fix-sve-sme-vl-change-v1-1-129dd8611413@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230713-arm64-fix-sve-sme-vl-change-v1-1-129dd8611413@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-20230720_035242_915904_FFCA2150 X-CRM114-Status: GOOD ( 14.10 ) 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 Thu, Jul 13, 2023 at 09:06:04PM +0100, Mark Brown wrote: > When we reconfigure the SVE vector length we discard the backing storage > for the SVE vectors and then reallocate on next SVE use, leaving the SME > specific state alone. This means that we do not enable SME traps if they > were already disabled. That means that userspace code can enter streaming > mode without trapping, putting the task in a state where if we try to save > the state of the task we will fault. > > Since the ABI does not specify that changing the SVE vector length disturbs > SME state, and since SVE code may not be aware of SME code in the process, > we shouldn't simply discard any ZA state. Instead immediately reallocate > the storage for SVE if SME is active, and disable SME if we change the SVE > vector length while there is no SME state active. What is the advantage of keep the old behaviour in this case? In other words, if it's acceptable to reallocate the state when SME is active, why not just reallocate in all cases? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel