From patchwork Wed Mar 27 20:00:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Samuel Holland X-Patchwork-Id: 13607396 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 68F5CC47DD9 for ; Wed, 27 Mar 2024 20:02:54 +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:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=sWfCNe5e6qYR5WVey8G1LzODv5TVNsJh49QRk4mm76E=; b=iJs6IULJ/ffeUD 4G0aIL2dfX1bprqstLaVjhiGz2iqNs20XpgmrDaM0SY9z3+4T5BoS8J3HzOdt2x4a36j+dtawlYKc UPdFB4sTML9gd6y3VTd/F2KKb7nxHREYRJ7lrAgAp6GXonADZuiGp8k01BscFAMocSl2WT5M/XORw yv+WccCoROh8JKDbvc9Hqe4GGO4cDSEhG5WN2WZ0Slfb+734+FvBOFzFBAAZRyZ4julj56uzPs6xl U51aeopfg5T/2rkJXe7C+ajllgy6YNJ0kcvskqY+TVUols3yi62E8QT/qsSVE1IAStDNAGcHiW1gt pdkZ5/cW1MXU+oRT9fcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpZU3-0000000AuUR-16nz; Wed, 27 Mar 2024 20:02:51 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpZTM-0000000Atxi-1yw2 for linux-riscv@lists.infradead.org; Wed, 27 Mar 2024 20:02:14 +0000 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1e0189323b4so1643755ad.1 for ; Wed, 27 Mar 2024 13:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1711569720; x=1712174520; darn=lists.infradead.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=ypWDQztlaUl0OBgzt8wXnA3vBiMMRAqmq7IofZwnoZI=; b=Qaouox/YuyYg39S+hprBvQ6fAPW3kcbSXckHsNT/GFflqMtYAxLR029Fugn5XN9b0y x4F8Y7bjJLGmkouGfUO7Dc27hr1G62d4pdo4+bGGzGX38QV0HhlA63TinWJStuntwgUt Qey5iyZO6UcXICU6dMlt+NVbH2+Udt7/C7q1cy1hD3VrLSHLBEHh0qh7gPV/WWeBeIGx j2+X+YfdE1AVbWgO1YTqwTeOQs52NFADQ4fPlAPxYpfFf/3/m14I+9O07IJlW7U1KCEv MSnRYl/x3aHb8tU1Q9z6ZhTYDlh+a8wlux2px7hBX3wNPwQubbqAeRuJNfLwb8ZnJM+8 o5WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711569720; x=1712174520; 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=ypWDQztlaUl0OBgzt8wXnA3vBiMMRAqmq7IofZwnoZI=; b=BXMqg/FYeJ4xWJlEHSRuh2mvtUoIP3uHpYQxAy3XRoGlJQbBKz+ndH6HdtNQ9DYlgR 4n8hLcoIOAGjYgEt71sUqBV5GtM5tGV8SsbrPFv/xyfDUAkzK3jzzIrQFLMQ6Pd8DrSi taS1y3sCjcB48h2xOGaY6vYvcqDwoTyGT6GlKKKfJ6jidN2uhfXSkEIjdvnDLBPO/PuR kDwA4RxEP5PRQsZVwaVQTbZ/eZqTTmFIfNx4n1J5BoflzCiD0zVYGifx6XGB7v47xrwI IMkuJ5ZTGC7Tot5dNZsEPg/b8/MOASEKxWsNp7MiZuMu8KUSGyoo44xHQTVQev5rh6Oy jIew== X-Forwarded-Encrypted: i=1; AJvYcCXTQxYygYtoCRMB6x8o5rWEDAmDpiRFwdDl72R+nodG2QhXcz68+g+e0C5OiOhHYN8w5ENVIuk61vucsh4mb7qbD0U9ephn9+Tuq7LexsM+ X-Gm-Message-State: AOJu0YymXU7qIVP5qhnW3OX/B/b6hCi12YYkuEOMkxMtoCVwT42dLxbL P3yavdewk5rDenWfqgvffHQLE5vE+qBqRb3vnN2Wi5EqXuILW5QilztG/Cx4Us8= X-Google-Smtp-Source: AGHT+IG/guZZUh1z8VBs2UBKbikNm/ct62HN1I/AjguyoIM/V4kgoDEmkJWsd5kFsvUg8c6UkAoepg== X-Received: by 2002:a17:903:1251:b0:1e0:f366:13e5 with SMTP id u17-20020a170903125100b001e0f36613e5mr876644plh.61.1711569720448; Wed, 27 Mar 2024 13:02:00 -0700 (PDT) Received: from sw06.internal.sifive.com ([4.53.31.132]) by smtp.gmail.com with ESMTPSA id u4-20020a170902e5c400b001dd0d0d26a4sm9446459plf.147.2024.03.27.13.01.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 13:02:00 -0700 (PDT) From: Samuel Holland To: Andrew Morton , linux-arm-kernel@lists.infradead.org, x86@kernel.org Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, Christoph Hellwig , loongarch@lists.linux.dev, amd-gfx@lists.freedesktop.org, Samuel Holland , Borislav Petkov , Catalin Marinas , Dave Hansen , Huacai Chen , Ingo Molnar , Jonathan Corbet , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Russell King , Thomas Gleixner , Will Deacon , linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org Subject: [PATCH v3 01/14] arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT Date: Wed, 27 Mar 2024 13:00:32 -0700 Message-ID: <20240327200157.1097089-2-samuel.holland@sifive.com> X-Mailer: git-send-email 2.43.1 In-Reply-To: <20240327200157.1097089-1-samuel.holland@sifive.com> References: <20240327200157.1097089-1-samuel.holland@sifive.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240327_130208_731469_709B2470 X-CRM114-Status: GOOD ( 29.61 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 Reviewed-by: Christoph Hellwig Signed-off-by: Samuel Holland --- (no changes since v2) 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 763b6792d3d5..710f65e4249d 100644 --- a/Makefile +++ b/Makefile @@ -964,6 +964,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) # Set the minimal function alignment. Use the newer GCC option # -fmin-function-alignment if it is available, or fall back to -falign-funtions. diff --git a/arch/Kconfig b/arch/Kconfig index 9f066785bb71..8e34b3acf73d 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1569,6 +1569,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