On Tue, 20 Dec 2022 at 16:04, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2022-12-20 at 11:43 +0800, Dave Young wrote: > > Hi Ard, > > > > Real time kernels usually disable efi runtime for latency issues, > > Could you say a bit more about this? I was under the impression we > only call efi runtime services when asked: for variable or capsule > updates or if you use the EFI RTC. So if you don't use EFI services in > a real time kernel, you shouldn't suffer any latency issues due to > having them enabled. > > > but for some use cases, e.g. when Secure Boot is used kexec needs to > > get the UEFI keys to verify the kernel signatures with > > kexec_file_load syscall. > > It's not just kexec. Without EFI variable services, you won't be able > to update the MoK keys for new kernels either. > I think it is a mistake to disable EFI runtime services on RT kernels. As you both have pointed out, this results in a loss of functionality already, but we have recently introduced ACPI PRMT, which is a replacement for SMM based 'invisible' OEM code, where platform firmware routines invoked by the ACPI AML code are dispatched in the same way as EFI runtime services. As I understand it, there are two reasons for this choice: - EFI runtime services disable preemption - EFI runtime services are permitted to en/disable interrupts temporarily I should point out that the situation has already improved substantially, given that since a couple of years, we no longer keep interrupts disabled at the kernel level while any runtime service is in progress. Given the lack of reported regressions in that time frame, I think we can conclude that running with interrupts enabled is fine. This also means that disabling migration should be sufficient, and disabling preemption is unnecessary, as apparently, the firmware code can generally code with being interrupted, and the firmware does not have any insight into whether it is being interrupted by code running in hardirq, softirq or task context. So that leaves the firmware code's ability to en/disable interrupts altogether. There is nothing we can do about that, but as James points out, the EFI runtime services are basically opt-in already, and you are free not to invoke them (there are some exceptions here - there are some drivers that perform a getvariable() call at bind time iirc). The ACPI PRMT code is platform specific though, but I don't think you can run an RT kernel on those systems in the first place. In summary, I think we should make the firmware calling infrastructure play more nicely with RT, by switching to migrate_disable(), and reassess whether or not they must still be disabled at all times on such kernels.
