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.web10.6276.1576641261514763406 for ; Tue, 17 Dec 2019 19:54:22 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0255afb0c7=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 xBI3nXSZ013044; Wed, 18 Dec 2019 03:54:18 GMT Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) by mx0b-002e3701.pphosted.com with ESMTP id 2wy5rwaa25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Dec 2019 03:54:17 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2354.austin.hpe.com (Postfix) with ESMTPS id EB5DD140; Wed, 18 Dec 2019 03:54:16 +0000 (UTC) Received: from G4W9326.americas.hpqcorp.net (16.208.32.96) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Dec 2019 03:54:17 +0000 Received: from G4W10204.americas.hpqcorp.net (2002:10cf:5210::10cf:5210) by G4W9326.americas.hpqcorp.net (2002:10d0:2060::10d0:2060) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Dec 2019 03:54:16 +0000 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (15.241.52.11) by G4W10204.americas.hpqcorp.net (16.207.82.16) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 18 Dec 2019 03:54:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ep0tDXUB1dUDkXZLhzWoSIWU8J208kRmqEY7niCfmjlXf16/726lnVbzAGt7+i4es57rr+Cw3TbSDYSZLDRAHamRUSGgN1NZndgBGWLyqQwjfoDDtF94hO5ddwHB3xXjMMAeo9fbkBcE/h94GDNLHr/iLTgBodiy/LhgIHmyMjU4Hnk/euYjkR6VHJVUtx0R2CgdYuHBNQ8wVqvv2AFYZig0wd4b6Zm471mm6n5xykUmwqsVzvhX4AdF4t2rRekRRGXA4JWQEW+BVAZV2/qtWx0s61fWEnyWMR/f78DrCGURqalJfBFn651if/Jbcc6ZC8/uvXbHecIX44Nshx0yzA== 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=F19bQ3mb8Zv84yz1B5LqbPlhC0VDocQr9iSSbjZDnZ0=; b=VTTLNwJbHrE0q3c2tvu6LGZ7Xjv6UNWkfElvZG1l9g7LmDChnnaRYKy9y0WIH3cLv+jLgXXWStlt3+pX8lIvirA1FzDxyUQ4b+ZmzqA6w1SR8K2HpEb+xgZ/4MTtGUS1sqkaFiaeoiusMleZFSSJA77194D324wIGZdzJA9ch6Xc7l6rdnax0mwd2PEMo+hkiHkoRFc5U09T9bxOLwgIARXgAEJv0EY+jatsHHqehw1i02MsU20LfjLCtN+xJpjsgsnn3uMa1YNFquDMhW6mFlp50+guVZ8KmU/2b1vLqinFVCSV7RhAhpUHobgw6FjzJioyBHncv75FtmbsWpWaMQ== 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 DF4PR8401MB1307.NAMPRD84.PROD.OUTLOOK.COM (10.169.93.143) by DF4PR8401MB0442.NAMPRD84.PROD.OUTLOOK.COM (10.169.83.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.17; Wed, 18 Dec 2019 03:54:14 +0000 Received: from DF4PR8401MB1307.NAMPRD84.PROD.OUTLOOK.COM ([fe80::7969:cbbd:6156:5fb4]) by DF4PR8401MB1307.NAMPRD84.PROD.OUTLOOK.COM ([fe80::7969:cbbd:6156:5fb4%4]) with mapi id 15.20.2538.019; Wed, 18 Dec 2019 03:54:14 +0000 From: "Wang, Sunny (HPS SW)" To: "discuss@edk2.groups.io" , "ashishsingha@nvidia.com" , Jeff Brasen , "Ni, Ray" , "devel@edk2.groups.io" , Laszlo Ersek , "afish@apple.com" CC: "Wang, Jian J" , "Wu, Hao A" , "Gao, Zhichao" , "Kinney, Michael D" , "Wang, Sunny (HPS SW)" Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration Thread-Topic: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration Thread-Index: AQHVsCtol8YfWgI2yUKb+2EDSHqGUae2yXmAgAgDqICAAHKxwA== Date: Wed, 18 Dec 2019 03:54:13 +0000 Message-ID: References: <37D801DD-41E8-452E-9F24-ADF52BFDB676@apple.com> <72ce1d71-2a65-a6c0-1dd8-7628429c5a3c@redhat.com> <746A8D5E-DC45-4D39-9C4D-97A10BE2E0B0@apple.com> <734D49CCEBEEF84792F5B80ED585239D5C35125E@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C352ECA@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C352F7C@SHSMSX104.ccr.corp.intel.com> ,<897d405a-b164-773c-5784-47fb8c4f9040@redhat.com> ,<734D49CCEBEEF84792F5B80ED585239D5C358AD3@SHSMSX104.ccr.corp.intel.com>, <734D49CCEBEEF84792F5B80ED585239D5C35DF72@SHSMSX104.ccr.corp.intel.com>, ,<734D49CCEBEEF84792F5B80ED585239D5C3990F4@SHSMSX104.ccr.corp.intel.com>, In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.133] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a8f2d8be-dfcc-4180-88a2-08d7836df294 x-ms-traffictypediagnostic: DF4PR8401MB0442: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:800; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(136003)(376002)(396003)(39860400002)(346002)(51444003)(189003)(199004)(51914003)(50084003)(13464003)(45080400002)(7696005)(55016002)(52536014)(316002)(7416002)(478600001)(30864003)(966005)(9686003)(8936002)(110136005)(5660300002)(71200400001)(66556008)(66946007)(66446008)(4326008)(66476007)(64756008)(186003)(8676002)(19627235002)(81156014)(26005)(54906003)(86362001)(53546011)(6506007)(33656002)(76116006)(2906002)(81166006)(579004)(569006);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR8401MB0442;H:DF4PR8401MB1307.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A: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: 9fRljq+GM/qL+eG9pHcqUevWBrkYZ1zlhWUxAwXnuME6Bj7BLlvO3Exchl3yp0p07CBN15F7rBOpEChIRnRJ50ungtqqU3Ixh/9i6VxH+zpX/2LTBmuFypB7GA0N7HtdxRG3fg16RYcCUh7W7fHKTSWzRX7T1LrdEpAMRr8ZclfkxPJYLeKwvnlNOyOSxJZWD6Rq1UPc/EJO6gcebIbdNBdhBwYgU+qA6RN4ljdyF8amplttWmgaP97pKDmFr+/CkjosD/AACeI8kHh3+WbZmoVK7tvliAZqtQ6cTxAF3o8LRO0i6OQytlxbckENDK/0PrDmYpDuEPpEZGUtqKRLD5QCS7rw5Sb3L0TEn5lNbRg7lh/nJ37609wHKny4jOaoKSRAW8aSbeiBBxjoziyU2W49hRT/aq6SF+6QyfSRQKLRWS6VLz6GVjdrNHiyZpjGiJZ9tknYZQWhcHqsmBXao5a6EhNvjMbkD3StCtB5E69hpvgQbIZyZ9zqwkta7fhB2xW52xCspsAfaQFOku7CwrOnSz09MXoEKrH8z+Gd5ACiNC83/4UELdTWXzE+hd9L27/prav9Xtnbal0MbwnywkvocFtq2m0pPNVt0SzaZ37im+D8k/ZDIXJi8xngRkZx X-MS-Exchange-CrossTenant-Network-Message-Id: a8f2d8be-dfcc-4180-88a2-08d7836df294 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 03:54:13.9189 (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: U88sY7SgItKhDaaP4v1+eHEDNbYrPvcipDDB7X6RPUQ+cnerozhr0F0VyOtZSdlO9a5nRVzDb4G9LoY0eHXMbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR8401MB0442 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 4 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,18.0.572 definitions=2019-12-17_05:2019-12-17,2019-12-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 malwarescore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912180027 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the delay. Somehow I didn't catch the follow-up email. Thanks for= checking my comments, Ray and Ashish.=20 Yeah, agree. 2.b is better. I will review the code change.=20 Regards, Sunny Wang -----Original Message----- From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of = Ashish Singhal Sent: Wednesday, December 18, 2019 4:16 AM To: Jeff Brasen ; Ni, Ray ; devel@ed= k2.groups.io; Laszlo Ersek ; afish@apple.com; discuss@ed= k2.groups.io Cc: Wang, Jian J ; Wu, Hao A ; = Gao, Zhichao ; Kinney, Michael D Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automati= c BM enumeration I have submitted a patch based on 2.b as suggested by Ray. I am open to ma= king changes in the structure of the protocol functions as well as the verb= al description. Please let me know what you all think about it. Thanks Ashish ________________________________ From: Jeff Brasen Sent: Thursday, December 12, 2019 10:52 AM To: Ni, Ray ; devel@edk2.groups.io ; Laszlo Ersek ; afish@apple.com ; dis= cuss@edk2.groups.io Cc: Ashish Singhal ; Wang, Jian J ; Wu, Hao A ; Gao, Zhichao ; Kinney, Michael D Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Thanks for the summary Ray, for the problem summary only thing I would add= would be that platform also wants to create/modify boot options when full = enumeration is requested as well. For solutions I prefer option 2 as we don't have to put the same logic eve= rywhere of how to modify the default enumerated list. And if we do that 2b = makes more sense as then we don't have to modify all of the existing platfo= rms. I see two things the platform would need to do. 1. Update list created in BmEnumerateBootOptions 2. Delete any no longer valid platform created boot options Thanks, Jeff ________________________________ From: Ni, Ray Sent: Wednesday, December 11, 2019 7:00 AM To: Jeff Brasen ; devel@edk2.groups.io ; Laszlo Ersek ; afish@apple.com ; discuss@edk2.groups.io Cc: Ashish Singhal ; Wang, Jian J ; Wu, Hao A ; Gao, Zhichao ; Kinney, Michael D Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n External email: Use caution opening links or attachments Jeff, Tom from AMD booked the meeting for SEV discussion months ago. I am afraid= there is no time for this discussion. Let's try to resolve it in mails. Firstly, let me rephase the problem and your proposed solutions here (subj= ective + verb + objective). Sunny's input is also included. Hope Mike K and= others can provide inputs. Personally, I agree with 2.b. It helps us to gradually migrate the Platfor= mBootManagerLib to PlatformBootManager protocol. Protocol with Revision fie= ld helps to reduce the impact to old platforms with new APIs added. **Problem: Platform requires certain BlockIo/SimpleFileSystem/LoadFile= instances don't cause Boot#### created. It's a need of platform customizat= ion. **Details: Boot#### for BlockIo/SimpleFileSystem/LoadFile are created = by API EfiBootMangerRefreshAllBootOptions(). There are 2 places that call t= his API: 1. Platform Boot Manager calls the API (usually in the full configurati= on boot path) 2. UiApp calls the API when entering "Boot Manager" page and "Boot Main= tenance Manager" page. Platform can change Platform Boot Manager to remove the unneeded Boot#### = in case #1. But platform has no way to remove the Boot#### created in case #2 . **Potential solutions: 1. Update UiApp * Define a new PCD and a new event group. If PCD is TRUE, UiApp signals the event. Event callback creates the Boot##= ##. Otherwise, EfiBootManagerRefreshAllBootOptions() is called. * Add a new PlatformBootManagerLib API (implemented by platform). UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (ne= ed to coordinate rollout with updates to all platforms). * Add a new protocol (implemented by platform). UiApp calls the new protocol if it exists otherwise calls EfiBootManagerRe= freshAllBootOption. 1. Update EfiBootManagerRefreshAllBootOptions() * Add a new library class (implemented by platform). EfiBootManagerRefreshAllBootOption() calls the new library class. * Add a new PlatformBootManager protocol (implemented by platform). EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists. Thanks, Ray From: Jeff Brasen Sent: Wednesday, December 11, 2019 4:46 AM To: Ni, Ray ; devel@edk2.groups.io; Laszlo Ersek ; afish@apple.com; discuss@edk2.groups.io Cc: Ashish Singhal ; Wang, Jian J ; Wu, Hao A ; Gao, Zhichao ; Kinney, Michael D Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Can we discuss this at the design meeting this week (12/12)? Thanks, Jeff ________________________________ From: Jeff Brasen Sent: Thursday, November 14, 2019 10:04 AM To: Ni, Ray >; devel@edk2.groups= .io >; Laszlo Ersek >; afis= h@apple.com > Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Yes, I think that would be good. Summarizing everything in this thread Problem: Platform needs to customize the boot options, this can be done fo= r normal boot but the UiApp calls EfiBootManagerRefreshAllBootOption in a c= ouple places. Potential solutions: 1 - Define new PCD and event group if PCD is set true then signal event in= stead of calling EfiBootManagerRefreshAllBootOption in UiApp 2 - Add new function to boot manager library and replace call to EfiBootMa= nagerRefreshAllBootOption in UiApp (need to coordinate rollout with updates= to all platform. 3 - Add new protocol with new function, if supported call this otherwise c= all EfiBootManagerRefreshAllBootOption as is done now 4 - For 2/3 use generic function so we don't need new APIs for future exp= ansion 5 - Update EfiBootManagerRefreshAllBootOption to call platform specific fu= nction. Thanks, Jeff From: Ni, Ray > Sent: Wednesday, November 13, 2019 7:09 PM To: devel@edk2.groups.io; Jeff Brasen >; Laszlo Ersek >; afish@apple.com Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Jeff, I think it's a good topic that we could discuss in the open design meeting= . Are you ok to present the problem you have and discuss the potential solut= ions in that meeting? https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting Thanks, Ray From: devel@edk2.groups.io > On Behalf Of Jeff Brasen Sent: Thursday, November 14, 2019 2:43 AM To: Ni, Ray >; devel@edk2.groups= .io; Laszlo Ersek >; afish@apple.com Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Thinking about this more I think we could do this with a PCD and a new gro= up event without having to define any new function interfaces. We could change UiApp and BootManagerMenuApp (and any others that are rele= vant) from EfiBootManagerRefreshAllBootOption (); to if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) { EFI_EVENT Event; gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid, &Event )= ; gBS->SignalEvent (Event); gBS->CloseEvent (Event); } else { EfiBootManagerRefreshAllBootOption (); } Then a platform that wants to do this on its own would just set this pcd a= nd create a group event and do what it needs to do there. Thanks, Jeff ________________________________ From: Jeff Brasen > Sent: Monday, November 11, 2019 5:00 PM To: Ni, Ray >; devel@edk2.groups= .io >; Laszlo Ersek >; afis= h@apple.com > Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n I am not sure a PCD would work (unless I am missing something) We do want = to do a connect all and re-enumerate in UiApp but we need the platform code= to be involved in that process. Thanks, Jeff ________________________________ From: Ni, Ray > Sent: Monday, November 11, 2019 4:58 PM To: devel@edk2.groups.io >; Jeff Brasen >; Laszlo Ersek >; afish@apple.com > Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n Jeff, If adding a PCD to control UiApp can meet the real needs, I prefer to do i= n that way instead of adding new APIs to PlatformBootManagerLib. Thanks, Ray From: devel@edk2.groups.io > On Behalf Of Jeff Brasen Sent: Tuesday, November 12, 2019 6:58 AM To: Laszlo Ersek >; Ni, Ray >; devel@edk2.groups.io; afish@apple.com Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n If we are concerned about deploying this and breaking builds we could do t= his via a new protocol instead. In that case though we would leave the old = default behavior in the code to handle platforms that didn't implement the = new protocol, so this might not be the cleanest way to deploy this. We could also look at adding a generic platform boot hook function (either= as a library function or protocol) if we wanted to limit the number of dis= ruption on new customization hooks. Something like EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *Con= textData OPTIONAL) Where Notification type describes where we are that we want platform to po= tentially handle and ContextData is per type caller allocated data that pro= vides additional in/out data. This has the same issue of leaving the curren= t default behavior in place for unsupported types as well as being a less t= han specific function to describe. Thanks, Jeff ________________________________ From: Laszlo Ersek > Sent: Friday, November 8, 2019 9:37 AM To: Jeff Brasen >; Ni, Ray <= ray.ni@intel.com>; devel@edk2.groups.io >; afi= sh@apple.com > Cc: Ashish Singhal >; Wang, Jian J >; Wu,= Hao A >; Gao, Zhichao >; Kinney, Michael D > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeratio= n On 11/07/19 18:46, Jeff Brasen wrote: > Fixing UiApp seems reasonable, I do think we would want a hook to the pl= atform library in here as the enumeration that occurs in the UiApp is inten= ded to do a full enumeration of the system and there may be platform specif= ics to how that occurs. Fully agreed -- entering UiApp should expose everything bootable in the sy= stem, unless (perhaps) PlatformBootManagerLib specifically thinks otherwise= . Of course, then we arrive (again) at the problem that a call in UefiBootMa= nagerLib, to a *new* PlatformBootManagerLib API, will break tens of out-of-= tree platforms. :) I think that can be prevented, as follows; but it will take quite some tim= e: - introduce the new function declaration in "PlatformBootManagerLib.h", - modify all platforms (in tree and out of tree) to implement (define) the= new function, - call the new function from UefiBootManagerLib For some history / background on this kind of problem, I suggest reading through: https://bugzilla.tianocore.org/show_bug.cgi?id=3D982=20 Thanks, Laszlo > From: Ni, Ray > > Sent: Thursday, November 7, 2019 12:21 AM > To: devel@edk2.groups.io; Jeff Brasen=20 > >;=20 > afish@apple.com > Cc: Ashish Singhal=20 > >; Laszlo=20 > Ersek >; Wang, Jian J=20 > >; Wu, Hao A=20 > >; Gao, Zhichao=20 > >; Kinney, Michael= =20 > D > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > I treat the issue in this way: > > 1. Platform Boot Manager library does a good job. It doesn't always c= all RefreshAll() API to auto-create the boot options > 2. But UiApp doesn't. It constantly call RefreshAll(). > > Do you think that we can fix UiApp instead? For example, introducing a P= CD to control the boot option refresh behavior? > > Thanks, > Ray > > From:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>=20 > oups.io%3cmailto:devel@edk2.groups.io>>> On Behalf Of Jeff Brasen > Sent: Thursday, November 7, 2019 3:02 PM > To: Ni, Ray=20 > ilto:ray.ni@intel.com>>>; afish@apple.com > Cc:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal=20 > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek=20 > cmailto:lersek@redhat.com>>>; Wang, Jian J=20 > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A=20 > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao=20 > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D=20 > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > The issue is there are some auto created options we do not want on our p= latform. > Get Outlook for=20 > Android ei36&d=3DDwIF-g&c=3DC5b8zRQO1miGmBeVZ2LFWg&r=3DZ9cLgEMdGZCI1_R0bW6KqOAGz= CXLJ > UR24f8N3205AYw&m=3DEzQH7xR5u0kejdb3Oa18jqGGrV5AO_ROvd_Y_ajQQMk&s=3DyaH1Z= cO > LL9iVBCGMBGKtuwgPVbblPxtJooJMnpxn8P0&e=3D > > > ________________________________ > From: Ni, Ray=20 > ilto:ray.ni@intel.com>>> > Sent: Wednesday, November 6, 2019 11:59:31 PM > To: Jeff Brasen=20 > m%3cmailto:jbrasen@nvidia.com>>>;=20 > afish@apple.com=20 > o:afish@apple.com>>> > Cc:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>=20 > oups.io%3cmailto:devel@edk2.groups.io>>>; Ashish Singhal=20 > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek=20 > cmailto:lersek@redhat.com>>>; Wang, Jian J=20 > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A=20 > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao=20 > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D=20 > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > > Jeff, > > RefreshAllBootOption() only modifies/creates the auto-created boot optio= ns. For the boot options created by platform boot manager library, they sta= y with no one touches. And all auto-created boot options are appended in th= e end of boot option list (through BootOrder). > > > > From: Jeff Brasen=20 > m%3cmailto:jbrasen@nvidia.com>>> > Sent: Thursday, November 7, 2019 12:13 PM > To: afish@apple.com; Ni, Ray=20 > ilto:ray.ni@intel.com>>> > Cc:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal=20 > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek=20 > cmailto:lersek@redhat.com>>>; Wang, Jian J=20 > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A=20 > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao=20 > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D=20 > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > > > As the suggestions below made sense, we updated our platform boot manage= r library to behave in this manner and for normal boots everything works we= ll. However the UiApp and boot maintenance applications in EDK2 also call E= fiBootManagerRefreshAllBootOption() when ever a user goes into the menu whi= ch will re-create the skipped boot options with no place for the platform c= ode to intervene. > > > > What about a solution where we add a new Platform library function that = allows for override of the behavior of BmEnumerateBootOptions? For example,= either a function or protocol that takes the same parameters as this funct= ion and only if it returns NULL then we continue to the default enumeration= code. Or a function call inserted at the end that would modify the load o= ption array after the system does the standard enumeration. > > > > -Jeff > > > > From: afish@apple.com=20 > o:afish@apple.com>>> > Sent: Wednesday, November 6, 2019 9:20 AM > To: Ni, Ray=20 > ilto:ray.ni@intel.com>>> > Cc:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>; Jeff Brasen=20 > m%3cmailto:jbrasen@nvidia.com>>>; Ashish Singhal=20 > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek=20 > cmailto:lersek@redhat.com>>>; Wang, Jian J=20 > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A=20 > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao=20 > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Mike Kinney=20 > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > > > Ray, > > > > Is there an obvious hook point we could point Jeff and Ashish at? > > > > Long term it would be a good idea to have a Wiki page to give some guida= nce on how to customize the BDS. > > > > Thanks, > > > > Andrew Fish > > > > On Nov 5, 2019, at 9:20 PM, Ni, Ray >> wrote: > > > > Andrew, > > I agree with your opinion. > > It's expected that Platform Boot Manager lib calls EfiBootManagerRefresh= AllBootOption() only in full configuration boot path. > > The full configuration boot path is chosen when hardware changes=20 > happen. So it's not expected EfiBootManagerRefresh...() be called in eve= ry boot. > > So you could: > > 1. Delete the auto-created option pointing to LoadFile instance > 2. Create your own one with customized description. > > > > > > From: afish@apple.com=20 > o:afish@apple.com>>> > Sent: Wednesday, November 6, 2019 10:47 AM > To:=20 > devel@edk2.groups.io ups.io%3cmailto:devel@edk2.groups.io>>;=20 > jbrasen@nvidia.com > Cc: Ashish Singhal=20 > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek=20 > cmailto:lersek@redhat.com>>>; Ni, Ray=20 > ilto:ray.ni@intel.com>>>; Wang, Jian J=20 > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A=20 > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao=20 > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D=20 > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM=20 > enumeration > > > > > > > > On Nov 5, 2019, at 7:34 PM, Jeff Brasen >> wrot= e: > > > > Wouldn't having a variable that we create and delete on every boot put u= nnecessary stress on the SPI-NOR that the variable store lives on? > What about the alternative approach where we allow the platform code to = modify the attributes of the auto created variable to disable it with hidde= n/!active but still match for detection purposes so that it doesn't delete = and recreate the modified variable each boot? That way all the logic on wha= t to disable can still be in the platform code and all the existing logic i= n the boot manager can stay basically the same? > > What changes every boot that forces the variable to need to get modified= ? > > I would assume the NOR driver is smart enough to not update a variable t= hat is not changing. > > The custom BDS could could only create the variable for this device if i= t does not exist. > > [JB] The current flow with no changes in the boot manager would be as=20 > follows > > > > 1. Scan for instance of the boot option in the variables > 2. It will not be found, so create a new boot option store it to a va= riable and update BootOrder > 3. Platform code runs creates the options for the boot option it want= s and writes those to variable store > 4. Delete/disable the boot option in the variable store > > > > When you reboot it won't find the variable so 1/2/4 will re-occur > > > > The code that does this (1/2) is EfiBootManagerRefreshAllBootOption in= =20 > BmBoot.c > > > > If you modify the variable to disable it with hidden/not active it would= delete that and create a new one as well as the code wouldn't recognize th= at is the same boot option. > > > > If however we modify EfiBootManagerFindLoadOption to not compare the att= ributes (at least allow for differences in active and hidden) then the when= it refreshes every thing it would see the match and not delete/create a ne= w variable in the store and thus we wouldn't have changes every boot. > > > > > > Jeff, > > > > Sorry if I'm a little off on the sequence of things as the platform I wo= rk on day to day has a custom BDS and does not use this library..... I thou= gh the patch changed BmEnumerateBootOptions(), so that is going to change h= ow EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch= as given is invalid as it changed the behavior of the public library API f= or EfiBootManagerRefreshAllBootOption() [1] so for the patch to be valid it= would need to change the comments to reflect the new behavior. This is kin= d of what Laszlo's technical debt comment was about. > > > > I think Laszlo advocated having the BDS platform specific code make sure= the boot variables are in the correct state. That should happen before the= Boot Manager code runs, and it is not clear to me why the Boot Manager co= uld would need to run if you have a valid EFI nvram variable to boot from. > > > > I think the question is how is your use case different than the boot var= iable that Windows installs? If it works kind of the same way then the answ= er is to have the BDS platform specific code write the boot variable. > > > > > > [1] > > /** > > The function creates boot options for all possible bootable medias in = the following order: > > 1. Removable BlockIo - The boot option only points to the r= emovable media > > device, like USB key, DVD, Floppy et= c. > > 2. Fixed BlockIo - The boot option only points to a Fix= ed blockIo device, > > like HardDisk. > > 3. Non-BlockIo SimpleFileSystem - The boot option points to a device= =20 > supporting > > SimpleFileSystem Protocol, but not= =20 > supporting BlockIo > > protocol. > > 4. LoadFile - The boot option points to the media = supporting > > LoadFile protocol. > > Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot=20 > Behavior > > > > The function won't delete the boot option not added by itself. > > **/ > > VOID > > EFIAPI > > EfiBootManagerRefreshAllBootOption ( > > VOID > > ); > > > > Thanks, > > > > Andrew Fish > > > > Thanks, > > Andrew Fish > > Thanks, > > Jeff > > ________________________________ > > This email message is for the sole use of the intended recipient(s) and = may contain confidential information. Any unauthorized review, use, disclo= sure or distribution is prohibited. If you are not the intended recipient,= please contact the sender by reply email and destroy all copies of the ori= ginal message. > > ________________________________ > > >