From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by mx.groups.io with SMTP id smtpd.web09.3716.1571661902451779070 for ; Mon, 21 Oct 2019 05:45:02 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0197fc507c=sunnywang@hpe.com) Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9LCgDrk031691; Mon, 21 Oct 2019 12:45:01 GMT Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) by mx0b-002e3701.pphosted.com with ESMTP id 2vs6yy5etc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Oct 2019 12:45:01 +0000 Received: from G2W6310.americas.hpqcorp.net (g2w6310.austin.hp.com [16.197.64.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id DB0CD72; Mon, 21 Oct 2019 12:45:00 +0000 (UTC) Received: from G9W8453.americas.hpqcorp.net (16.216.160.211) by G2W6310.americas.hpqcorp.net (16.197.64.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 21 Oct 2019 12:45:00 +0000 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (15.241.52.10) by G9W8453.americas.hpqcorp.net (16.216.160.211) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 21 Oct 2019 12:45:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cFJq3OkpkiCKuMRQeeg4sAkPt1UNs0xkk9uLKz1oU5L/bWxtL2lBBfHfIgCgCoKvM91O7wbTfY6n4CeOkmokO+b7ZFQAdNK1BnL76mtTo4TvfvqwWVLtEvpqDD37u7OVG8uWUQ7QpdN6aHkotBV+PpfeBUhdb6WIAXVdqiFrqKecG4TZUpI/mIhHC1tVr4MwJXrxbFl2dEEq95hrzKstJGM02v75Tam/wg98wjy9tsPSkEqIcVa9jEvlx5LCi35ykr9T2kPtkIZjspKEhafssY+gsGxom8o5wrB9LZzZi9L2yZ+9MSALqkXNLt0GLsoI6BGR+8gPwk/vnTx4u2E5vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gHi4jGBOGOa5qs/VefUdewx1+51k0lQCEYWoeI43mtE=; b=dL6WMt8ZZyxHeKaknp8X3C7ezjb7MdUWH1fOR1Rv+oCrZZWnsJunsIhoZZCRYVOB/jrCw/FB+8FuRrHVTec9ANm8V6IGoREOz5kKMvXt5AfPCvzzzgvCUBjsS3BUZqNFsnIrHUgOfs7kAvmXg50G0GWDDvN+yFDZkmSYAjYc4WzUCf70+QEyr2Y9FQqakyqKvWT2xUbhQ18c7QOSzy3VzWW6BvDiVPhfm7NdsrViA7M9BOIDMz0DseRPGyGnt3BayIbL8NG8D2erGs6jb+UwCk41sSGIJ1qjVzWAYBvPBxQGTa5ZyMck/hz82jdbPeMscuL83wVsm44gt8Wgfzst2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from DF4PR8401MB0969.NAMPRD84.PROD.OUTLOOK.COM (10.169.87.143) by DF4PR8401MB0810.NAMPRD84.PROD.OUTLOOK.COM (10.169.84.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 21 Oct 2019 12:44:58 +0000 Received: from DF4PR8401MB0969.NAMPRD84.PROD.OUTLOOK.COM ([fe80::d1ca:f8fb:45e:4c30]) by DF4PR8401MB0969.NAMPRD84.PROD.OUTLOOK.COM ([fe80::d1ca:f8fb:45e:4c30%12]) with mapi id 15.20.2347.029; Mon, 21 Oct 2019 12:44:58 +0000 From: "Wang, Sunny (HPS SW)" To: "Ni, Ray" , "devel@edk2.groups.io" , "Gao, Zhichao" , "pjones@redhat.com" 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 Thread-Topic: [edk2-devel] Use a pcd to control PlatformRecovery Thread-Index: AdWDK94yxgzpZjqYRC+1b6PvmRyefQAmqTjgAAec3iAABAVasAACE+xQAQJ4ahA= Date: Mon, 21 Oct 2019 12:44:58 +0000 Message-ID: References: <3CE959C139B4C44DBEA1810E3AA6F9000B857172@SHSMSX101.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C325246@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C325246@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d88bf2a-8168-43a9-35b4-08d756247b9b x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DF4PR8401MB0810: x-ms-exchange-purlcount: 3 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(136003)(396003)(39860400002)(346002)(376002)(13464003)(199004)(189003)(51444003)(9686003)(6436002)(446003)(52536014)(102836004)(2906002)(486006)(66066001)(2501003)(26005)(4326008)(25786009)(229853002)(11346002)(55016002)(5660300002)(6306002)(6246003)(186003)(476003)(66446008)(64756008)(66556008)(66476007)(256004)(14444005)(19627235002)(76116006)(71200400001)(71190400001)(99286004)(54906003)(8936002)(81166006)(81156014)(110136005)(76176011)(7696005)(74316002)(305945005)(316002)(7416002)(7736002)(86362001)(3846002)(66946007)(8676002)(6506007)(53546011)(966005)(478600001)(33656002)(14454004)(6116002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB0810;H:DF4PR8401MB0969.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OXv/5gDWA9nmMHCywISgdVu/7brzS3a9MBhYwWiytT4DNJvHE9FU8Sr3HTl/n3UNyKmb1QUql4C4zHZNe5WEhZFYg10qxNCcrfrM3DZN2RG/YlXl835eMcL0ifVtLzXMEbG55DIPFfp6s+nmk946O5jX6fvqt482CeDTqNPnt/jJ+wDPazle5arrqS3LdhcOuJ+FxiyOTW8e/VUMsGFPeKDbPNcap9J5MBh0uOqVGxTVOU4SmsQVLdLOKmCUVCX1HEU+fR7US1lcJvR3m78yjiZHz4tI64KRq41U4qkfcIMld0R+ZhCUAqsRKTTN8RF4/RD4Ui+WnskFBQD+IVjHrJfilQIuaSbYtzjsXCRVx4ss2fiGRjJk/6R1ch4cr1rPop7BCVbiSDOmyYBIp0WNhSzk6y+2WT4KqNZS7CPEapgAhZqkD4btqK5yM0DN1Jn/i6qOWNWUC9jgQLScxy4Okt77e73GeSouZfwH4Ld+tME= X-MS-Exchange-CrossTenant-Network-Message-Id: 5d88bf2a-8168-43a9-35b4-08d756247b9b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 12:44:58.6946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CZAyVILPYd8+f/H7JVBWCfkkq+3ug6dzTsiiIwetJjpScs2fTweM9BUBcdiYdC16xloSBDBn67I8SzFflmn7qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0810 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-21_04:2019-10-21,2019-10-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910210123 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the delay and thanks for checking my question, Ray. Since the OS recovery and platform recovery options were added to UEFI spe= cification at the same time, I thought we will also implement it and push t= he code regardless of the OS support.=20 No, I didn't see a real need of using the OS recovery option. If my memory= serves me well, I have only seen a need of using "One-Time" OS recovery, b= ut it can be done by creating, adjusting, and removing a boot option in boo= t order.=20 However, I can still imagine that the OS recovery option is needed for the= use of "persistent" OS recovery. Therefore, if we don't have any concern a= bout adding OS recovery option support, I think it is still better to push = the code because the UEFI specification mentioned it. Add Peter. He may kno= w more information about this. By the way, I think if no one works on the task below, there will be no OS= or OS tool supporting it. :) - https://github.com/rhboot/efibootmgr/issues/41 Regards, Sunny Wang -----Original Message----- From: Ni, Ray [mailto:ray.ni@intel.com]=20 Sent: Wednesday, October 16, 2019 4:43 PM To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; Gao, Z= hichao 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 Importance: High 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,=20 > Ray > Cc: Wang, Jian J ; Wu, Hao A=20 > ; Zeng, Star ; Gao, Liming=20 > ; Sean Brogan ;=20 > Michael Turner ; Bret Barkelew=20 > ; Li, Walon ; Wei, Kent= =20 > (HPS SW) ; Spottswood, Jason=20 > ; 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=20 > OsIndications" >=20 > Regards, > Sunny Wang >=20 > -----Original Message----- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of=20 > Gao, Zhichao > Sent: Wednesday, October 16, 2019 1:57 PM > To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io;=20 > Ni, Ray > Cc: Wang, Jian J ; Wu, Hao A=20 > ; Zeng, Star ; Gao, Liming=20 > ; Sean Brogan ;=20 > Michael Turner ; Bret Barkelew=20 > ; Li, Walon ; Wei, Kent= =20 > (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=20 > > ; Zeng, Star ; Gao, Liming=20 > > ; Sean Brogan ;=20 > > Michael Turner ; Bret Barkelew=20 > > ; 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=20 > > boot flow except PlatformRecovery. > > > > Local variable PlatformRecovery is controlled by OsIndications=20 > > variable. When the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY is > set, > > the firmware should try to platform specific recovery. But that=20 > > doesn't mean the platform must support the specific recovery. i.e. > > local PlatformRecovery is controlling the boot flow and the Pcd just= =20 > > 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=20 > and 3.4.2, the OsRecovery and PlatformRecovery should always be=20 > operated regardless of the value of OsIndication variable if fail to=20 > boot the BootOrder. I am wrong. We should change to use the=20 > PcdPlatformRecoverySupport to control the PlatformRecovery. Please=20 > help to send a patch to fix it. Thanks 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*=20 > > option would be one part of the PlatformRecovery#### in case there=20 > > are no other boot options. If the firmware doesn't support platform=20 > > recovery, we still need this default boot thru a short file path and= =20 > > 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 ;=20 > > > Ni, Ray > > > Cc: Wang, Jian J ; Wu, Hao A=20 > > > ; Zeng, Star ; Gao,=20 > > > Liming ; Sean Brogan=20 > > > ; Michael Turner=20 > > > ; Bret Barkelew=20 > > > ; 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= =20 > > > to bring my questions here. > > > > > > For now, the code block for iterating the PlatformRecovery####=20 > > > variables is controlled by OsIndications variable. However, it=20 > > > looks to me like that the PlatformRecovery#### should still be=20 > > > attempted for the case of that processing of BootOrder does NOT=20 > > > result in success (according to section 3.4 in UEFI 2.8). In other= =20 > > > words, I think we should check PCD "PcdPlatformRecoverySupport"=20 > > > instead of Local variable > > "PlatformRecovery" > > > (from OsIndications variable) like the code below. What do you=20 > > > guys think? If you need a meeting or short talk to discuss this,=20 > > > feel free to let me > > know. > > > > > > if (!BootSuccess) { > > > - if (PlatformRecovery) { > > > + if (PcdGetBool (PcdPlatformRecoverySupport)) { > > > LoadOptions =3D EfiBootManagerGetLoadOptions=20 > > > (&LoadOptionCount, LoadOptionTypePlatformRecovery); > > > ProcessLoadOptions (LoadOptions, LoadOptionCount); > > > EfiBootManagerFreeLoadOptions (LoadOptions, LoadOptionCount); > > > } else { > > > // > > > // When platform recovery is not enabled, still boot to=20 > > > platform default file path. > > > // > > > EfiBootManagerProcessLoadOption (&PlatformDefaultBootOption); > > > } > > > > > > > > > In addition, it looks like EDK2 don't have code to process=20 > > > 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=20 > 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=20 > > > PlatformRecovery", but I can't figure out the connection between=20 > > > the discussion and the final code change. Isn't the "Default > PlatformRecovery" > > > part of the Platform Recovery feature? At this moment, we don't=20 > > > have OS recovery support, so I think that NO platform recovery=20 > > > support can be identified as NO boot option recovery support. For=20 > > > this case, shouldn't we use PCD "PcdPlatformRecoverySupport" to=20 > > > control "Default PlatformRecovery" as well? For the next step, I=20 > > > think we need to get further clarification from USWG to either not= =20 > > > tie "Default Boot Behavior" with PlatformRecovery or update the=20 > > > description to the > > following: > > > - If system firmware supports Platform recovery as described=20 > > > in Section 3.4.2, system firmware must include a=20 > > > PlatformRecovery#### variable specifying a short-form File Path Medi= a Device Path.... >=20 > As I said above the 'Default Platform Recovery' refer to the=20 > short-form file path boot. When the PcdPlatformRecoverySupport is=20 > TRUE, it is part of PlatformRecovery. Ohterwise, it is not part of=20 > platform recovery and we still need to support it because of the=20 > capability issue. And that isn't conflict with the spec. >=20 > Thanks, > Zhichao >=20 > > > > > > Regards, > > > Sunny Wang > > > >=20 >=20 >=20