Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1086088pxb; Fri, 1 Apr 2022 04:20:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BgiXYHhNYFlQZAbWu54XpM0knYakueaFnJmU8wqkRQ5n2i++YiuKv4TjdlWYZYwAWRXI X-Received: by 2002:a50:d48d:0:b0:41a:c9cb:8b90 with SMTP id s13-20020a50d48d000000b0041ac9cb8b90mr20520674edi.299.1648812027683; Fri, 01 Apr 2022 04:20:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648812027; cv=none; d=google.com; s=arc-20160816; b=1AHdmpcHmUGP2FnvCW6sXDxYFJEeDDHn8GA+00g3GCmDT3J8U5U5QytGPvuTojESHl gQc5Yn+F6tchkiNydMgopB9nieHUl1njd2XLoTxj8wo2941bsCg/Isd/sYdyiiW62uXd lpu9N2+0TwJESlCQ4Ugq08B0GcfaN78QXxSYshGPuabQdFr4JXHMiOX2q2EwIspDqklR AqAjkpb7Kn1LKEdt5Yq2Zj17WNTcIe4QTV2f08bkB9xUbyINu0H5pdJJwwR2IxYals85 +xY4BKQtNwQweUqqgYNXOyOr3b9B8e8d4QG94D4H2UWOYiy0+spQ4PiJVZqIx1nskSlX BHrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature :dkim-signature:date; bh=TrMSX3+gQilz8a7VNHdVxgsogGZEoAnFBXl8tPxCkps=; b=Ki0260W9W0jdMQTAZ9YHWakwtXPFFszL68QecDT/DmXPqeOnfEkcryRtHVHWzjl2/d ZLpJVgdly2QpoSW/houC25qWUTyMffB1Q/W7UiFtBLuo6NoiV4kyL9GBfxxaVAbE4SIC jfZFIML6ramEI584y5hq46XyFklCF/+D3GfKCl8RJPxe/94ZegcaPB2rL2G1ZrohXRpq E76HDGyskmErtGPERjrvhVNw8HHD1GyZSM4d5qv2n+1Dt/OyMXXRErox11Pw5qhSPJz/ +SuuyiQMQzU0RmWM3Gzd9F42HoTAFAU2sV5erwhl7I1tmHVDWhWmmz2bGDjK22oPjfN3 FAiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=xRcTCcl+; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n20-20020a5099d4000000b00418c2b5bf8bsi1332605edb.621.2022.04.01.04.20.01; Fri, 01 Apr 2022 04:20:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=xRcTCcl+; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343911AbiDAHok (ORCPT + 99 others); Fri, 1 Apr 2022 03:44:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236779AbiDAHoi (ORCPT ); Fri, 1 Apr 2022 03:44:38 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 728D525ECAF; Fri, 1 Apr 2022 00:42:49 -0700 (PDT) Date: Fri, 1 Apr 2022 09:42:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1648798967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TrMSX3+gQilz8a7VNHdVxgsogGZEoAnFBXl8tPxCkps=; b=xRcTCcl+csECfBYuNeNbcoKWCk5bkTzdHZkh5H4ondpwyQ+mRfNAxVURLZ7BZMZ1nXodyz 0RdC+akthA17UUMCGhlJJGtTRKpueBs+Mv0k07cJ0OQyxrvgsPNrQZDxjKTzAbDXkK3O3k K/76cJx6ROrJi1G0DpVO/Qed01wyS1nCY/CNwBzsweCWieBVUi+jK6mJolTX4GWKFZmaJh xPBXvtjwjN4BOJPzegIWlxJ85o4ZDRJp6XnOG8IcMcERx1iHygjV9hYJ6uiRCBtQZ7TyPO mJ8wQzuIVRADijqlu6b8jOb0rZuUVe7njPkkt5K3wFpYzrgKpftD5QDE0NT4nA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1648798967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TrMSX3+gQilz8a7VNHdVxgsogGZEoAnFBXl8tPxCkps=; b=vntOswetkOSyBNw8nZmY0lvQccpo4n9jTQXXWNro3shzUqYzmw8U7y18KhVz7XtmsQ0jUP lu4mxX+xZNpxX9DA== From: Sebastian Andrzej Siewior To: Javier Martinez Canillas Cc: "Ahmed S. Darwish" , Ard Biesheuvel , Linux Kernel Mailing List , linux-efi , Brian Masney , Al Stone , Peter Robinson , Robbie Harwood , Peter Jones , Alexander Larsson , Andrew Halaney , linux-rt-users@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH v2] efi: Allow to enable EFI runtime services by default on RT Message-ID: References: <20220331151654.184433-1-javierm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-04-01 00:19:57 [+0200], Javier Martinez Canillas wrote: > > In case of (CONFIG_PREEMPT_RT=y && CONFIG_EFI_DISABLE_RUNTIME=n), > > shouldn't we add a small message in the kernel log warning that EFI > > runtime services are enabled for the RT kernel? > > > > In almost all HW, except custom ones with "verified" firmware, such a > > warning would be useful... This is especially true since in the embedded > > I considered that as well but was not sure about what that message should be. This makes sense and we had this in the past but dropped it for some reason. > Since it will be printed even on systems whose EFI firmwares do not > have such long call times as the ones described in the commit that > disabled the runtime services for RT. > > And in that case the warning may be misleading and make users believe > that a problem exists, which might not be accurate. Does this matter? The efi-rtc driver is known to cause latencies but it does not happen if the driver is not used. The same is probably true for efi-vars: It won't cause high latencies on _read_ but then a certain number of bit flips during read _may_ lead to write+erase which will cause higher latencies. Having a warning at boot (similar to trace_printk's warning) with the options listed that are known to case high latencies might be a help. There are some options that nobody will argue about like LOCKDEP. Then there are other like WATCHDOG or this one, where a debate might start ;) > Best regards, > Javier Sebastian