public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Jeremy Linton" <jeremy.linton@arm.com>
To: devel@edk2.groups.io, ngompa13@gmail.com
Cc: "Neal Gompa" <ngompa@fedoraproject.org>,
	"Pete Batard" <pete@akeo.ie>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Samer El-Haj-Mahmoud" <samer.el-haj-mahmoud@arm.com>,
	"Laszlo Ersek" <lersek@redhat.com>
Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
Date: Tue, 31 Oct 2023 17:27:32 -0500	[thread overview]
Message-ID: <58ec87dc-ce03-6ad8-681a-d815bc5c39f9@arm.com> (raw)
In-Reply-To: <20231031173700.647004-1-ngompa@fedoraproject.org>

On 10/31/23 12:37, Neal Gompa via groups.io wrote:
> From: Neal Gompa <ngompa@fedoraproject.org>
> 
> Currently, the ReadyToBoot event is only signaled when a formal Boot
> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> 
> However, the introduction of Platform Recovery in UEFI 2.5 makes it
> necessary to signal ReadyToBoot when a Platform Recovery boot loader
> runs because otherwise it may lead to the execution of a boot loader
> that has similar requirements to a regular one that is not launched
> as a Boot Manager option.
> 
> This is especially critical to ensuring that the graphical console
> is actually usable during platform recovery, as some platforms do
> rely on the ConsolePrefDxe driver, which only performs console
> initialization after ReadyToBoot is triggered.
> 
> This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
> in EfiBootManagerProcessLoadOption () when invoking platform recovery,
> which is the function that sets up the platform recovery boot process.
> 
> The expected behavior has been clarified in the UEFI 2.10 specification
> to explicitly indicate this behavior is required for correct operation.
> 
> This is a rebased version of the patch originally written by Pete Batard.

Took me a bit to swap in that whole conversation again, and recheck the 
spec's and code paths, but this all looks fine to me and should allow 
the PFTF build to drop the similar patch from Pete that has been carried 
downstream for the past couple years.

As for testing the previous patch has been in the field for a couple 
years now and i'm not aware of it causing any issues. The additional 
restriction of limiting it to platform recovery logically makes sense, 
and as far as I can see shouldn't cause any problems.

So,

Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>


As a PS: I also went to check the ready to boot behavior for OsRecovery 
and realized that apparently none of that support was ever merged? That 
seems a bit of an oversight since its been in the spec for a few years now.


> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
> 
> Cc: Pete Batard <pete@akeo.ie>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> 
> Co-authored-by: Pete Batard <pete@akeo.ie>
> Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
> ---
>   .../Library/UefiBootManagerLib/BmLoadOption.c         | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 2087f0b91d..83a2f893e4 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1416,6 +1416,17 @@ EfiBootManagerProcessLoadOption (
>       return EFI_SUCCESS;
>     }
>   
> +  if (LoadOption->OptionType == LoadOptionTypePlatformRecovery) {
> +    //
> +    // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
> +    //
> +    EfiSignalEventReadyToBoot ();
> +    //
> +    // Report Status Code to indicate ReadyToBoot was signaled
> +    //
> +    REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> +  }
> +
>     //
>     // Load and start the load option.
>     //



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110454): https://edk2.groups.io/g/devel/message/110454
Mute This Topic: https://groups.io/mt/102302654/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-10-31 22:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 17:37 [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery Neal Gompa
2023-10-31 22:27 ` Jeremy Linton [this message]
2023-11-02 10:35   ` Laszlo Ersek
2023-11-24 23:36     ` Neal Gompa
2023-12-07  4:47       ` Neal Gompa
2023-12-07  7:40         ` Ard Biesheuvel
2023-12-12  8:11           ` Ard Biesheuvel
2023-12-18 21:55             ` Ard Biesheuvel
2023-12-19 11:50               ` Leif Lindholm
2023-12-19 12:59                 ` 回复: " gaoliming via groups.io
2023-12-19 13:59                   ` Ard Biesheuvel
2023-12-19 14:11                     ` Samer El-Haj-Mahmoud
2023-12-22  3:03                       ` Neal Gompa
2023-11-02 10:20 ` Laszlo Ersek

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-list 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=58ec87dc-ce03-6ad8-681a-d815bc5c39f9@arm.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox