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 79D56C4332F for ; Tue, 15 Nov 2022 11:38:30 +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=ZPB8yopbuSoeo2TYjZ5SDi/mtfUbTT9Gav+zwldI6Tg=; b=oOAv7KxWnMGBwu xhrppTKWmD6iL/HY6SxwmTfrSIbEqs9O6hVbmQeSC9DoNiObuc73bs0oZldTj/ek6gA4GsF0i7FIY n+ZobSn8GDRoD41jxCzQJyrDFkT/xr4wBcrlPlciYYupWQjS0rhK29dvhz6RXVexOsntgfg3FkHFX YCdshlAy9NRdxNdx9OOU+xs6QUsSDppJaerWylmbvTbeq5YQoIekoZEHVFTyDaSTHnK6oNs0xmmtS zMA+vy4x/27kKinMjbcVhwk8IDoeXIsB2LmJY38RXAKVJspOBSMMOs2KXoz9/5tEeSuZf7ABpDsMx Ze9N6D7qgVNkC9o+TzfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouuG4-00AdZs-2j; Tue, 15 Nov 2022 11:37:40 +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 1ouuG1-00AdYN-1T for linux-arm-kernel@lists.infradead.org; Tue, 15 Nov 2022 11:37:38 +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 B92DC616CB; Tue, 15 Nov 2022 11:37:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39A64C433B5; Tue, 15 Nov 2022 11:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668512255; bh=opRh8Y6O0Thd7KS305STdGSOehFsN1kn4/tAVdpAFQg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eEWKr0V7nsyIhcFp/BbbMOzId7d0e1i3lubDjrV4Qdw6PwCR+evUGn0zpWzhVQhZK 1uvEc0EcA7sqwMSNGBL5n7DVAqzyAfhyeSPNds/VUflpevAuO6DqAZIOKyiApwPHDs +Ccjp1NDUm+WQzD1K21wF9f7RtIcBJreG4awtrEFMuD8J9xBkM0wMieZFzjQH08Kn+ WYktsCVyb9qXI1vIm4qW8AR3P4d5doCkXMYRdyu+RcobyOXo/hw2jeqHD9ygxVrOsO YLiCuF313why1zuf0c9L+LtMYEOMwgBPnKVP+Kd4S1PIVarw20dNl44OP7MGl+ZtaL W8ZutH9pF2XMg== Date: Tue, 15 Nov 2022 11:37:30 +0000 From: Will Deacon To: Mark Brown Cc: Catalin Marinas , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] arm64/fpsimd: Add interface for kernel use of SVE and SME Message-ID: <20221115113729.GD32523@willie-the-truck> References: <20221103182105.644166-1-broonie@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221103182105.644166-1-broonie@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-20221115_033737_184992_C3B37269 X-CRM114-Status: GOOD ( 37.83 ) 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, Nov 03, 2022 at 06:21:05PM +0000, Mark Brown wrote: > We currently support in kernel use of FPSIMD via the kernel_neon_begin() > and kernel_neon_end() interface but there is no corresponding interface > for SVE or SME. Given that SVE hardware is now becoming widely available > there is interest in using these more modern floating point instruction > sets for in kernel applications let's add an interface which allows them > to be selected in addition to FPSIMD. > > The sharing of registers and code means that using kernel_neon_begin() > is actually doing most of the setup required, the only problem is that we > are not configuring the vector length so any SVE or SME code would just use > whatever vector length is configured in the hardware potentially leading to > uneven performance on systems which support multiple vector lengths. Add > a new kernel_fp_begin()/end() interface which allows the caller to flag if > it will use SVE or SME and initialises the vector length if requested. > > We allow simultaneous specification of multiple extensions since it is > possible that a user may wish to mix them in a single algorithm, there is > no cost to allowing this. > > Signed-off-by: Mark Brown > --- > > v2: Check for system_supports_sme() for setting the SME VL. > > arch/arm64/include/asm/fpsimd.h | 7 +++++ > arch/arm64/kernel/fpsimd.c | 45 +++++++++++++++++++++++++++++++++ > 2 files changed, 52 insertions(+) > > diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h > index 6f86b7ab6c28..d4045fb73483 100644 > --- a/arch/arm64/include/asm/fpsimd.h > +++ b/arch/arm64/include/asm/fpsimd.h > @@ -44,6 +44,13 @@ > */ > #define SME_VQ_MAX 16 > > +#define KERNEL_FP_FPSIMD 1 > +#define KERNEL_FP_SVE 2 > +#define KERNEL_FP_SME 4 > + > +void kernel_fp_begin(unsigned int flags); > +void kernel_fp_end(void); > + > struct task_struct; > > extern void fpsimd_save_state(struct user_fpsimd_state *state); > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 23834d96d1e7..01a79a8fe9f6 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1858,6 +1858,51 @@ void kernel_neon_end(void) > } > EXPORT_SYMBOL(kernel_neon_end); > > +/** > + * kernel_fp_begin(): obtain the CPU floating point registers for use > + * by the calling context > + * > + * @flags: KERNEL_FP_ flags specifying which FP features will be used. > + * > + * The caller is responsible for ensuring that the requested floating > + * point features are available on the current system. Task context > + * in the registers is saved back to memory as necessary. If SVE or > + * SME support is enabled then the maximum available vector length > + * will be selected. > + * > + * A matching call to kernel_fp_end() must be made before returning from the > + * calling context. > + * > + * The caller may freely use the floating point registers until > + * kernel_fp_end() is called. > + */ > +void kernel_fp_begin(unsigned int flags) > +{ > + kernel_neon_begin(); > + > + if (system_supports_sve() && (flags & KERNEL_FP_SVE)) > + sve_set_vq(sve_vq_from_vl(sve_max_vl()) - 1); > + > + if (system_supports_sme() && (flags & KERNEL_FP_SME)) > + sme_set_vq(sve_vq_from_vl(sme_max_vl()) - 1); > +} > +EXPORT_SYMBOL(kernel_fp_begin); > + > +/** > + * kernel_fp_end(): end kernel usage of the floating point registers > + * > + * Must be called from a context in which kernel_fp_begin() was previously > + * called, with no call to kernel_fp_end() in the meantime. > + * > + * The caller must not use the FPSIMD registers after this function is called, > + * unless kernel_fp_begin() is called again in the meantime. > + */ > +void kernel_fp_end(void) > +{ > + kernel_neon_end(); > +} > +EXPORT_SYMBOL(kernel_fp_end); Hmm, I don't really understand the point of this. Exporting unused symbols to modules has a funny smell to it, so let's leave this until we get an in-tree user (if we decide that we want to support that at all)? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel