On Thu, 22 Dec 2022 at 20:10, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > 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. > Ard, interesting point, thanks. Let's see how RT people thinks about your proposal. Thanks Dave
