From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 0/7] arm64: Make EFI calls preemptible
Date: Fri, 5 Sep 2025 16:45:09 +0100 [thread overview]
Message-ID: <aLsFhe/whtmKyFus@e129823.arm.com> (raw)
In-Reply-To: <20250905133035.275517-9-ardb+git@google.com>
This series looks good to me.
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The arm64 port permits the use of the baseline FP/SIMD register file in
> kernel mode, and no longer requires preemption to be disabled. Now that
> the EFI spec is being clarified to state that EFI runtime services may
> only use baseline FP/SIMD, the fact that EFI may code may use FP/SIMD
> registers (while executing at the same privilege level as the kernel) is
> no longer a reason to disable preemption when invoking them.
>
> This means that the only remaining reason for disabling preemption is
> the fact that the active mm is swapped out and replaced with efi_mm in a
> way that is hidden from the scheduler, and so scheduling is not
> supported currently. However, given that virtually all (*) EFI runtime
> calls are made from the efi_rts_wq workqueue, the efi_mm can simply be
> loaded into the workqueue worker kthread while the call is in progress,
> and this does not require preemption to be disabled.
>
> Note that this is only a partial solution in terms of RT guarantees,
> given that the runtime services execute at the same privilege level as
> the kernel, and can therefore disable interrupts (and therefore
> preemption) directly. But it should prevent scheduling latency spikes
> for EFI calls that simply take a long time to run to completion.
>
> Changes since v1/RFC:
> - Disable uaccess for SWPAN before updating the preserved TTBR0 value
> - Document why disabling migration is needed
> - Rebase onto v6.17-rc1
>
> (*) only efi_reset_system() and EFI pstore invoke EFI runtime services
> without going through the workqueue, and the latter only when saving
> a kernel oops log to the EFI varstore
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
>
> Ard Biesheuvel (7):
> efi: Add missing static initializer for efi_mm::cpus_allowed_lock
> efi/runtime: Return success/failure from arch_efi_call_virt_setup()
> efi/runtime: Deal with arch_efi_call_virt_setup() returning failure
> arm64/fpsimd: Don't warn when EFI execution context is preemptible
> arm64/efi: Use a semaphore to protect the EFI stack and FP/SIMD state
> arm64/efi: Move uaccess en/disable out of efi_set_pgd()
> arm64/efi: Call EFI runtime services without disabling preemption
>
> arch/arm/include/asm/efi.h | 2 +-
> arch/arm64/include/asm/efi.h | 15 ++----
> arch/arm64/kernel/efi.c | 57 +++++++++++++++++---
> arch/arm64/kernel/fpsimd.c | 4 +-
> arch/loongarch/include/asm/efi.h | 2 +-
> arch/riscv/include/asm/efi.h | 2 +-
> arch/x86/include/asm/efi.h | 2 +-
> arch/x86/platform/efi/efi_32.c | 3 +-
> arch/x86/platform/efi/efi_64.c | 3 +-
> arch/x86/platform/uv/bios_uv.c | 3 +-
> drivers/firmware/efi/efi.c | 3 ++
> drivers/firmware/efi/riscv-runtime.c | 3 +-
> drivers/firmware/efi/runtime-wrappers.c | 20 ++++---
> include/linux/efi.h | 8 +--
> 14 files changed, 89 insertions(+), 38 deletions(-)
>
>
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> --
> 2.51.0.355.g5224444f11-goog
>
>
--
Sincerely,
Yeoreum Yun
next prev parent reply other threads:[~2025-09-05 15:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 13:30 [PATCH v2 0/7] arm64: Make EFI calls preemptible Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 1/7] efi: Add missing static initializer for efi_mm::cpus_allowed_lock Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 2/7] efi/runtime: Return success/failure from arch_efi_call_virt_setup() Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 3/7] efi/runtime: Deal with arch_efi_call_virt_setup() returning failure Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 4/7] arm64/fpsimd: Don't warn when EFI execution context is preemptible Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 5/7] arm64/efi: Use a semaphore to protect the EFI stack and FP/SIMD state Ard Biesheuvel
2025-09-05 13:44 ` Peter Zijlstra
2025-09-05 13:54 ` Ard Biesheuvel
2025-09-08 15:37 ` Peter Zijlstra
2025-09-05 13:30 ` [PATCH v2 6/7] arm64/efi: Move uaccess en/disable out of efi_set_pgd() Ard Biesheuvel
2025-09-05 13:30 ` [PATCH v2 7/7] arm64/efi: Call EFI runtime services without disabling preemption Ard Biesheuvel
2025-09-05 15:45 ` Yeoreum Yun [this message]
2025-09-15 8:52 ` [PATCH v2 0/7] arm64: Make EFI calls preemptible Sebastian Andrzej Siewior
2025-09-15 9:05 ` Ard Biesheuvel
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=aLsFhe/whtmKyFus@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.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