All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Ahmed S. Darwish" <a.darwish@linutronix.de>,
	Ard Biesheuvel <ardb@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Brian Masney <bmasney@redhat.com>, Al Stone <ahs3@redhat.com>,
	Peter Robinson <pbrobinson@gmail.com>,
	Robbie Harwood <rharwood@redhat.com>,
	Peter Jones <pjones@redhat.com>,
	Alexander Larsson <alexl@redhat.com>,
	Andrew Halaney <ahalaney@redhat.com>,
	linux-rt-users@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] efi: Allow to enable EFI runtime services by default on RT
Date: Fri, 1 Apr 2022 10:32:56 +0200	[thread overview]
Message-ID: <78a0360d-1a27-5280-10bf-d27d1d306fa5@redhat.com> (raw)
In-Reply-To: <Ykas9iX/D3WURx8T@linutronix.de>

Hello Sebastian,

On 4/1/22 09:42, Sebastian Andrzej Siewior wrote:
> 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.
> 

Ok, something like the following maybe? If you agree, I'll squash in v3:

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ff57db8f8d05..08d329a5179b 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -362,6 +362,8 @@ static int __init efisubsys_init(void)
 
        if (!efi_enabled(EFI_RUNTIME_SERVICES))
                efi.runtime_supported_mask = 0;
+       else if (IS_ENABLED(CONFIG_PREEMPT_RT))
+               pr_warn("EFI runtime services can lead to high latencies on Real-Time kernels\n");
 
        if (!efi_enabled(EFI_BOOT))
                return 0;

>> 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 ;)
>

Yes, you are correct.
 
>> Best regards,
>> Javier
> 
> Sebastian
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat


  reply	other threads:[~2022-04-01  8:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31 15:16 [PATCH v2] efi: Allow to enable EFI runtime services by default on RT Javier Martinez Canillas
2022-03-31 16:26 ` Ard Biesheuvel
2022-03-31 19:29   ` Ahmed S. Darwish
2022-03-31 22:19     ` Javier Martinez Canillas
2022-04-01  7:42       ` Sebastian Andrzej Siewior
2022-04-01  8:32         ` Javier Martinez Canillas [this message]
2022-04-01  8:34           ` Ard Biesheuvel
2022-04-01  8:38             ` Javier Martinez Canillas
2022-04-01  9:05             ` Sebastian Andrzej Siewior
2022-04-13 17:11               ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=78a0360d-1a27-5280-10bf-d27d1d306fa5@redhat.com \
    --to=javierm@redhat.com \
    --cc=a.darwish@linutronix.de \
    --cc=ahalaney@redhat.com \
    --cc=ahs3@redhat.com \
    --cc=alexl@redhat.com \
    --cc=ardb@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=bmasney@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=pbrobinson@gmail.com \
    --cc=pjones@redhat.com \
    --cc=rharwood@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.