Re: [PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs

["Ard Biesheuvel" <ardb@kernel.org>]

Hello Sebastian,

On Thu, 5 Feb 2026, at 12:55, Sebastian Andrzej Siewior wrote:
> EFI runtime services are disabled on PREEMPT_RT by default which can be
> overwritten on the boot command line. For native EFI, an invocation
> requires to disable preemption while a call is made into EFI.

This is no longer true on arm64 since

commit a5baf582f4c026c25a206ac121bceade926aec74
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Wed Oct 15 22:56:42 2025 +0200

    arm64/efi: Call EFI runtime services without disabling preemption

except for some corner cases (reboot, pstore crash dump).

> The time
> spent in EFI is not deterministic and depends on SW and HW of the
> system.
> While accessing the efi-rtc device can be avoided by using a native
> driver, accessing the "variables" is important and there is no second
> path.
>
> The "runtime-wrappers" is wrapping access to the EFI callback via a
> workqueue. On a SMP system one CPU could be declared as housekeeping/
> not-realtime-capable and force all EFI invocation to be performed on
> this CPU. This could be achieved by setting workqueue.unbound_cpus or
> 	/sys/devices/virtual/workqueue/cpumask
>
> at runtime. This however will affect all workqueues and might not be
> desired. With an explicit setting such as
> 	/sys/devices/virtual/workqueue/efi_runtime/cpumask
>
> it looks like an official way to limit the CPUs involved here.
>
> With this in place I was wondering if EFI_DISABLE_RUNTIME could be
> lifted at runtime on SMP systems. But given the unbound_cpus option
> and the auto-config based on NOHZ-full it might not be wise to add yet
> another smart option here. Also it needs to be a subset of root cpumask
> or it won't be effective.
>
> There are two EFI invocations which are not covered by this
> - mixed EFI
>   Used on x86 with 64bit kernel but 32bit EFI. Would it work to use here
>   the same workqueue mechanism?
>

That stuff is beyond obsolete, so I don't think it is relevant for RT.

> - TEE / ARM secure monitor
>   If I understand this right then TEE invokes the secure monitor which
>   is preemptible. So an interrupt will interrupt and enter "normal"
>   world immediately and could wake a user task. The following context
>   switch will not happen because the return from interrupt path goes
>   back to the secure monitor/ TEE.
>   If so, or if TEE may disable interrupts from normal world, would it
>   make sense to use a wrapper here, too?
>
> Any comments or things I have missed?
>
> Sebastian
>
> Sebastian Andrzej Siewior (2):
>   workqueue: Allow to expose ordered workqueues via sysfs
>   efi: Allow to expose the workqueue via sysfs
>
>  drivers/firmware/efi/efi.c |  2 +-
>  kernel/workqueue.c         | 14 +++++++-------
>  2 files changed, 8 insertions(+), 8 deletions(-)
>

Acked-by: Ard Biesheuvel <ardb@kernel.org>