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.web12.2651.1571211751616000526 for ; Wed, 16 Oct 2019 00:42:31 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0192f9752e=sunnywang@hpe.com) Received: from pps.filterd (m0148664.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9G7fDvZ007573 for ; Wed, 16 Oct 2019 07:42:30 GMT Received: from g9t5009.houston.hpe.com (g9t5009.houston.hpe.com [15.241.48.73]) by mx0b-002e3701.pphosted.com with ESMTP id 2vnk56hxpf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Oct 2019 07:42:30 +0000 Received: from G2W6311.americas.hpqcorp.net (g2w6311.austin.hp.com [16.197.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5009.houston.hpe.com (Postfix) with ESMTPS id C66A76F for ; Wed, 16 Oct 2019 07:42:29 +0000 (UTC) Received: from G4W9335.americas.hpqcorp.net (16.208.33.85) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 16 Oct 2019 07:42:29 +0000 Received: from G4W10205.americas.hpqcorp.net (2002:10cf:520f::10cf:520f) by G4W9335.americas.hpqcorp.net (2002:10d0:2155::10d0:2155) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 16 Oct 2019 07:42:29 +0000 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (15.241.52.11) by G4W10205.americas.hpqcorp.net (16.207.82.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 16 Oct 2019 07:42:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S8xCM5yxpvqPFQf+sTn2kNSM60UTHbQ2jfTFqUxdQNOIvHmuwdkuHFLHHOymX4x2iB8DGQYgylfg1xVGLJg/UJp3049jmN5XkGj00VdaTRwvUSq7obkUb+6mf2TSslYzJaVeVCCMwg6xNTlCO7Ec8oEyEc2qBkza5r+ejUTRvzxVTnMf+fUp4wnxXO1jKOoZCzbvr5UteRtHUrfP2UlY/rVY3pMhI9OJVIR/R4Pj2Q6CXJD0sgW0eHW7771zzyV/YNiseXjnx9J1IKhd7/8iiby0ahxtkai4618CB432LQKlXYxafDS96gNvaURrcOQ7Jj+p019gz/wY1PorelwxRw== 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=MrWtnTn9ieLWC4Rb1PkFdBS9To8a9rtxCKMD9x1Mek8=; b=h51dH0RUtXGzTvRsi+5YNdBbXjipMY5l0XTkDH8REXjiIwlXgFdz9TTjQnH0IzcaGJlOGiG3BPCRytWT2KQ80wXrvUnsZa+TLXN/aHQslJLunoL7kkUwwNp6s4Q0A/2Wo3tm2YMKjdTvZxl3DI04IetPzmUkFhJmOVJquNjz9aC5S7/T8gZwfE9NDDmSRzvaLqSLb3rVWraPJHt9dAzt3I3bD9Kn8ykOX7ZpfrtjxHhujVH9YmBcgwqw2kOiaEM0yQHnOUg3yiNRSwj60w8K7VrXDldvtafamMULA6NzQmH2T03JfMiikYEQwFnCwY4CSvOTrLzvMdqqEXu9vhavIA== 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 DF4PR8401MB0746.NAMPRD84.PROD.OUTLOOK.COM (10.169.85.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 07:42:27 +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.023; Wed, 16 Oct 2019 07:42:27 +0000 From: "Wang, Sunny (HPS SW)" To: "devel@edk2.groups.io" , "zhichao.gao@intel.com" , "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 Thread-Topic: [edk2-devel] Use a pcd to control PlatformRecovery Thread-Index: AdWDK94yxgzpZjqYRC+1b6PvmRyefQAmqTjgAAec3iAABAVasA== Date: Wed, 16 Oct 2019 07:42:27 +0000 Message-ID: References: <3CE959C139B4C44DBEA1810E3AA6F9000B857172@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <3CE959C139B4C44DBEA1810E3AA6F9000B857172@SHSMSX101.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: aa3a8d07-7b45-42c0-f2a6-08d7520c644a x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: DF4PR8401MB0746: x-ms-exchange-purlcount: 3 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2276; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(346002)(376002)(39860400002)(366004)(136003)(51444003)(199004)(189003)(13464003)(81156014)(26005)(81166006)(14444005)(256004)(2501003)(11346002)(476003)(66066001)(186003)(486006)(8936002)(8676002)(229853002)(66476007)(66556008)(86362001)(446003)(6436002)(64756008)(76116006)(66946007)(66446008)(74316002)(7736002)(305945005)(7416002)(478600001)(99286004)(33656002)(966005)(4326008)(14454004)(9686003)(102836004)(7696005)(53546011)(76176011)(6506007)(6306002)(3846002)(25786009)(71200400001)(71190400001)(6246003)(55016002)(52536014)(110136005)(5660300002)(54906003)(2906002)(316002)(6116002);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB0746;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: 1NXPcGiRxs/eQu8lwRxB+A5fKAtMYRjzbCJkCI1b+pCtgC6ad0gYQos+FL0QeOWSgqE1OMoDHY6FjvbdWOp3jUpRGh0gqfi86UmNB5+admVPiszT7L8kVtWmIV0zK0wcT6LgfCtTqTtmqrk12Mo1/78Se4p4q/nQnMS/yBkZ7gU2TmCy76Vj9GyZj44HRHn+cU2hcXsg1E7An/vCN2rr5iQWekHDUj835/9UQ9S+/NzbYMjS2JxqkcZ03kbUYeu4Nc8N9hKr6UqoaQN/SD0yg/CvZJW5mRi78T8WOh+aJ6xp9jsZkxsry/N15VvyCZVolRF2nuDt30F5IEm/AW6yGAK+Rz+w3GguB0nMBffOeIvBJvWU5jt6Kq6BNHO2U4BitkvNK7suAQiQh5N9fm18uXx2VFPOGIrE+AWRunjD3pSPNRR2rYL8t2tEZCwAGlJqyWzuPWlUwnVhR531O9H34Q== X-MS-Exchange-CrossTenant-Network-Message-Id: aa3a8d07-7b45-42c0-f2a6-08d7520c644a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 07:42:27.0793 (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: /SlUjHQJ+W4dfi/U3/iuzkvOtsHJXlb6+62r4OeZd1ezkqfY8yHGSMCTAbows9imxoUKUcro5dRMZICkjGlOcQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0746 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 3 URL's were 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-16_03:2019-10-15,2019-10-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 phishscore=0 priorityscore=1501 adultscore=0 malwarescore=0 suspectscore=0 bulkscore=0 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910160071 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for checking this, Zhichao and Ray.=20 I just sent a patch to fix it with the subject " [edk2-devel] [PATCH] MdeM= odulePkg/BdsDxe: Make PlatformRecovery work regardless of OsIndications" Regards, Sunny Wang -----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, Ra= y 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 > -----Original Message----- > From: Gao, Zhichao > Sent: Wednesday, October 16, 2019 10:09 AM > 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: Use a pcd to control PlatformRecovery >=20 > First of all, the patch didn't aim to change the other part of the=20 > boot flow except PlatformRecovery. >=20 > Local variable PlatformRecovery is controlled by OsIndications=20 > variable. When the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY is set,=20 > the firmware should try to platform specific recovery. But that=20 > doesn't mean the platform must support the specific recovery. i.e.=20 > 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. After discuss with Sunny and Ray, and refer to the spec section 3.4.1 and = 3.4.2, the OsRecovery and PlatformRecovery should always be operated regard= less of the value of OsIndication variable if fail to boot the BootOrder. I= am wrong. We should change to use the PcdPlatformRecoverySupport to contro= l the PlatformRecovery. Please 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.= =20 > If the firmware supports platform recovery, then *short file path*=20 > option would be one part of the PlatformRecovery#### in case there are= =20 > 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 compat= ibility thinking. >=20 > Thanks, > Zhichao >=20 > > -----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,=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 > > (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 looks= =20 > > to me like that the PlatformRecovery#### should still be attempted=20 > > for the case of that processing of BootOrder does NOT result in=20 > > success (according to section 3.4 in UEFI 2.8). In other words, I=20 > > think we should check PCD "PcdPlatformRecoverySupport" instead of=20 > > Local variable > "PlatformRecovery" > > (from OsIndications variable) like the code below. What do you guys=20 > > think? If you need a meeting or short talk to discuss this, feel=20 > > free to let me > know. > > > > if (!BootSuccess) { > > - if (PlatformRecovery) { > > + if (PcdGetBool (PcdPlatformRecoverySupport)) { > > LoadOptions =3D EfiBootManagerGetLoadOptions (&LoadOptionCount,= =20 > > 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? OsRecovery#### doesn't have an implement yet, we should co-work with the O= S vendor to define the operation. For now, there is no requirement. > > > > Moreover, I saw that both of you had a discussion about "Default=20 > > PlatformRecovery", but I can't figure out the connection between the= =20 > > discussion and the final code change. Isn't the "Default PlatformRecov= ery" > > part of the Platform Recovery feature? At this moment, we don't have= =20 > > OS recovery support, so I think that NO platform recovery support=20 > > can be identified as NO boot option recovery support. For this case,= =20 > > shouldn't we use PCD "PcdPlatformRecoverySupport" to control=20 > > "Default PlatformRecovery" as well? For the next step, I think we=20 > > need to get further clarification from USWG to either not tie=20 > > "Default Boot Behavior" with PlatformRecovery or update the=20 > > description to the > following: > > - If system firmware supports Platform recovery as described in=20 > > Section 3.4.2, system firmware must include a PlatformRecovery####=20 > > variable specifying a short-form File Path Media Device Path.... As I said above the 'Default Platform Recovery' refer to the short-form fi= le path boot. When the PcdPlatformRecoverySupport is TRUE, it is part of Pl= atformRecovery. Ohterwise, it is not part of platform recovery and we still= need to support it because of the capability issue. And that isn't conflic= t with the spec. Thanks, Zhichao > > > > Regards, > > Sunny Wang > >