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.web12.1072.1571191753084829482 for ; Tue, 15 Oct 2019 19:09:13 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: zhichao.gao@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; 15 Oct 2019 19:09:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,302,1566889200"; d="scan'208";a="395741488" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga005.fm.intel.com with ESMTP; 15 Oct 2019 19:09:12 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 15 Oct 2019 19:09:12 -0700 Received: from shsmsx154.ccr.corp.intel.com (10.239.6.54) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 15 Oct 2019 19:09:12 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.96]) by SHSMSX154.ccr.corp.intel.com ([10.239.6.54]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 10:09:10 +0800 From: "Gao, Zhichao" 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 Thread-Topic: Use a pcd to control PlatformRecovery Thread-Index: AdWDK94yxgzpZjqYRC+1b6PvmRyefQAmqTjg Date: Wed, 16 Oct 2019 02:09:09 +0000 Message-ID: <3CE959C139B4C44DBEA1810E3AA6F9000B85709F@SHSMSX101.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: zhichao.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First of all, the patch didn't aim to change the other part of the boot flo= w except PlatformRecovery. Local variable PlatformRecovery is controlled by OsIndications variable. Wh= en the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY is set, the firmware shou= ld try to platform specific recovery. But that doesn't mean the platform mu= st support the specific recovery. i.e. local PlatformRecovery is controllin= g the boot flow and the Pcd just indicated whether the platform support rec= overy 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 t= he firmware supports platform recovery, then *short file path* option would= be one part of the PlatformRecovery#### in case there are no other boot op= tions. If the firmware doesn't support platform recovery, we still need thi= s default boot thru a short file path and it should not depend on the Platf= ormRecovery#### 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 >=20 > Hi Zhichao and Ray, >=20 > I have some questions about this code change. Sorry for being late to bri= ng > my questions here. >=20 > For now, the code block for iterating the PlatformRecovery#### variables = is > controlled by OsIndications variable. However, it looks to me like that t= he > 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 kno= w. >=20 > 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 de= fault > file path. > // > EfiBootManagerProcessLoadOption (&PlatformDefaultBootOption); > } >=20 >=20 > 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 > 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 w= e > use PCD "PcdPlatformRecoverySupport" to control "Default > PlatformRecovery" as well? For the next step, I think we need to get furt= her > 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 Secti= on > 3.4.2, system firmware must include a PlatformRecovery#### variable > specifying a short-form File Path Media Device Path.... >=20 > Regards, > Sunny Wang >=20