From: "Gao, Zhichao" <zhichao.gao@intel.com>
To: "Wang, Sunny (HPS SW)" <sunnywang@hpe.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Ni, Ray" <ray.ni@intel.com>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>,
"Wu, Hao A" <hao.a.wu@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
Sean Brogan <sean.brogan@microsoft.com>,
Michael Turner <Michael.Turner@microsoft.com>,
Bret Barkelew <Bret.Barkelew@microsoft.com>,
"Li, Walon" <walon.li@hpe.com>,
"Wei, Kent (HPS SW)" <kent.wei@hpe.com>
Subject: Re: Use a pcd to control PlatformRecovery
Date: Wed, 16 Oct 2019 02:09:09 +0000 [thread overview]
Message-ID: <3CE959C139B4C44DBEA1810E3AA6F9000B85709F@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <DF4PR8401MB0969A0C387A4FEC397DDCF7FA8930@DF4PR8401MB0969.NAMPRD84.PROD.OUTLOOK.COM>
First of all, the patch didn't aim to change the other part of the boot flow except PlatformRecovery.
Local variable PlatformRecovery is controlled by OsIndications variable. When the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY is set, the firmware should try to platform specific recovery. But that doesn't mean the platform must support the specific recovery. i.e. local PlatformRecovery is controlling the boot flow and the Pcd just indicated whether the platform support recovery or not.
So, on my opinion, I don't agree with your change.
Default Platform Recovery refer to the short file path to boot the OS. If the firmware supports platform recovery, then *short file path* option would be one part of the PlatformRecovery#### in case there are no other boot options. If the firmware doesn't support platform recovery, we still need this default boot thru a short file path and it should not depend on the PlatformRecovery#### variable for the compatibility thinking.
Thanks,
Zhichao
> -----Original Message-----
> From: Wang, Sunny (HPS SW) [mailto:sunnywang@hpe.com]
> Sent: Tuesday, October 15, 2019 4:53 PM
> To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray
> <ray.ni@intel.com>
> Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
> Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>;
> Sean Brogan <sean.brogan@microsoft.com>; Michael Turner
> <Michael.Turner@microsoft.com>; Bret Barkelew
> <Bret.Barkelew@microsoft.com>; Li, Walon <walon.li@hpe.com>; Wei, Kent
> (HPS SW) <kent.wei@hpe.com>; Wang, Sunny (HPS SW)
> <sunnywang@hpe.com>
> Subject: Use a pcd to control PlatformRecovery
>
> Hi Zhichao and Ray,
>
> I have some questions about this code change. Sorry for being late to bring
> my questions here.
>
> For now, the code block for iterating the PlatformRecovery#### variables is
> controlled by OsIndications variable. However, it looks to me like that the
> PlatformRecovery#### should still be attempted for the case of that
> processing of BootOrder does NOT result in success (according to section 3.4
> in UEFI 2.8). In other words, I think we should check PCD
> "PcdPlatformRecoverySupport" instead of Local variable "PlatformRecovery"
> (from OsIndications variable) like the code below. What do you guys think? If
> you need a meeting or short talk to discuss this, feel free to let me know.
>
> if (!BootSuccess) {
> - if (PlatformRecovery) {
> + if (PcdGetBool (PcdPlatformRecoverySupport)) {
> LoadOptions = EfiBootManagerGetLoadOptions (&LoadOptionCount,
> LoadOptionTypePlatformRecovery);
> ProcessLoadOptions (LoadOptions, LoadOptionCount);
> EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount);
> } else {
> //
> // When platform recovery is not enabled, still boot to platform default
> file path.
> //
> EfiBootManagerProcessLoadOption (&PlatformDefaultBootOption);
> }
>
>
> In addition, it looks like EDK2 don't have code to process OsRecovery####
> variables. Do we need to create a Bug on TianoCore Bugzilla system?
>
> Moreover, I saw that both of you had a discussion about "Default
> PlatformRecovery", but I can't figure out the connection between the
> discussion and the final code change. Isn't the "Default PlatformRecovery"
> part of the Platform Recovery feature? At this moment, we don't have OS
> recovery support, so I think that NO platform recovery support can be
> identified as NO boot option recovery support. For this case, shouldn't we
> use PCD "PcdPlatformRecoverySupport" to control "Default
> PlatformRecovery" as well? For the next step, I think we need to get further
> clarification from USWG to either not tie "Default Boot Behavior" with
> PlatformRecovery or update the description to the following:
> - If system firmware supports Platform recovery as described in Section
> 3.4.2, system firmware must include a PlatformRecovery#### variable
> specifying a short-form File Path Media Device Path....
>
> Regards,
> Sunny Wang
>
next prev parent reply other threads:[~2019-10-16 2:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 8:53 Use a pcd to control PlatformRecovery Wang, Sunny (HPS SW)
2019-10-16 2:09 ` Gao, Zhichao [this message]
2019-10-16 5:57 ` Gao, Zhichao
2019-10-16 7:42 ` [edk2-devel] " Wang, Sunny (HPS SW)
2019-10-16 8:42 ` Ni, Ray
2019-10-21 12:44 ` Wang, Sunny (HPS SW)
2019-10-22 1:13 ` Ni, Ray
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=3CE959C139B4C44DBEA1810E3AA6F9000B85709F@SHSMSX101.ccr.corp.intel.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