public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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