[PATCH v2 0/2] efi: Expose the runtime-services workqueue via sysfs
From: Sebastian Andrzej Siewior
Date: Fri Feb 27 2026 - 12:08:05 EST
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 an x86 while a call is made into EFI.
Even if it does not (as it is the case on arm64) the EFI function can
disable interrupts. This makes the time spent in EFI is not
deterministic.
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.
v1…v2: https://lore.kernel.org/all/20260205115559.1625236-1-bigeasy@xxxxxxxxxxxxx/
- For BH and WQ_ORDERED worker make the max_active RO.
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 | 28 ++++++++++++++++++++--------
2 files changed, 21 insertions(+), 9 deletions(-)
--
2.51.0