From patchwork Thu Dec 28 01:41:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Samuel Holland X-Patchwork-Id: 183610 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp1758349dyb; Wed, 27 Dec 2023 17:43:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IHUDOR4+TFdfIONOoqKkD2/yQAorek13zRqm/y5g/3cpZ2IalFJE7jsSfgYINCDmTD0Pncm X-Received: by 2002:a2e:9442:0:b0:2cc:72af:7cfb with SMTP id o2-20020a2e9442000000b002cc72af7cfbmr3694561ljh.26.1703727799805; Wed, 27 Dec 2023 17:43:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703727799; cv=none; d=google.com; s=arc-20160816; b=U6hIK6ys0XvAAqWck9eH89XInX3vl1myILuqxl3zc4puyMoLuUiUlAsK+zgVoPlcON PxGVipHar5hVyIY0DUVJzEc8gC9JPXyAC5VKTJVe/kyaDe9UQqlPBCSCIqTwNsV7NS1l BmVj0i03BgVVodlhsDeRGddF8zqPaGadp/AppFyQfxGwTJNVSEZsGzkTq/eQwxDJKE6y IQiAegvNPyPKwR76/mdeWAu00JG5TZOwfQ8ljU40fa4D49DY3BA9Cdtw+BcT+zRt6dip hoPpHJuEV9Lcd/U3AR8xaNpZrzPojuw06Lbseh41YD5dLf/ogkDJjCyOm1ULq4POxwkY CkgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=oKGphS+JVbRrpyRYNMXZcp4xlaDyNlE0PfrLYNqYsRU=; fh=94uOV5sWmRw3BrY72TFM31lKigqzeHCm+E+w2ZFcL9E=; b=sqT1xrgX3WzOz7R9Po2u/gokrOZ/k+9eL7G/xcYEDvNXM0n67FaKpWYoLz+6yJa2nG IAjJKuQJEx6/gIfK+bFoIvdwoXkU29MEMppKr6qDveV+NIPunKeRQqRr/ygd5fdEL30L XBq6wiN28A1lnz62QVR8OZBAJXuGhAZZWRncLw1XE08hDlypVmZvxA+f55smInhPhb2D rk+wd8hBHmIYCrvQiyIY8FQbAvnO8L0dIVwzj1UVHVAZJCa4kU/s4aXLbSU+3SwqVbsq V+Qp7jV4ofLK/hR0bbhMYtgehChGHKvUrU/A7wWlvfJBT3Rfdp+K8qjcVZbSlwiMEAiM 2vpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=dYxiGMkR; spf=pass (google.com: domain of linux-kernel+bounces-12369-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12369-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id 22-20020a508e56000000b0055411420e18si6535347edx.232.2023.12.27.17.43.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Dec 2023 17:43:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-12369-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=dYxiGMkR; spf=pass (google.com: domain of linux-kernel+bounces-12369-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12369-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 389971F212C1 for ; Thu, 28 Dec 2023 01:43:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 167085232; Thu, 28 Dec 2023 01:42:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="dYxiGMkR" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D925D1396 for ; Thu, 28 Dec 2023 01:42:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3bbd11b2f95so106904b6e.0 for ; Wed, 27 Dec 2023 17:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1703727744; x=1704332544; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oKGphS+JVbRrpyRYNMXZcp4xlaDyNlE0PfrLYNqYsRU=; b=dYxiGMkR8n7fryIbd7uBY43jviOEm2um6UWd7s+0iy6Z7TDynEFdSxvwFnnpybc+Y9 fUJXc74LweXH5Q+/u3YiWvrqBXGlEJrhUOak+MQ8Do0Yc8BKKZnmx9fCgKWa91hlPmcb qNLzP2jTbfW3vqpvjUiXo5yqaLidistyDM7RuVuBvqnWBlk0qa6E3+RUbBKAuFyhRQBe bbpG1YmRgzJwopYLDz1Qmj2NzM27Th4PvyZeVUj09qkcxuOe3ytUY7bQmAHXtAShsuVC 83ePFfCc2HVpwtGztpEiY2w0b/xKwoK+xcGKkJLV3mNfpI5woQLdAEeDtAohHrl3ezFr mQLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703727744; x=1704332544; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oKGphS+JVbRrpyRYNMXZcp4xlaDyNlE0PfrLYNqYsRU=; b=SJG8+ttVrNtwKu/cLvpwo9B9HI0WmXLD3iEHuV0F6EiVRBWH4uksV/m5jsMcEJoGHm kaBoYXHUz7ZjrE2Ts2z6CA/0tKvYRquK0aTN34c7dWt8apd7G55O3ByObCOFCktw7d+a /2qEK8TOG/bAewotPN8VgBL/t94TRsxze94tYg/x6XUWKWCTcEeYvsJcoNhGENTa3wQF +oXDdpVf1L2YkAnS6vH4yKYfXvYrel1sEg6oYYjOzQGuVrit8IOiA+bYYAqgQDhlT5Is PDP/gB1GjD+3xDzpK2jgAODX/ZrYFChMXde3YH4VqU8gKDs1J2DDGgP6SjyHHAwyGu1x dcVg== X-Gm-Message-State: AOJu0Yz1vHF7CCppK0vuEOzy/vF8kKd04r6XqF6F4/K3CcMGq1OaJIPm OYAo72owoh3zJB0arefVQjx2O/gqDFohJg== X-Received: by 2002:aca:2413:0:b0:3bb:c658:40f with SMTP id n19-20020aca2413000000b003bbc658040fmr1920457oic.117.1703727743938; Wed, 27 Dec 2023 17:42:23 -0800 (PST) Received: from sw06.internal.sifive.com ([4.53.31.132]) by smtp.gmail.com with ESMTPSA id g24-20020aa78758000000b006d49ed3effasm7335440pfo.63.2023.12.27.17.42.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Dec 2023 17:42:23 -0800 (PST) From: Samuel Holland To: linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-riscv@lists.infradead.org, Christoph Hellwig Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-arch@vger.kernel.org, Samuel Holland , Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH v2 01/14] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT Date: Wed, 27 Dec 2023 17:41:51 -0800 Message-ID: <20231228014220.3562640-2-samuel.holland@sifive.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231228014220.3562640-1-samuel.holland@sifive.com> References: <20231228014220.3562640-1-samuel.holland@sifive.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786488081183144620 X-GMAIL-MSGID: 1786488081183144620 Several architectures provide an API to enable the FPU and run floating-point SIMD code in kernel space. However, the function names, header locations, and semantics are inconsistent across architectures, and FPU support may be gated behind other Kconfig options. Provide a standard way for architectures to declare that kernel space FPU support is available. Architectures selecting this option must implement what is currently the most common API (kernel_fpu_begin() and kernel_fpu_end(), plus a new function kernel_fpu_available()) and provide the appropriate CFLAGS for compiling floating-point C code. Suggested-by: Christoph Hellwig Signed-off-by: Samuel Holland Reviewed-by: Christoph Hellwig --- Changes in v2: - Add documentation explaining the built-time and runtime APIs - Add a linux/fpu.h header for generic isolation enforcement Documentation/core-api/floating-point.rst | 78 +++++++++++++++++++++++ Documentation/core-api/index.rst | 1 + Makefile | 5 ++ arch/Kconfig | 6 ++ include/linux/fpu.h | 12 ++++ 5 files changed, 102 insertions(+) create mode 100644 Documentation/core-api/floating-point.rst create mode 100644 include/linux/fpu.h diff --git a/Documentation/core-api/floating-point.rst b/Documentation/core-api/floating-point.rst new file mode 100644 index 000000000000..a8d0d4b05052 --- /dev/null +++ b/Documentation/core-api/floating-point.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Floating-point API +================== + +Kernel code is normally prohibited from using floating-point (FP) registers or +instructions, including the C float and double data types. This rule reduces +system call overhead, because the kernel does not need to save and restore the +userspace floating-point register state. + +However, occasionally drivers or library functions may need to include FP code. +This is supported by isolating the functions containing FP code to a separate +translation unit (a separate source file), and saving/restoring the FP register +state around calls to those functions. This creates "critical sections" of +floating-point usage. + +The reason for this isolation is to prevent the compiler from generating code +touching the FP registers outside these critical sections. Compilers sometimes +use FP registers to optimize inlined ``memcpy`` or variable assignment, as +floating-point registers may be wider than general-purpose registers. + +Usability of floating-point code within the kernel is architecture-specific. +Additionally, because a single kernel may be configured to support platforms +both with and without a floating-point unit, FPU availability must be checked +both at build time and at run time. + +Several architectures implement the generic kernel floating-point API from +``linux/fpu.h``, as described below. Some other architectures implement their +own unique APIs, which are documented separately. + +Build-time API +-------------- + +Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT`` +is enabled. For C code, such code must be placed in a separate file, and that +file must have its compilation flags adjusted using the following pattern:: + + CFLAGS_foo.o += $(CC_FLAGS_FPU) + CFLAGS_REMOVE_foo.o += $(CC_FLAGS_NO_FPU) + +Architectures are expected to define one or both of these variables in their +top-level Makefile as needed. For example:: + + CC_FLAGS_FPU := -mhard-float + +or:: + + CC_FLAGS_NO_FPU := -msoft-float + +Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``. + +Runtime API +----------- + +The runtime API is provided in ``linux/fpu.h``. This header cannot be included +from files implementing FP code (those with their compilation flags adjusted as +above). Instead, it must be included when defining the FP critical sections. + +.. c:function:: bool kernel_fpu_available( void ) + + This function reports if floating-point code can be used on this CPU or + platform. The value returned by this function is not expected to change + at runtime, so it only needs to be called once, not before every + critical section. + +.. c:function:: void kernel_fpu_begin( void ) + void kernel_fpu_end( void ) + + These functions create a floating-point critical section. It is only + valid to call ``kernel_fpu_begin()`` after a previous call to + ``kernel_fpu_available()`` returned ``true``. These functions are only + guaranteed to be callable from (preemptible or non-preemptible) process + context. + + Preemption may be disabled inside critical sections, so their size + should be minimized. They are *not* required to be reentrant. If the + caller expects to nest critical sections, it must implement its own + reference counting. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 7a3a08d81f11..974beccd671f 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -48,6 +48,7 @@ Library functionality that is used throughout the kernel. errseq wrappers/atomic_t wrappers/atomic_bitops + floating-point Low level entry and exit ======================== diff --git a/Makefile b/Makefile index ee995fc2b0e5..79c9e0b56ab8 100644 --- a/Makefile +++ b/Makefile @@ -969,6 +969,11 @@ KBUILD_CFLAGS += $(CC_FLAGS_CFI) export CC_FLAGS_CFI endif +# Architectures can define flags to add/remove for floating-point support +CC_FLAGS_FPU += -D_LINUX_FPU_COMPILATION_UNIT +export CC_FLAGS_FPU +export CC_FLAGS_NO_FPU + ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0) KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT) endif diff --git a/arch/Kconfig b/arch/Kconfig index f4b210ab0612..e1c01ce819ed 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1478,6 +1478,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG address translations. Page table walkers that clear the accessed bit may use this capability to reduce their search space. +config ARCH_HAS_KERNEL_FPU_SUPPORT + bool + help + Architectures that select this option can run floating-point code in + the kernel, as described in Documentation/core-api/floating-point.rst. + source "kernel/gcov/Kconfig" source "scripts/gcc-plugins/Kconfig" diff --git a/include/linux/fpu.h b/include/linux/fpu.h new file mode 100644 index 000000000000..2fb63e22913b --- /dev/null +++ b/include/linux/fpu.h @@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _LINUX_FPU_H +#define _LINUX_FPU_H + +#ifdef _LINUX_FPU_COMPILATION_UNIT +#error FP code must be compiled separately. See Documentation/core-api/floating-point.rst. +#endif + +#include + +#endif