From: Ard Biesheuvel <ardb@google.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-crypto@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Kees Cook <keescook@chromium.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
Eric Biggers <ebiggers@google.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled
Date: Fri, 8 Dec 2023 12:32:19 +0100 [thread overview]
Message-ID: <20231208113218.3001940-6-ardb@google.com> (raw)
From: Ard Biesheuvel <ardb@kernel.org>
Currently, kernel mode NEON (SIMD) support is implemented in a way that
requires preemption to be disabled while the SIMD registers are live.
The reason for this is that those registers are not in the set that is
preserved/restored on exception entry/exit and context switch, as this
would impact performance generally, even for workloads where kernel mode
SIMD is not the bottleneck.
However, doing substantial work with preemption disabled is not great,
as it affects scheduling latency, which is especially problematic for
real-time use cases. So ideally, we should keep preemption enabled when
we can, and find another way to ensure that this does not corrupt the
NEON register state of in-kernel SIMD users.
This series implements a suggestion by Mark Rutland, and introduces a
thread_info flag TIF_KERNEL_FPSTATE, which indicates to the thread
switch machinery that the task in question has live kernel mode SIMD
state which needs to be preserved and restored. The space needed for
this is allocated in thread_struct. (*)
Given that currently, we run kernel mode NEON with softirqs disabled (to
avoid the need for preserving kernel mode NEON context belonging to task
context while the SIMD unit is being used by code running in softirq
context), just removing the preempt_disable/enable calls is not
sufficient, and we also need to leave softirqs enabled. This means that
we may need to preserve kernel mode NEON state not only on a context
switch, but also when code running in softirq context takes ownership of
the SIMD unit, but this is straight-forward once we add the scratch
space to thread_struct. (On PREEMPT_RT, softirqs execute with preemption
enabled, making kernel mode FPSIMD in softirq context preemptible as
well. We rely on the fact that the task that hosts the softirq dispatch
logic does not itself use kernel mode FPSIMD in task context to ensure
that there is only a single kernel mode FPSIMD state that may need to be
preserved and restored.)
(*) We might decide to allocate this space (~512 bytes) dynamically, if
the thread_struct memory footprint causes issues. However, we should
also explore doing the same for the user space FPSIMD state, as kernel
threads never return to user space and have no need for this allocation.
v4:
- for the time being, make the existing yield logic depend on
CONFIG_PREEMPT_VOLUNTARY, so it can be retired once the prerequisite
core preempt changes (which remove CONFIG_PREEMPT_VOLUNTARY) have been
merged [0]
- incorporate feedback from Mark Rutland and include his acks
v3:
- add patch to drop yield logic from crypto C glue code
- add R-b from Mark
v2:
- tweak some commit logs for clarity
- integrate with the existing lazy restore logic
- add Mark's R-b to patch #1
[0] https://lore.kernel.org/lkml/20231107215742.363031-1-ankur.a.arora@oracle.com/
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Ard Biesheuvel (4):
arm64: fpsimd: Drop unneeded 'busy' flag
arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
arm64: crypto: Disable yielding logic unless
CONFIG_PREEMPT_VOLUNTARY=y
arch/arm64/crypto/aes-ce-ccm-glue.c | 8 +-
arch/arm64/crypto/chacha-neon-glue.c | 5 +-
arch/arm64/crypto/crct10dif-ce-glue.c | 6 +-
arch/arm64/crypto/nhpoly1305-neon-glue.c | 5 +-
arch/arm64/crypto/poly1305-glue.c | 5 +-
arch/arm64/crypto/polyval-ce-glue.c | 9 +-
arch/arm64/include/asm/assembler.h | 4 +-
arch/arm64/include/asm/processor.h | 3 +
arch/arm64/include/asm/simd.h | 11 +-
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/fpsimd.c | 163 +++++++++++++-------
11 files changed, 140 insertions(+), 80 deletions(-)
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2023-12-08 11:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 11:32 Ard Biesheuvel [this message]
2023-12-08 11:32 ` [PATCH v4 1/4] arm64: fpsimd: Drop unneeded 'busy' flag Ard Biesheuvel
2023-12-12 11:27 ` Geert Uytterhoeven
2023-12-12 12:29 ` Will Deacon
2023-12-12 12:34 ` Geert Uytterhoeven
2023-12-12 12:59 ` Ard Biesheuvel
2023-12-12 13:54 ` Geert Uytterhoeven
2023-12-08 11:32 ` [PATCH v4 2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at context switch Ard Biesheuvel
2023-12-08 11:32 ` [PATCH v4 3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD Ard Biesheuvel
2023-12-08 11:32 ` [PATCH v4 4/4] arm64: crypto: Disable yielding logic unless CONFIG_PREEMPT_VOLUNTARY=y Ard Biesheuvel
2023-12-11 20:27 ` [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled Will Deacon
2023-12-12 8:16 ` Ard Biesheuvel
2023-12-12 10:55 ` Will Deacon
2023-12-12 16:35 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231208113218.3001940-6-ardb@google.com \
--to=ardb@google.com \
--cc=ardb@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ebiggers@google.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).