[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7178244c-fcfb-01d8-f678-565401cabca0@redhat.com>
Date: Thu, 31 Mar 2022 16:50:06 +0200
From: Javier Martinez Canillas <javierm@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Peter Jones <pjones@...hat.com>,
Alexander Larsson <alexl@...hat.com>,
Al Stone <ahs3@...hat.com>, linux-efi@...r.kernel.org,
Ard Biesheuvel <ardb@...nel.org>,
Andrew Halaney <ahalaney@...hat.com>,
linux-rt-users@...r.kernel.org, Brian Masney <bmasney@...hat.com>,
Robbie Harwood <rharwood@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] efi: Allow to enable EFI runtime services with PREEMPT_RT
On 3/31/22 16:40, Sebastian Andrzej Siewior wrote:
> On 2022-03-31 16:25:40 [+0200], Javier Martinez Canillas wrote:
>> Hello Sebastian,
> Hi Javier,
>
>> Yes, it is but the motivation is to be able to have EFI runtime services
>> by default without the need for any kernel command line parameter.
>
> This part wasn't clear. It is not mentioned by the description but now
> that I look at Kconfig, it is there.
>
Sure, I can post a v2 with better wording in the description to make it clear.
>> In the same vein, I could ask if efi=noruntime wasn't enough instead of
>> commit ("efi: Disable runtime services on RT").
>
> No, it is not because it should not lead to any surprise latencies by
> default.
>
Yes, it was a rhetorical question. I understand the motivation of that commit
and agree with it. That's why $SUBJECT doesn't change the current behaviour,
and the EFI runtime services will still be disabled by default for RT.
It's just to allow a way to enable for RT users that may want to. But having
a separate boolean symbol also allow non RT users to disable it by default.
> Sebastian
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Powered by blists - more mailing lists