Re: [PATCH] efi: runtime-wrappers: run UEFI Runtime Services with interrupts enabled

[Matt Fleming]

On Thu, 04 Feb, at 02:58:47PM, Ard Biesheuvel wrote:
> OK, since Sai has confirmed that Windows leaves interrupts enabled when
> calling the EFI variable store related runtime services, we should be able
> to do the same for Linux, or at least be slightly more confident that we
> won't have to back out this change later.
> 
> @Sai: could you please confirm on-list as well? Thanks.
> 
> Below is an updated version of the patch, rebased onto current tip/efi/core,
> with the BUG_ON() removed that I left in inadvertently. I also added a mention
> in the commit log that Windows leaves interrupts enabled as well. As far as
> annotating the definition of efi_runtime_lock is concerned, the existing ~40
> lines of documentation should be sufficient imo so I left that as is. Thanks.
> 
> --------8<----------------
> The UEFI spec allows Runtime Services to be invoked with interrupts
> enabled. The only reason we were disabling interrupts was to prevent
> recursive calls into the services on the same CPU, which will lead to
> deadlock. However, the only context where such invocations may occur
> legally is from efi-pstore via efivars, and that code has been updated
> to call a non-blocking alternative when invoked from a non-interruptible
> context.
> 
> So instead, update the ordinary, blocking UEFI Runtime Services wrappers
> to execute with interrupts enabled. This aims to prevent excessive interrupt
> latencies on uniprocessor platforms with slow variable stores.
> 
> Note that other OSes such as Windows call UEFI Runtime Services with
> interrupts enabled as well.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> ---
>  drivers/firmware/efi/runtime-wrappers.c | 71 ++++++++------------
>  1 file changed, 28 insertions(+), 43 deletions(-)

Ingo, if you want to pick up this patch directly you can add my,

Reviewed-by: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>

Otherwise let me know and I'll send you a pull request.