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 3EF31C433F5 for ; Tue, 22 Feb 2022 12:11:17 +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=ZNBjNIAuFVyT91/o6NT0OII5W03S6ZpPJGYn0OkD2dI=; b=tccGqH1RcY1PID o4aLDagPApF+4LEmeTui/7Lb7zFskcyVxHI9Q7DUJjANF2DkQS6gfq256q+CXuzS2fCjfP1dn9fRJ TUBqzwLlShFWgWYy1OQu2Flt5pfW/AOAbu8xWi9Jey7yHGc5F9er2SY+qMIpNJ2imryBIfet2EONd C5LewUceoz+hn4L6vpz4bHf5A/bw5lX+34UaI42Y0GcFL3vcDpaEa4qdQQyjOiHX6i6mhGpLdYh8B QyQJqAx/uWGXYLlrfEukTAYX0w4rBLXpEmkN3yedWPL2ZnvnyGGqXqIaMeLDtuYVwPs5ZCINvWj+h GUgMVz8Um701yzv0F/Sw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMTzJ-009VbQ-6h; Tue, 22 Feb 2022 12:09:49 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nMTzF-009Va8-4r for linux-arm-kernel@lists.infradead.org; Tue, 22 Feb 2022 12:09:47 +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 190DE60EFD; Tue, 22 Feb 2022 12:09:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A39F0C340E8; Tue, 22 Feb 2022 12:09:40 +0000 (UTC) Date: Tue, 22 Feb 2022 12:09:37 +0000 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Marc Zyngier , Shuah Khan , Shuah Khan , Alan Hayward , Luis Machado , Salil Akerkar , Basant Kumar Dwivedi , Szabolcs Nagy , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v11 10/40] arm64/sme: Basic enumeration support Message-ID: References: <20220207152109.197566-1-broonie@kernel.org> <20220207152109.197566-11-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220222_040945_272924_DC9CAECE X-CRM114-Status: GOOD ( 33.27 ) 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, Feb 21, 2022 at 11:10:34PM +0000, Mark Brown wrote: > On Mon, Feb 21, 2022 at 07:24:59PM +0000, Catalin Marinas wrote: > > On Mon, Feb 21, 2022 at 03:01:03PM +0000, Mark Brown wrote: > > > We do run the kernel in streaming mode - entering the kernel through a > > > syscall or preemption will not change the streaming mode state, and we > > > need to be in streaming mode in order to save or restore the register > > > state for streaming mode. In particular we need FA64 enabled for EL1 in > > > order to context switch FFR when in streaming mode, without it we'll > > > generate an exception when we execute the rdffr or wrffr. We don't do > > > any real floating point work in streaming mode but we absolutely need to > > > run in streaming mode and only exit streaming mode when restoring a > > > context where it is disabled, when using floating point in the kernel or > > > when idling the CPU. > > > So, IIUC, for Linux it is mandatory that FEAT_SME_FA64 is supported, > > otherwise we won't be able to enable SME. Does the architecture say > > The feature is not mandatory and we do not require it for Linux. It is > expected that many implementations will choose to not support FA64. > > The only impact it has on the kernel is that if it's present then we > need to enable it for each EL and then context switch FFR in streaming > mode, the code is there to do that conditionally already. OK, I get it. So FFR is only present if FA64 is supported. > This is actually a bit awkward for not disabling streaming mode when we > do a syscall since the disabled instructions include the FPSMID mov > vector, vector instruction which we currently use to zero the high bits > of the Z registers. That issue goes away if the optimisations I've got > for relaxed flushing of the non-shared SVE state that we discussed in > relation to syscall-abi get merged, though it'd still be there if we add > a sysctl to force flushing. This is a solvable problem though, even if > we have to use a less efficient sequence to flush in streaming mode. I guess the simplest is to just disable streaming mode on syscall. The C library would mark the syscall wrappers as not streaming compatible, so whoever is calling them might disable SM anyway. So I think your original proposal in the ABI doc is fine (I just need the libc people to confirm ;)). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel