Received-SPF: pass (google.com: domain of linux-crypto+bounces-716-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Will Deacon <will@kernel.org>
To: Ard Biesheuvel <ardb@google.com>,
	linux-arm-kernel@lists.infradead.org
Cc: catalin.marinas@arm.com,
	kernel-team@android.com,
	Will Deacon <will@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Eric Biggers <ebiggers@google.com>,
	Kees Cook <keescook@chromium.org>,
	Marc Zyngier <maz@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH v4 0/4] arm64: Run kernel mode NEON with preemption enabled
Date: Mon, 11 Dec 2023 20:27:27 +0000
Message-Id: <170231871028.1857077.10318072500676133330.b4-ty@kernel.org>
In-Reply-To: <20231208113218.3001940-6-ardb@google.com>
References: <20231208113218.3001940-6-ardb@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hey Ard,

On Fri, 8 Dec 2023 12:32:19 +0100, Ard Biesheuvel wrote:
> 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.
> 
> [...]

I applied the first three patches to for-next/fpsimd:

[1/4] arm64: fpsimd: Drop unneeded 'busy' flag
      https://git.kernel.org/arm64/c/e109130b0e5e
[2/4] arm64: fpsimd: Preserve/restore kernel mode NEON at context switch
      https://git.kernel.org/arm64/c/1e3a3de1ff6c
[3/4] arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD
      https://git.kernel.org/arm64/c/035262623959

It would be nice to have an Ack from Herbert on the last one so that
he's aware of the possible conflicts.

The other thing I tangentially wondered about is what happens now if code
calls uaccess routines (e.g. get_user()) within a kernel_neon_{begin,end}
section? I think previously the fact that preemption had to be disabled
would've caused the might_fault() to explode, but now I suppose the BUG_ON()
in kernel_neon_begin() will save us. Is that right?

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev