On Tue, Mar 18, 2025 at 02:24:22PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@xxxxxxxxxx>
>
> The EFI specification has some elaborate rules about which runtime
> services may be called while another runtime service call is already in
> progress. In Linux, however, for simplicity, all EFI runtime service
> invocations are serialized via the efi_runtime_lock semaphore.
> This implies that calls to the helper pair arch_efi_call_virt_setup()
> and arch_efi_call_virt_teardown() are serialized too, and are guaranteed
> not to nest. Furthermore, the arm64 arch code has its own spinlock to
> serialize use of the EFI runtime stack, of which only a single instance
> exists.
> This all means that the FP/SIMD and SVE state preserve/restore logic in
> __efi_fpsimd_begin() and __efi_fpsimd_end() are also serialized, and
> only a single instance of the associated per-CPU variables can ever be
> in use at the same time. There is therefore no need at all for per-CPU
> variables here, and they can all be replaced with singleton instances.
> This saves a non-trivial amount of memory on systems with many CPUs.
That makes life a lot easier all round, and like you say the memory
savings are nice.
Reviewed-by: Mark Brown <broonie@xxxxxxxxxx>
> - if (system_supports_sve() && likely(efi_sve_state)) {
> - char *sve_state = this_cpu_ptr(efi_sve_state);
> + if (system_supports_sve() && efi_sve_state != NULL) {
The change does remove a bunch of these likely() annotations, though the
chances that they were ever having an impact seem minimal.
Attachment:
signature.asc
Description: PGP signature
