From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751147AbeCILMN (ORCPT ); Fri, 9 Mar 2018 06:12:13 -0500 Received: from mail.skyhub.de ([5.9.137.197]:52298 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbeCILMM (ORCPT ); Fri, 9 Mar 2018 06:12:12 -0500 Date: Fri, 9 Mar 2018 12:11:57 +0100 From: Borislav Petkov To: "Prakhya, Sai Praneeth" Cc: "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Chun-Yi Lee , "Luck, Tony" , Will Deacon , "Hansen, Dave" , Mark Rutland , Bhupesh Sharma , "Neri, Ricardo" , "Shankar, Ravi V" , Matt Fleming , "Zijlstra, Peter" , Ard Biesheuvel , "Williams, Dan J" Subject: Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services() Message-ID: <20180309111157.GC10753@pd.tnic> References: <1520292190-5027-1-git-send-email-sai.praneeth.prakhya@intel.com> <1520292190-5027-3-git-send-email-sai.praneeth.prakhya@intel.com> <20180307121047.GG23662@pd.tnic> <20180308140830.GE21166@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 09, 2018 at 02:37:59AM +0000, Prakhya, Sai Praneeth wrote: > But, I guess, we have some downsides with this design: > 1. We are doing this to have "no exceptions to use efi_rts_wq", but we will be making > the common case complicated. i.e. When a user requests to write some efi variable, So if the pstore use case is so important and special, I think we should make the EFI path as fast as possible as getting that data to the pstore is a priority. > Alternatively, instead of playing around with in_atomic(), we could have wrapper > functions like efi_write_var_non_wq() which will only be used by pstore. This function > will not use efi_rts_wq and directly invoke efi_runtime_service. Just an attempt to > make the code not look messy. I guess. If the write-to-pstore case is such a critical one, I guess the exception is justified. > That's true! AFAIK, we don't have any issues handling NMI while in efi_pgd. > We might have issues only when, we are already in efi_pgd, NMI comes along Can you trigger this? Or is it something hypothetical? > and NMI handler tries to touch the regions that are not mapped in efi_pgd If it is not hypothetical, the NMI handler should learn to look at CR3 first and return if CR3 has the efi pgd. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.