From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx.groups.io with SMTP id smtpd.web11.8239.1576658589497859601 for ; Wed, 18 Dec 2019 00:43:10 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2019 00:43:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,328,1571727600"; d="scan'208";a="217787081" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga006.jf.intel.com with ESMTP; 18 Dec 2019 00:43:08 -0800 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 18 Dec 2019 00:43:08 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 18 Dec 2019 00:43:07 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.90]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.195]) with mapi id 14.03.0439.000; Wed, 18 Dec 2019 16:43:06 +0800 From: "Ni, Ray" To: "Wang, Sunny (HPS SW)" , "discuss@edk2.groups.io" , "ashishsingha@nvidia.com" , Jeff Brasen , "devel@edk2.groups.io" , Laszlo Ersek , "afish@apple.com" CC: "Wang, Jian J" , "Wu, Hao A" , "Gao, Zhichao" , "Kinney, Michael D" 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: AQHVjtTBfs56XIdrLUS3rD3UlLLaAqd0BEOAgAfitPD//4ZKgIAAGusAgAABkQCAAARWgIAABc2AgAAJNQCAAD03AIAAdMAAgAAS3ACAABdZAIAAX/iAgAAHo4CAABRiAIAAixowgABX2YCAAMcwAIAAs8oA//97lgCAAIoFAIAAKeMAgAF/U4CABSEZAIAAlohA//968wAAWX1kAAAgFutgAA7CSIAFI1Q5gAAlZO8gADkfk4ABAHUGgAAQBM2AABrW2RA= Date: Wed, 18 Dec 2019 08:43:05 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C3A1928@SHSMSX104.ccr.corp.intel.com> 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, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjFhZTIzMjgtNDgzMS00N2U1LTkxMDItM2RlZGUyMjYzMzdlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSXp4YU9OeFwvTE5RQkM4Q3c2Q2hCaTRMYzBocWxqT3o4TzJab1R2bVRtMXNIejdMQkJMM24wZVd6WndKejJ5d1IifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action 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, Thanks for your comments. Thanks, Ray > -----Original Message----- > From: Wang, Sunny (HPS SW) > Sent: Wednesday, December 18, 2019 11:54 AM > 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 automa= tic BM enumeration >=20 > Sorry for the delay. Somehow I didn't catch the follow-up email. Thanks = for checking my comments, Ray and Ashish. > Yeah, agree. 2.b is better. I will review the code change. >=20 > Regards, > Sunny Wang >=20 > -----Original Message----- > From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf O= f Ashish Singhal > Sent: Wednesday, December 18, 2019 4:16 AM > To: Jeff Brasen ; Ni, Ray ; devel@= edk2.groups.io; Laszlo Ersek > ; afish@apple.com; discuss@edk2.groups.io > Cc: Wang, Jian J ; Wu, Hao A = ; Gao, Zhichao ; > Kinney, Michael D > Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automa= tic BM enumeration >=20 > I have submitted a patch based on 2.b as suggested by Ray. I am open to = making changes in the structure of the protocol > functions as well as the verbal description. Please let me know what you= all think about it. >=20 > 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 ; 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 enumerat= ion >=20 > Thanks for the summary Ray, for the problem summary only thing I would a= dd would be that platform also wants to > create/modify boot options when full enumeration is requested as well. >=20 > For solutions I prefer option 2 as we don't have to put the same logic e= verywhere 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 platforms. >=20 > I see two things the platform would need to do. >=20 > 1. Update list created in BmEnumerateBootOptions > 2. Delete any no longer valid platform created boot options >=20 >=20 > Thanks, >=20 > Jeff >=20 > ________________________________ > 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 enumerat= ion >=20 > External email: Use caution opening links or attachments >=20 >=20 > Jeff, >=20 > Tom from AMD booked the meeting for SEV discussion months ago. I am afra= id there is no time for this discussion. >=20 > Let's try to resolve it in mails. >=20 >=20 >=20 > Firstly, let me rephase the problem and your proposed solutions here (su= bjective + verb + objective). Sunny's input is also > included. Hope Mike K and others can provide inputs. >=20 > Personally, I agree with 2.b. It helps us to gradually migrate the Platf= ormBootManagerLib to PlatformBootManager > protocol. Protocol with Revision field helps to reduce the impact to old= platforms with new APIs added. >=20 >=20 >=20 > **Problem: >=20 > Platform requires certain BlockIo/SimpleFileSystem/LoadFi= le instances don't cause Boot#### created. It's a need > of platform customization. >=20 >=20 >=20 > **Details: >=20 > Boot#### for BlockIo/SimpleFileSystem/LoadFile are create= d by API EfiBootMangerRefreshAllBootOptions(). There > are 2 places that call this API: >=20 > 1. Platform Boot Manager calls the API (usually in the full configura= tion boot path) > 2. UiApp calls the API when entering "Boot Manager" page and "Boot Ma= intenance Manager" page. >=20 >=20 >=20 > Platform can change Platform Boot Manager to remove the unneeded Boot###= # in case #1. >=20 > But platform has no way to remove the Boot#### created in case #2 . >=20 >=20 >=20 > **Potential solutions: >=20 > 1. Update UiApp > * Define a new PCD and a new event group. >=20 > If PCD is TRUE, UiApp signals the event. Event callback creates the Boot= ####. Otherwise, > EfiBootManagerRefreshAllBootOptions() is called. >=20 > * Add a new PlatformBootManagerLib API (implemented by platform). >=20 > UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (= need to coordinate rollout with updates to all > platforms). >=20 > * Add a new protocol (implemented by platform). >=20 > UiApp calls the new protocol if it exists otherwise calls EfiBootManager= RefreshAllBootOption. >=20 >=20 >=20 > 1. Update EfiBootManagerRefreshAllBootOptions() > * Add a new library class (implemented by platform). >=20 > EfiBootManagerRefreshAllBootOption() calls the new library class. >=20 > * Add a new PlatformBootManager protocol (implemented by platform= ). >=20 > EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists= . >=20 >=20 >=20 > Thanks, >=20 > Ray >=20 >=20 >=20 > 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 enumerat= ion >=20 >=20 >=20 > Can we discuss this at the design meeting this week (12/12)? >=20 >=20 >=20 > Thanks, >=20 > Jeff >=20 > ________________________________ >=20 > From: Jeff Brasen > Sent: Thursday, November 14, 2019 10:04 AM > To: Ni, Ray >; devel@edk2.grou= ps.io > >; Laszlo Ersek >; > afish@apple.com > > Cc: Ashish Singhal >; Wang, Jian J > >; Wu, Hao A >; > Gao, Zhichao >; Kinn= ey, Michael D > > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > Yes, I think that would be good. >=20 >=20 >=20 > Summarizing everything in this thread >=20 >=20 >=20 > Problem: Platform needs to customize the boot options, this can be done = for normal boot but the UiApp calls > EfiBootManagerRefreshAllBootOption in a couple places. >=20 >=20 >=20 > Potential solutions: >=20 > 1 - Define new PCD and event group if PCD is set true then signal event = instead of calling > EfiBootManagerRefreshAllBootOption in UiApp >=20 > 2 - Add new function to boot manager library and replace call to EfiBoot= ManagerRefreshAllBootOption in UiApp (need to > coordinate rollout with updates to all platform. >=20 > 3 - Add new protocol with new function, if supported call this otherwise= call EfiBootManagerRefreshAllBootOption as is > done now >=20 > 4 - For 2/3 use generic function so we don't need new APIs for future e= xpansion >=20 > 5 - Update EfiBootManagerRefreshAllBootOption to call platform specific = function. >=20 >=20 >=20 > Thanks, > Jeff >=20 >=20 >=20 >=20 >=20 > 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 >; Kinn= ey, Michael D > > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > Jeff, >=20 > I think it's a good topic that we could discuss in the open design meeti= ng. >=20 > Are you ok to present the problem you have and discuss the potential sol= utions in that meeting? >=20 > https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting >=20 >=20 >=20 > Thanks, >=20 > Ray >=20 >=20 >=20 > From: devel@edk2.groups.io > On > Behalf Of Jeff Brasen > Sent: Thursday, November 14, 2019 2:43 AM > To: Ni, Ray >; devel@edk2.grou= ps.io; Laszlo > Ersek >; afish@apple.com > Cc: Ashish Singhal >; Wang, Jian J > >; Wu, Hao A >; > Gao, Zhichao >; Kinn= ey, Michael D > > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > Thinking about this more I think we could do this with a PCD and a new g= roup event without having to define any new > function interfaces. >=20 >=20 >=20 > We could change UiApp and BootManagerMenuApp (and any others that are re= levant) from >=20 >=20 >=20 > EfiBootManagerRefreshAllBootOption (); >=20 >=20 >=20 > to >=20 >=20 >=20 > if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) { >=20 > EFI_EVENT Event; >=20 > gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid, &Event= ); >=20 > gBS->SignalEvent (Event); >=20 > gBS->CloseEvent (Event); >=20 > } else { >=20 > EfiBootManagerRefreshAllBootOption (); >=20 > } >=20 >=20 >=20 > Then a platform that wants to do this on its own would just set this pcd= and create a group event and do what it needs to > do there. >=20 >=20 >=20 > Thanks, >=20 > Jeff >=20 > ________________________________ >=20 > From: Jeff Brasen > > Sent: Monday, November 11, 2019 5:00 PM > To: Ni, Ray >; devel@edk2.grou= ps.io > >; Laszlo Ersek >; > afish@apple.com > > Cc: Ashish Singhal >; Wang, Jian J > >; Wu, Hao A >; > Gao, Zhichao >; Kinn= ey, Michael D > > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > I am not sure a PCD would work (unless I am missing something) We do wan= t to do a connect all and re-enumerate in > UiApp but we need the platform code to be involved in that process. >=20 >=20 >=20 > Thanks, >=20 > Jeff >=20 > ________________________________ >=20 > 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 >; Kinn= ey, Michael D > > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > Jeff, >=20 > If adding a PCD to control UiApp can meet the real needs, I prefer to do= in that way instead of adding new APIs to > PlatformBootManagerLib. >=20 >=20 >=20 > Thanks, >=20 > Ray >=20 >=20 >=20 > 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 >; Kinn= ey, Michael D > > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > If we are concerned about deploying this and breaking builds we could do= this via a new protocol instead. In that case > though we would leave the old default behavior in the code to handle pla= tforms that didn't implement the new protocol, > so this might not be the cleanest way to deploy this. >=20 >=20 >=20 > We could also look at adding a generic platform boot hook function (eith= er as a library function or protocol) if we wanted > to limit the number of disruption on new customization hooks. Something = like >=20 >=20 >=20 > EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *C= ontextData OPTIONAL) >=20 >=20 >=20 > Where Notification type describes where we are that we want platform to = potentially handle and ContextData is per type > caller allocated data that provides additional in/out data. This has the= same issue of leaving the current default behavior > in place for unsupported types as well as being a less than specific fun= ction to describe. >=20 >=20 >=20 > Thanks, >=20 > Jeff >=20 >=20 >=20 > ________________________________ >=20 > From: Laszlo Ersek > > Sent: Friday, November 8, 2019 9:37 AM > To: Jeff Brasen >; Ni, Ray= >; > devel@edk2.groups.io >; > afish@apple.com > > Cc: Ashish Singhal >; Wang, Jian J > >; Wu, Hao A >; > Gao, Zhichao >; Kinn= ey, Michael D > > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion >=20 >=20 >=20 > On 11/07/19 18:46, Jeff Brasen wrote: > > Fixing UiApp seems reasonable, I do think we would want a hook to the = platform library in here as the enumeration that > occurs in the UiApp is intended to do a full enumeration of the system a= nd there may be platform specifics to how that > occurs. >=20 > Fully agreed -- entering UiApp should expose everything bootable in the = system, unless (perhaps) PlatformBootManagerLib > specifically thinks otherwise. >=20 > Of course, then we arrive (again) at the problem that a call in UefiBoot= ManagerLib, to a *new* PlatformBootManagerLib > API, will break tens of out-of-tree platforms. :) >=20 > I think that can be prevented, as follows; but it will take quite some t= ime: >=20 > - introduce the new function declaration in "PlatformBootManagerLib.h", > - modify all platforms (in tree and out of tree) to implement (define) t= he new function, > - call the new function from UefiBootManagerLib >=20 > For some history / background on this kind of problem, I suggest reading > through: >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__bugzilla.tianoc= ore.org_show-5Fbug.cgi-3Fid-3D982&d=3DDwIF- > g&c=3DC5b8zRQO1miGmBeVZ2LFWg&r=3DZ9cLgEMdGZCI1_R0bW6KqOAGzCXLJUR24f8N320= 5AYw&m=3DEzQH7xR5u0kejdb3Oa18jq > GGrV5AO_ROvd_Y_ajQQMk&s=3DcTZCJVE04A0qq4imb3Pma8jdJIrunDornyDXBty-1Uk&e= =3D >=20 > Thanks, > Laszlo >=20 > > From: Ni, Ray > > > Sent: Thursday, November 7, 2019 12:21 AM > > To: devel@edk2.groups.io; Jeff Brasen > > >; > > afish@apple.com > > Cc: Ashish Singhal > > >; Laszlo > > Ersek >; Wang, Jian J > > >; Wu, Hao A > > >; Gao, Zhichao > > >; Kinney, Michael > > D > > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM > > enumeration > > > > I treat the issue in this way: > > > > 1. Platform Boot Manager library does a good job. It doesn't always= call 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= PCD to control the boot option refresh behavior? > > > > Thanks, > > Ray > > > > From: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>> > > > oups.io%3cmailto:devel@edk2.groups.io>>> On Behalf Of Jeff Brasen > > Sent: Thursday, November 7, 2019 3:02 PM > > To: Ni, Ray > > > ilto:ray.ni@intel.com>>>; afish@apple.com > > Cc: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal > > > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek > > > cmailto:lersek@redhat.com>>>; Wang, Jian J > > > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A > > > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao > > > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D > > > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM > > enumeration > > > > The issue is there are some auto created options we do not want on our= platform. > > Get Outlook for > > Android > ei36&d=3DDwIF-g&c=3DC5b8zRQO1miGmBeVZ2LFWg&r=3DZ9cLgEMdGZCI1_R0bW6KqOA= GzCXLJ > > UR24f8N3205AYw&m=3DEzQH7xR5u0kejdb3Oa18jqGGrV5AO_ROvd_Y_ajQQMk&s=3DyaH= 1ZcO > > LL9iVBCGMBGKtuwgPVbblPxtJooJMnpxn8P0&e=3D > > > > > ________________________________ > > From: Ni, Ray > > > ilto:ray.ni@intel.com>>> > > Sent: Wednesday, November 6, 2019 11:59:31 PM > > To: Jeff Brasen > > > m%3cmailto:jbrasen@nvidia.com>>>; > > afish@apple.com > > > o:afish@apple.com>>> > > Cc: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>> > > > oups.io%3cmailto:devel@edk2.groups.io>>>; Ashish Singhal > > > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek > > > cmailto:lersek@redhat.com>>>; Wang, Jian J > > > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A > > > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao > > > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D > > > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM > > enumeration > > > > > > Jeff, > > > > RefreshAllBootOption() only modifies/creates the auto-created boot opt= ions. For the boot options created by platform > boot manager library, they stay with no one touches. And all auto-create= d boot options are appended in the end of boot > option list (through BootOrder). > > > > > > > > From: Jeff Brasen > > > m%3cmailto:jbrasen@nvidia.com>>> > > Sent: Thursday, November 7, 2019 12:13 PM > > To: afish@apple.com; Ni, Ray > > > ilto:ray.ni@intel.com>>> > > Cc: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>>; Ashish Singhal > > > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek > > > cmailto:lersek@redhat.com>>>; Wang, Jian J > > > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A > > > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao > > > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D > > > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM > > enumeration > > > > > > > > As the suggestions below made sense, we updated our platform boot mana= ger library to behave in this manner and for > normal boots everything works well. However the UiApp and boot maintenan= ce applications in EDK2 also call > EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu= which will re-create the skipped boot options > with no place for the platform code to intervene. > > > > > > > > What about a solution where we add a new Platform library function tha= t allows for override of the behavior of > BmEnumerateBootOptions? For example, either a function or protocol that = takes the same parameters as this function > 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 option array after the system does the standard en= umeration. > > > > > > > > -Jeff > > > > > > > > From: afish@apple.com > > > o:afish@apple.com>>> > > Sent: Wednesday, November 6, 2019 9:20 AM > > To: Ni, Ray > > > ilto:ray.ni@intel.com>>> > > Cc: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>>; Jeff Brasen > > > m%3cmailto:jbrasen@nvidia.com>>>; Ashish Singhal > > > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek > > > cmailto:lersek@redhat.com>>>; Wang, Jian J > > > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A > > > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao > > > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Mike Kinney > > > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM > > 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 gui= dance 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 EfiBootManagerRefre= shAllBootOption() only in full configuration boot > path. > > > > The full configuration boot path is chosen when hardware changes > > happen. So it's not expected EfiBootManagerRefresh...() be called in e= very 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 > > > o:afish@apple.com>>> > > Sent: Wednesday, November 6, 2019 10:47 AM > > To: > > devel@edk2.groups.io > ups.io%3cmailto:devel@edk2.groups.io>>; > > jbrasen@nvidia.com > > Cc: Ashish Singhal > > > ingha@nvidia.com%3cmailto:ashishsingha@nvidia.com>>>; Laszlo Ersek > > > cmailto:lersek@redhat.com>>>; Ni, Ray > > > ilto:ray.ni@intel.com>>>; Wang, Jian J > > > @intel.com%3cmailto:jian.j.wang@intel.com>>>; Wu, Hao A > > > m%3cmailto:hao.a.wu@intel.com>>>; Gao, Zhichao > > > @intel.com%3cmailto:zhichao.gao@intel.com>>>; Kinney, Michael D > > > ichael.d.kinney@intel.com%3cmailto:michael.d.kinney@intel.com>>> > > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM > > enumeration > > > > > > > > > > > > > > > > On Nov 5, 2019, at 7:34 PM, Jeff Brasen > >> wrote: > > > > > > > > Wouldn't having a variable that we create and delete on every boot put= unnecessary stress on the SPI-NOR that the > variable store lives on? > > What about the alternative approach where we allow the platform code t= o modify the attributes of the auto created > variable to disable it with hidden/!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 what to disable c= an still be in the platform code and all the existing > logic in the boot manager can stay basically the same? > > > > What changes every boot that forces the variable to need to get modifi= ed? > > > > I would assume the NOR driver is smart enough to not update a variable= that is not changing. > > > > The custom BDS could could only create the variable for this device if= it does not exist. > > > > [JB] The current flow with no changes in the boot manager would be as > > 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 = variable and update BootOrder > > 3. Platform code runs creates the options for the boot option it wa= nts 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 > > BmBoot.c > > > > > > > > If you modify the variable to disable it with hidden/not active it wou= ld delete that and create a new one as well as the > code wouldn't recognize that is the same boot option. > > > > > > > > If however we modify EfiBootManagerFindLoadOption to not compare the a= ttributes (at least allow for differences in > active and hidden) then the when it refreshes every thing it would see t= he match and not delete/create a new 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 = work on day to day has a custom BDS and does not use > this library..... I though the patch changed BmEnumerateBootOptions(), s= o that is going to change how > EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch= as given is invalid as it changed the behavior of > the public library API for EfiBootManagerRefreshAllBootOption() [1] so f= or the patch to be valid it would need to change > the comments to reflect the new behavior. This is kind of what Laszlo's = technical debt comment was about. > > > > > > > > I think Laszlo advocated having the BDS platform specific code make su= re 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 could 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 v= ariable that Windows installs? If it works kind of the > same way then the answer is to have the BDS platform specific code write= the boot variable. > > > > > > > > > > > > [1] > > > > /** > > > > The function creates boot options for all possible bootable medias i= n the following order: > > > > 1. Removable BlockIo - The boot option only points to the= removable media > > > > device, like USB key, DVD, Floppy = etc. > > > > 2. Fixed BlockIo - The boot option only points to a F= ixed blockIo device, > > > > like HardDisk. > > > > 3. Non-BlockIo SimpleFileSystem - The boot option points to a device > > supporting > > > > SimpleFileSystem Protocol, but not > > supporting BlockIo > > > > protocol. > > > > 4. LoadFile - The boot option points to the medi= a supporting > > > > LoadFile protocol. > > > > Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot > > 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) an= d may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the > sender by reply email and destroy all copies of the original message. > > > > ________________________________ > > > > > >=20 >=20 >=20 >=20 >=20