From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web11.2927.1571215359987924035 for ; Wed, 16 Oct 2019 01:42:40 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2019 01:42:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,303,1566889200"; d="scan'208";a="395824369" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 16 Oct 2019 01:42:39 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 01:42:38 -0700 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 01:42:38 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.166]) by SHSMSX153.ccr.corp.intel.com ([10.239.6.53]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 16:42:36 +0800 From: "Ni, Ray" To: "Wang, Sunny (HPS SW)" , "devel@edk2.groups.io" , "Gao, Zhichao" CC: "Wang, Jian J" , "Wu, Hao A" , "Zeng, Star" , "Gao, Liming" , Sean Brogan , Michael Turner , Bret Barkelew , "Li, Walon" , "Wei, Kent (HPS SW)" , "Spottswood, Jason" Subject: Re: [edk2-devel] Use a pcd to control PlatformRecovery Thread-Topic: [edk2-devel] Use a pcd to control PlatformRecovery Thread-Index: AdWDK94yxgzpZjqYRC+1b6PvmRyefQAmqTjgAAec3iAABAVasAACE+xQ Date: Wed, 16 Oct 2019 08:42:36 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C325246@SHSMSX104.ccr.corp.intel.com> References: <3CE959C139B4C44DBEA1810E3AA6F9000B857172@SHSMSX101.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sunny, For the OS recovery question, I had the code change in https://github.com/= niruiyu/edk2/tree/bds/osrecovery. Due to there is no OS support for OS recovery yet, the code was not pushed= . Do you see any needs of the OS recovery? Thanks, Ray > -----Original Message----- > From: Wang, Sunny (HPS SW) > Sent: Wednesday, October 16, 2019 3:42 PM > To: devel@edk2.groups.io; Gao, Zhichao ; Ni, Ray > > Cc: Wang, Jian J ; Wu, Hao A = ; > Zeng, Star ; Gao, Liming ; > Sean Brogan ; Michael Turner > ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) ; Spottswood, Jason > ; Wang, Sunny (HPS SW) > > Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery >=20 > Thanks for checking this, Zhichao and Ray. > I just sent a patch to fix it with the subject " [edk2-devel] [PATCH] > MdeModulePkg/BdsDxe: Make PlatformRecovery work regardless of > OsIndications" >=20 > Regards, > Sunny Wang >=20 > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Gao, Zhichao > Sent: Wednesday, October 16, 2019 1:57 PM > To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; > Ni, Ray > Cc: Wang, Jian J ; Wu, Hao A = ; > Zeng, Star ; Gao, Liming ; > Sean Brogan ; Michael Turner > ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) > Subject: Re: [edk2-devel] Use a pcd to control PlatformRecovery > Importance: High >=20 >=20 > > -----Original Message----- > > From: Gao, Zhichao > > Sent: Wednesday, October 16, 2019 10:09 AM > > To: 'Wang, Sunny (HPS SW)' ; > devel@edk2.groups.io; > > Ni, Ray > > Cc: Wang, Jian J ; Wu, Hao A > > ; Zeng, Star ; Gao, Liming > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > ; Li, Walon ; Wei, > Kent > > (HPS SW) > > Subject: RE: Use a pcd to control PlatformRecovery > > > > 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. >=20 > After discuss with Sunny and Ray, and refer to the spec section 3.4.1 an= d > 3.4.2, the OsRecovery and PlatformRecovery should always be operated > regardless of the value of OsIndication variable if fail to boot the Boo= tOrder. I > am wrong. We should change to use the PcdPlatformRecoverySupport to > control the PlatformRecovery. Please help to send a patch to fix it. Tha= nks a > lot. >=20 > > > > 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 ; Ni, > > > Ray > > > Cc: Wang, Jian J ; Wu, Hao A > > > ; Zeng, Star ; Gao, Liming > > > ; Sean Brogan ; > > > Michael Turner ; Bret Barkelew > > > ; Li, Walon ; Wei, > > Kent > > > (HPS SW) ; Wang, Sunny (HPS SW) > > > > > 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 =3D 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? >=20 > OsRecovery#### doesn't have an implement yet, we should co-work with > the OS vendor to define the operation. For now, there is no requirement. >=20 > > > > > > 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.... >=20 > As I said above the 'Default Platform Recovery' refer to the short-form = file > path boot. When the PcdPlatformRecoverySupport is TRUE, it is part of > PlatformRecovery. Ohterwise, it is not part of platform recovery and we = still > need to support it because of the capability issue. And that isn't confl= ict with > the spec. >=20 > Thanks, > Zhichao >=20 > > > > > > Regards, > > > Sunny Wang > > > >=20 >=20 >=20