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

Sebastian Andrzej Siewior posted 2 patches 1 day, 17 hours ago
drivers/firmware/efi/efi.c |  2 +-
kernel/workqueue.c         | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
[PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs
Posted by Sebastian Andrzej Siewior 1 day, 17 hours ago
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. 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?

- 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(-)

-- 
2.51.0