public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Samer El-Haj-Mahmoud" <samer.el-haj-mahmoud@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"gaoliming@byosoft.com.cn" <gaoliming@byosoft.com.cn>
Cc: "quic_llindhol@quicinc.com" <quic_llindhol@quicinc.com>,
	"ngompa13@gmail.com" <ngompa13@gmail.com>,
	"Michael Kinney" <michael.d.kinney@intel.com>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Jeremy Linton" <Jeremy.Linton@arm.com>,
	"Pete Batard" <pete@akeo.ie>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
Date: Tue, 19 Dec 2023 14:11:04 +0000	[thread overview]
Message-ID: <VI1PR08MB5312BB48121BDCF4D922C84A9097A@VI1PR08MB5312.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAMj1kXG9U4Nhs1xDbryFkVO1_ujYZu_5Fza=Qgcw2f=w5X2sXg@mail.gmail.com>

Thank you all!

> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Tuesday, December 19, 2023 8:59 AM
> To: devel@edk2.groups.io; gaoliming@byosoft.com.cn
> Cc: quic_llindhol@quicinc.com; ngompa13@gmail.com; Michael Kinney
> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Jeremy Linton
> <Jeremy.Linton@arm.com>; 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>
> Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib:
> Signal ReadyToBoot on platform recovery
>
> On Tue, 19 Dec 2023 at 14:00, gaoliming via groups.io
> <gaoliming=byosoft.com.cn@groups.io> wrote:
> >
> > Yes. The latest spec has clarified this behavior. So, this change is OK. Reviewed-
> by: Liming Gao <gaoliming@byosoft.com.cn>
> >
>
> Merged as #5165
>
> Thanks all
>
> > > -----邮件原件-----
> > > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Leif Lindholm
> > > 发送时间: 2023年12月19日 19:51
> > > 收件人: devel@edk2.groups.io; ardb@kernel.org
> > > 抄送: ngompa13@gmail.com; Liming Gao (Byosoft address)
> > > <gaoliming@byosoft.com.cn>; Michael Kinney
> <michael.d.kinney@intel.com>;
> > > Laszlo Ersek <lersek@redhat.com>; Jeremy Linton <jeremy.linton@arm.com>;
> > > 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>
> > > 主题: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib:
> > > Signal ReadyToBoot on platform recovery
> > >
> > > On Mon, Dec 18, 2023 at 22:55:21 +0100, Ard Biesheuvel wrote:
> > > > Hello all,
> > > >
> > > > Same question again. Could we please make some progress on this?
> > > >
> > > > Full thread here:
> > > >
> > > https://openfw.io/edk2-devel/20231031173700.647004-1-
> ngompa@fedorap
> > > roject.org/
> > > >
> > > > If nobody objects, I will assume that the change is acceptable and
> > > > merge it by the end of the week.
> > >
> > > I'm OK with this.
> > >
> > > The last comment from Liming in
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2831
> > > was that the fix could be merged after "the next UEFI is published",
> > > which it was - in August 2022.
> > >
> > > Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > >
> > > > Thanks,
> > > > Ard.
> > > >
> > > >
> > > >
> > > > On Tue, 12 Dec 2023 at 09:11, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > >
> > > > > (cc Mike, Leif)
> > > > >
> > > > > On Thu, 7 Dec 2023 at 08:40, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > (cc Liming)
> > > > > >
> > > > > > On Thu, 7 Dec 2023 at 05:48, Neal Gompa <ngompa13@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > On Fri, Nov 24, 2023 at 6:36 PM Neal Gompa
> <ngompa13@gmail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Nov 2, 2023 at 6:35 AM Laszlo Ersek <lersek@redhat.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > On 10/31/23 23:27, Jeremy Linton wrote:
> > > > > > > > > > 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?
> > > > > > > > >
> > > > > > > > > What else is there, outside of this patch, in need of upstreaming?
> > > > > > > > >
> > > > > > > > > > That seems a bit of an oversight since its been in the spec for a
> > > few years now.
> > > > > > > > >
> > > > > > > > > "ready-to-boot for OsRecovery" is new in UEFI 2.10 (according to
> > > the
> > > > > > > > > commit message), which is quite recent ("Aug 29, 2022").
> > > > > > > > >
> > > > > > > > > I couldn't find the Mantis ticket in the Revision History (for 2.10)
> > > though.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Is there anything else holding up committing this patch? Jeremy and
> > > > > > > > you reviewed it earlier in the month...
> > > > > > > >
> > > > > > >
> > > > > > > Friendly ping again? It's been a month now...
> > > > > > >
> > > > > >
> > > > > > Apologies for the delay - Liming, can we progress with this?
> > > > >
> > > > > Can we please make some progress with this? This has been in limbo for
> > > > > far too long.
> > > > >
> > > > > Thanks,
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > 
> >
> >
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


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



  reply	other threads:[~2023-12-19 14:11 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
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 [this message]
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=VI1PR08MB5312BB48121BDCF4D922C84A9097A@VI1PR08MB5312.eurprd08.prod.outlook.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