From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by mx.groups.io with SMTP id smtpd.web12.1390.1576613736459729911 for ; Tue, 17 Dec 2019 12:15:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nvidia.com header.s=n1 header.b=X8Hz/h93; spf=pass (domain: nvidia.com, ip: 216.228.121.65, mailfrom: ashishsingha@nvidia.com) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Tue, 17 Dec 2019 12:15:26 -0800 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 17 Dec 2019 12:15:35 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 17 Dec 2019 12:15:35 -0800 Received: from HQMAIL107.nvidia.com (172.20.187.13) by HQMAIL111.nvidia.com (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Dec 2019 20:15:34 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Dec 2019 20:15:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xx99dg9BQ6ibfRIIBUqVzGmpa88sJ6mnXyDJfoG6+IvGig4qZa3Xt0KR+FdV7PjGOCylEOkcDy/dd6dXTeGIHoFnOKsckk0g1kaItgshugZCqGXZAKQ6aQILurwTE1A+cRzZruXuQS7anDCMuZh7xR0PSk7rQz9Omk/BaFRek+KK22ZJDiHSXYtw3aZQ6EiFVy6nmihl9kPUTwJvXtX6iE4k1qxmosFs3M1r4aQN/xZjBvTnQ4D6RwpTWbpso5UBpflC43A0AKWlS7YKpS94TpSsOpDBYyZxrURIBUymxcYOgBmtHwkdm7pO46sjDSyJ5QO3hedQxvea0nf0tisU1Q== 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=MAZWbLIeUbFoBdMlu2IMCSDX9/fRsmULM3BGG5sk8Ek=; b=Te3cerHYGns1WumV5pD4vH/KS2uTfF3AB+NChkn0dINDQ89fuTJt07+XRJmCn/xeJGT/EYXTlyXjVN5hFZYySkKytJTJRlQa54WZ4FDZiFKa4/ZyrBuAjCin5vIC7DMakW/+wN5zVDjxF3kGHLUZuLGAJk5YzzxVfuRtgZq+7D8+mvQswIKb3CMqwIQ/VWQb+s6tY0klb4Ie9J64QsYtpRWW44dm8Ob4qlVLNIWfK9GsloOi9alY5LBxedbLCZNIN8dY9CYHLccvr6Kjxyvyd+/puoMljC8sUiKcAym2m3D5OLlxcQ5ZalKasiENGNxPUyj2fosAgfro/G3gGiMrXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from DM6PR12MB3324.namprd12.prod.outlook.com (20.178.31.154) by DM6PR12MB4075.namprd12.prod.outlook.com (10.141.187.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15; Tue, 17 Dec 2019 20:15:33 +0000 Received: from DM6PR12MB3324.namprd12.prod.outlook.com ([fe80::d59b:7923:689f:bdc0]) by DM6PR12MB3324.namprd12.prod.outlook.com ([fe80::d59b:7923:689f:bdc0%6]) with mapi id 15.20.2538.019; Tue, 17 Dec 2019 20:15:33 +0000 From: "Ashish Singhal" 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-devel] [PATCH] Support skipping automatic BM enumeration Thread-Topic: [edk2-devel] [PATCH] Support skipping automatic BM enumeration Thread-Index: AQHVjtTHCLhtaIcUyUSCzPyxqDHpbqd0il+AgAddNoCAAAtAEIAAG3QAgAAAwxCAAAUjgIAAA/WwgAALDQCAAD03AIAAdMEAgAAMtNuAAB2BAIAAX7wwgAAH34CAABRhAIAACWCAgADZk4CAAMcwAIAALqiAgAAAuACAAAVNAIAArpsAgAF/VICABSEYAIAAEOcAgAAAlACAAsvrAIAAfLcAgAD6EoCAKRqigIABIPoAgAHTKoCACANBkw== Date: Tue, 17 Dec 2019 20:15:33 +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: msip_labels: MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Enabled=True; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_SiteId=43083d15-7273-40c1-b7db-39efd9ccc17a; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Owner=jbrasen@nvidia.com; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_SetDate=2019-11-14T17:04:03.1235930Z; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Name=Unrestricted; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Application=Microsoft Azure Information Protection; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_ActionId=02410ade-7f8d-45dd-9af8-01fc8e761cf7; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Extended_MSFT_Method=Automatic; authentication-results: spf=none (sender IP is ) smtp.mailfrom=ashishsingha@nvidia.com; x-originating-ip: [216.228.112.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc4ad5a8-b4a4-479b-bc5c-08d7832ddef8 x-ms-traffictypediagnostic: DM6PR12MB4075:|DM6PR12MB4075: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(136003)(39860400002)(346002)(396003)(366004)(199004)(50084003)(189003)(51914003)(51444003)(26005)(316002)(4326008)(6506007)(53546011)(86362001)(19627235002)(110136005)(55016002)(5660300002)(966005)(66946007)(19627405001)(7696005)(81166006)(81156014)(45080400002)(76116006)(76236002)(186003)(8676002)(9686003)(71200400001)(8936002)(2906002)(54906003)(52536014)(66556008)(64756008)(66446008)(30864003)(66476007)(478600001)(33656002)(559001)(579004);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR12MB4075;H:DM6PR12MB3324.namprd12.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: nvidia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4+CIDA642DdACHWG8xAUkVvoi8VDeiEHV9NN+v1zeGJj7+4fTnXvGUHy6xuh7whaBUCJMl3on0eXPYzass8TMwT7/FlVf8JCJJlBg2oorlKsX7E19T5xq1rFnVAb3JXwHDdR8N2Z/wL4qBcYaKPk/IsQ77HDhRsFFPoEiz7li9O450d+KXT5pLqp7iSAZL01h0SHAnBvgOToHVTfOW8cwvA3MWjFiu/zjtaOVdWhkhs0IyXj4ofhYupfETZOpzJk4wpp6KzgYuoGRpHFdrygf5vCg82R/YhYs32DqAzi1dMDFxauG2Ql5oJ05aSmE0gKKEmfS6hy5jHIJJZVVAY8P03r+nwghMCJQFNrmeJ5QJf6pg/p+I7bJQC2SaTeyQAm5GUAFKi9gIwhzqnvcqx0cySUinxpOHe+jRp+SEtZ9oyGDbK7LsAN6XeeIsZg5aIXjdyC1jSQ/VDBBjYPCZOsrDG2PET4qKS+pDZWs9WzG4D2vlBcbR1oMNN7KdU2EWjOL78pMGHk27a5K5blf8wYhYNp3d7PGLIM90hb08OJmJw5zPWvB3wKLJ/F59yWRKyam3DgICMcl3evrljjXnWbKg== MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fc4ad5a8-b4a4-479b-bc5c-08d7832ddef8 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2019 20:15:33.2845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nLjpJuf82QNN7R6Qg0uoaGGE6ihhoEsYkpUs4gU7C3D96FirpxTrzEJYbtYmyPXnarZm0gs92LayZk1E7n6P2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4075 Return-Path: ashishsingha@nvidia.com X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1576613727; bh=MAZWbLIeUbFoBdMlu2IMCSDX9/fRsmULM3BGG5sk8Ek=; h=X-PGP-Universal:ARC-Seal:ARC-Message-Signature: ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator:msip_labels: authentication-results:x-originating-ip:x-ms-publictraffictype: x-ms-office365-filtering-correlation-id:x-ms-traffictypediagnostic: x-ms-exchange-transport-forked:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf: x-ms-exchange-senderadcheck:x-microsoft-antispam: x-microsoft-antispam-message-info:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg: Content-Language:Content-Type; b=X8Hz/h93JHinuunu1fBwOacXEUyP6Kvlz1GCepf6xcQF77aAlhiVaW2bhjtB6wSbX geNSCDW/GFby6/4TETP8pC9FxKPUc8XJaGSf/jxJ00yEjQgsbzvQ6o5ngNWdw9gSK6 rYIBrckm217hv5My7WFrqpHRzkGPFkqzDO4EFStLSEza+Zidn2uzjvwRTPUeOpS/OA fP0SFCKI4bgILyDdillinnuwW73SE2vFZOVAibE4O4XTomMgFMgnjgrRhpzIyOVh7v 6yAmuMw3jhrz3NKnn6ItITQyf6rsn1/RtvSBm9yYo+IBgB2Ste3zjO9gNNydG9ztdz g5oDURS69TkuA== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_DM6PR12MB3324853F20F6622347F78142BA500DM6PR12MB3324namp_" --_000_DM6PR12MB3324853F20F6622347F78142BA500DM6PR12MB3324namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have submitted a patch based on 2.b as suggested by Ray. I am open to mak= ing changes in the structure of the protocol functions as well as the verba= l 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=92s try to resolve it in mails. Firstly, let me rephase the problem and your proposed solutions here (subj= ective + verb + objective). Sunny=92s input is also included. Hope Mike K a= nd 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=92t cause Boot#### created. It=92s a need of platform custom= ization. **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 =93Boot Manager=94 page and =93Boo= t Maintenance Manager=94 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 =96 Define new PCD and event group if PCD is set true then signal event = instead of calling EfiBootManagerRefreshAllBootOption in UiApp 2 =96 Add new function to boot manager library and replace call to EfiBoot= ManagerRefreshAllBootOption in UiApp (need to coordinate rollout with updat= es to all platform. 3 =96 Add new protocol with new function, if supported call this otherwise= call EfiBootManagerRefreshAllBootOption as is done now 4 =96 For 2/3 use generic function so we don=92t need new APIs for future= expansion 5 =96 Update EfiBootManagerRefreshAllBootOption to call platform specific = function. 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=92s a good topic that we could discuss in the open design meeti= ng. 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 system, unless (perhaps) PlatformBootManagerLib specifically thinks otherwise. Of course, then we arrive (again) at the problem that a call in UefiBootManagerLib, 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 Thanks, Laszlo > 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, Jia= n J >; Wu, Hao A >; Gao, Zhichao >; Kinney, Michael D > > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > 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: devel@edk2.groups.io> >> On Behalf Of Jeff Brasen > Sent: Thursday, November 7, 2019 3:02 PM > To: Ni, Ray >>; afish@apple.com > Cc: devel@edk2.groups.io>; Ashish Singhal >>; Laszlo Ersek >>; Wang, = Jian J >>; Wu, Hao A >>; Gao, Zhichao >>; Kinney, M= ichael D >> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > The issue is there are some auto created options we do not want on our p= latform. > Get Outlook for Android > > ________________________________ > From: Ni, Ray >> > Sent: Wednesday, November 6, 2019 11:59:31 PM > To: Jeff Brasen >>; afish@apple.com >> > Cc: devel@edk2.groups.io> >= >; Ashish Singhal >>; Laszlo E= rsek >>; Wang, Jian J >>; Wu, Hao A >>; Gao, Zhichao >>; Kinney, Michael D >> > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > > 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 >> > Sent: Thursday, November 7, 2019 12:13 PM > To: afish@apple.com; Ni, Ray >> > Cc: devel@edk2.groups.io>; Ashish Singhal >>; Laszlo Ersek >>; Wang, = Jian J >>; Wu, Hao A >>; Gao, Zhichao >>; Kinney, M= ichael D >> > Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > > > 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 >> > Sent: Wednesday, November 6, 2019 9:20 AM > To: Ni, Ray >> > Cc: devel@edk2.groups.io>; Jeff Brasen >>; Ashish Singhal >>; Las= zlo Ersek >>; Wang, Jian J >>; Wu, Hao A >>; Gao, Zhichao >>; Mike Kinney >> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > > > 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 happen.= So it's not expected EfiBootManagerRefresh...() be > called in every 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 >> > Sent: Wednesday, November 6, 2019 10:47 AM > To: devel@edk2.groups.io>; jbrasen@nvidia.com > Cc: Ashish Singhal >>; Lasz= lo Ersek >>; Ni, Ray >>; Wang, Jian J= >>; Wu, Hao A >>; Gao, Zhichao >>; Kinney, Michael= D >> > Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerat= ion > > > > > > > > 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 fo= llows > > > > 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 B= mBoot.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 s= upporting > > SimpleFileSystem Protocol, but not s= upporting 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 Be= havior > > > > 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. > > ________________________________ > > > --_000_DM6PR12MB3324853F20F6622347F78142BA500DM6PR12MB3324namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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 <jbra= sen@nvidia.com>
Sent: Thursday, December 12, 2019 10:52 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <deve= l@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@apple.c= om <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.groups.= io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J &l= t;jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhi= chao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@= intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration
 
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 lo= nger valid platform created boot options

Thanks,

Jeff


From: Ni, Ray <ray.ni= @intel.com>
Sent: Wednesday, December 11, 2019 7:00 AM
To: Jeff Brasen <jbrasen@nvidia.com>; devel@edk2.groups.io &l= t;devel@edk2.groups.io>; Laszlo Ersek <lersek@redhat.com>; afish@a= pple.com <afish@apple.com>; discuss@edk2.groups.io <discuss@edk2.g= roups.io>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J &l= t;jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhi= chao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@= intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration
 
External email: U= se caution opening links or attachments

Jeff,

Tom from AMD booked the meeting for SEV disc= ussion months ago. I am afraid there is no time for this discussion.

Let=92s try to resolve it in mails.

 

Firstly, let me rephase the problem and your= proposed solutions here (subjective + verb + objective). Sunny=92s= 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 PlatformBootManagerLib to PlatformBootManager protoc= ol. Protocol with Revision field helps to reduce the impact to old platform= s with new APIs added.

 

**Problem:

       &n= bsp;       Platform requires certain BlockIo/= SimpleFileSystem/LoadFile instances don=92t cause Boot#### created. It=92s = a need of platform customization.

 

**Details:

       &n= bsp;       Boot#### for BlockIo/SimpleFileSys= tem/LoadFile are created by API EfiBootMangerRefreshAllBootOptions(). There= are 2 places that call this API:

  1. Platform Boot M= anager calls the API (usually in the full configuration boot path)
  2. UiApp calls the API = when entering =93Boot Manager=94 page and =93Boot Maintenance Manager=94 pa= ge.

 

Platform can chan= ge 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
    1. Define a new PCD and a new event= group.

If PCD is TRUE, = UiApp signals the event. Event callback creates the Boot####. Otherwise, Ef= iBootManagerRefreshAllBootOptions() is called.

    1. Add a new PlatformBootManagerLib= API (implemented by platform).

UiApp calls the = new API instead of EfiBootManagerRefreshAllBootOption. (need to coordinate = rollout with updates to all platforms).

    1. Add a new protocol (implemented = by platform).

UiApp calls the = new protocol if it exists otherwise calls EfiBootManagerRefreshAllBootOptio= n.

 

  1. Update EfiBootManagerRefreshAllB= ootOptions()
    1. Add a new library class (impleme= nted by platform).

EfiBootManagerRe= freshAllBootOption() calls the new library class.

    1. Add a new Pla= tformBootManager protocol (implemented by platform).

EfiBootManag= erRefreshAllBootOption() calls the new protocol if it exists.

 

Thanks,

Ray

 

From= : Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo = Ersek <lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J &l= t;jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhi= chao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@= intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

C= an we discuss this at the design meeting this week (12/12)?

&= nbsp;

Thanks,

Jeff


From:= Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray <
ray.ni@i= ntel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek &l= t;lersek@redhat.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <
ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

Yes, I think that would be good.

 

Summarizing everything in this thread

 

Problem: Platform needs to customize the boot = options, this can be done for normal boot but the UiApp calls EfiBootManagerRefreshAllBoot= Option in a couple places.

=  

= Potential solutions:

= 1 =96 Define new PCD and event group if PCD is set true then signal event i= nstead of calling EfiBootManagerRefreshAllBootOption in UiApp

= 2 =96 Add new function to boot manager library and replace call to EfiBootM= anagerRefreshAllBootOption in UiApp (need to coordinate rollout with update= s to all platform.

= 3 =96 Add new protocol with new function, if supported call this otherwise = call EfiBootManagerRefreshAllBootOption as is done now

= 4 =96 For 2/3 use  generic function so we don=92t need new APIs for fu= ture expansion

= 5 =96 Update EfiBootManagerRefreshAllBootOption to call platform specific f= unction.

=  

= Thanks,
Jeff

 

 

From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com= >; Laszlo Ersek <lersek@redh= at.com>; afish@apple.com
Cc: Ashish Singhal <a= shishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>= ;; Kinney, Michael D <mich= ael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

Jeff,

I think it=92s a good topic that we could disc= uss in the open design meeting.

Are you ok to present the problem you have and= discuss the potential solutions in that meeting?

https://github.com/tianocore/tianocore.g= ithub.io/wiki/Design-Meeting

 

Thanks,

Ray

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen
Sent: Thursday, November 14, 2019 2:43 AM
To: Ni, Ray <ray.ni@intel.co= m>; devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; afish@apple.com
Cc: Ashish Singhal <a= shishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>= ;; Kinney, Michael D <mich= ael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

= Thinking about this more I think we could do this with a PCD and a new grou= p event without having to define any new function interfaces.

=  

= We could change UiApp and BootManagerMenuApp (and any others that are relev= ant) from

=  

= EfiBootManagerRefreshAllBootOption ();

=  

= to 

=  

= if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

=   EFI_EVENT Event;

=   gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGui= d, &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 an= d create a group event and do what it needs to do there.

=  

Thanks,

Jeff


From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Monday, November 11, 2019 5:00 PM
To: Ni, Ray <
ray.ni@i= ntel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek &l= t;lersek@redhat.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <
ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

= I am not sure a PCD would work (unless I am missing something) We do want t= o 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 <ray.ni@intel.com>
Sent: Monday, November 11, 2019 4:58 PM
To:
devel@edk2.group= s.io <devel@edk2.groups.io>; Jeff= Brasen <jbrasen@nvidia.com= >; Laszlo Ersek <lersek@redha= t.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <
ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

Jeff,

If adding a PCD to control UiApp can meet th= e real needs, I prefer to do in that way instead of adding new APIs to Plat= formBootManagerLib.

 

Thanks,

Ray

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen
Sent: Tuesday, November 12, 2019 6:58 AM
To: Laszlo Ersek <lersek@re= dhat.com>; Ni, Ray <ray.ni@in= tel.com>; devel@edk2.groups.io; afish@apple.com
Cc: Ashish Singhal <a= shishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>= ;; Kinney, Michael D <mich= ael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

Thanks,

Jeff


From:<= /b> Laszlo Ersek <lersek@redhat.com>
Sent: Friday, November 8, 2019 9:37 AM
To: Jeff Brasen <
jb= rasen@nvidia.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <
ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

 

On 11/07/19 1= 8: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 in= tended to do a full enumeration of the system and there may be platform spe= cifics to how that occurs.

Fully agreed -- entering UiApp should expose everything bootable in the system, unless (perhaps) PlatformBootManagerLib specifically thinks
otherwise.

Of course, then we arrive (again) at the problem that a call in
UefiBootManagerLib, 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:

  ht= tps://bugzilla.tianocore.org/show_bug.cgi?id=3D982

Thanks,
Laszlo

> From: Ni, Ray <ray.ni@intel.co= m>
> Sent: Thursday, November 7, 2019 12:21 AM
> To: devel@edk2.groups.io;= Jeff Brasen <jbrasen@nvidia.com>; afish@apple.com
> Cc: Ashish Singhal <ash= ishsingha@nvidia.com>; Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao= , Zhichao <zhichao.gao@intel.co= m>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
> I treat the issue in this way:
>
>   1.  Platform Boot Manager library does a good job. I= t 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<mailto:devel@edk2.groups.io> <devel@edk= 2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
> Sent: Thursday, November 7, 2019 3:02 PM
> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; afish@app= le.com<mailto:afish@apple.com>=
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ashish Si= nghal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>= ;>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Ji= an J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
> The issue is there are some auto created options we do not want on ou= r platform.
> Get Outlook for Android<https://= aka.ms/ghei36>
>
> ________________________________
> From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Sent: Wednesday, November 6, 2019 11:59:31 PM
> To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>= ;; afish@apple.com<mailto:afish@apple= .com> <afish@apple.com<mailto:afish@apple.com>>
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.= groups.io<mailto:devel@edk2.groups.io>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com&g= t;>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com&g= t;>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:m= ichael.d.kinney@intel.com>>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
> Jeff,
>
> RefreshAllBootOption() only modifies/creates the auto-created boot op= tions. For the boot options created by platform boot manager library, they = stay with no one touches. And all auto-created boot options are appended in= the end of boot option list (through BootOrder).
>
>
>
> From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>&= gt;
> Sent: Thursday, November 7, 2019 12:13 PM
> To: afish@apple.com<mailto:afis= h@apple.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>=
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ashish Si= nghal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>= ;>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Ji= an J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
> As the suggestions below made sense, we updated our platform boot man= ager library to behave in this manner and for normal boots everything works= well. However the UiApp and boot maintenance applications in EDK2 also cal= l 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 th= at allows for override of the behavior of BmEnumerateBootOptions? For examp= le, either a function or protocol that takes the same parameters as this fu= nction and only if it returns NULL then we continue to the default enumeration code.  Or a function call ins= erted at the end that would modify the load option array after the system d= oes the standard enumeration.
>
>
>
> -Jeff
>
>
>
> From: afish@apple.com<mailto:af= ish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> Sent: Wednesday, November 6, 2019 9:20 AM
> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Bras= en <jb= rasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia= .com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com&g= t;>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com&g= t;>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com&g= t;>; Mike Kinney <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
> 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 gu= idance on how to customize the BDS.
>
>
>
> Thanks,
>
>
>
> Andrew Fish
>
>
>
> On Nov 5, 2019, at 9:20 PM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.co= m>> wrote:
>
>
>
> Andrew,
>
> I agree with your opinion.
>
> It's expected that Platform Boot Manager lib calls EfiBootManagerRefr= eshAllBootOption() only in full configuration boot path.
>
> The full configuration boot path is chosen when hardware changes happ= en. So it's not expected EfiBootManagerRefresh...() be
> called in every boot.
>
> So you could:
>
>   1.  Delete the auto-created option pointing to LoadF= ile instance
>   2.  Create your own one with customized description.=
>
>
>
>
>
> From: afish@apple.com<mailto:af= ish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> Sent: Wednesday, November 6, 2019 10:47 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; jbrasen@n= vidia.com<mailto:jbrasen@nvidia.co= m>
> Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingh= a@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.c= om>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Wang, Jian J <= jia= n.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
>
>
>
>
> On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidia.com<mailto:jbras= en@nvidia.com>> wrote:
>
>
>
> Wouldn't having a variable that we create and delete on every boot pu= t unnecessary 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 hi= dden/!active but still match for detection purposes so that it doesn't dele= te and recreate the modified variable each boot? That way all the logic on what to disable can still be in the = platform code and all the existing logic in the boot manager can stay basic= ally the same?
>
> What changes every boot that forces the variable to need to get modif= ied?
>
> I would assume the NOR driver is smart enough to not update a variabl= e that is not changing.
>
> The custom BDS could could only create the variable for this device i= f 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 vari= ables
>   2.  It will not be found, so create a new boot optio= n store it to a variable and update BootOrder
>   3.  Platform code runs creates the options for the b= oot option it wants and writes those to variable store
>   4.  Delete/disable the boot option in the variable s= tore
>
>
>
> 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 i= n BmBoot.c
>
>
>
> If you modify the variable to disable it with hidden/not active it wo= uld 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 = attributes (at least allow for differences in active and hidden) then the w= hen it refreshes every thing it would see the 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 t= hough the patch changed BmEnumerateBootOptions(), so that is going to chang= e 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 for 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 s= ure 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 Ma= nager 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 = variable that Windows installs? If it works kind of the same way then the a= nswer is to have the BDS platform specific code write the boot variable. >
>
>
>
>
> [1]
>
> /**
>
>   The function creates boot options for all possible bootab= le medias in the following order:
>
>   1. Removable BlockIo      &= nbsp;     - The boot option only points to the removabl= e media
>
>           &nbs= p;            &= nbsp;            dev= ice, like USB key, DVD, Floppy etc.
>
>   2. Fixed BlockIo       = ;         - The boot option only po= ints to a Fixed blockIo device,
>
>           &nbs= p;            &= nbsp;            lik= e HardDisk.
>
>   3. Non-BlockIo SimpleFileSystem - The boot option points = to a device supporting
>
>           &nbs= p;            &= nbsp;            Sim= pleFileSystem Protocol, but not supporting BlockIo
>
>           &nbs= p;            &= nbsp;            pro= tocol.
>
>   4. LoadFile       &nbs= p;             = - The boot option points to the media supporting
>
>           &nbs= p;            &= nbsp;            Loa= dFile protocol.
>
>   Reference: UEFI Spec chapter 3.3 Boot Option Variables De= fault Boot Behavior
>
>
>
>   The function won't delete the boot option not added by it= self.
>
> **/
>
> 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) a= nd may contain confidential information.  Any unauthorized review, use= , disclosure or distribution is prohibited.  If you are not the intend= ed recipient, please contact the sender by reply email and destroy all copies of the original message.
>
> ________________________________
>
> >

--_000_DM6PR12MB3324853F20F6622347F78142BA500DM6PR12MB3324namp_--