From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mx.groups.io with SMTP id smtpd.web12.3091.1573004072669912282 for ; Tue, 05 Nov 2019 17:34:33 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nvidia.com header.s=n1 header.b=Hq7y3oDE; spf=pass (domain: nvidia.com, ip: 203.18.50.4, mailfrom: jbrasen@nvidia.com) Received: from hkpgpgate102.nvidia.com (Not Verified[10.18.92.77]) by nat-hk.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 06 Nov 2019 09:34:30 +0800 Received: from HKMAIL101.nvidia.com ([10.18.16.10]) by hkpgpgate102.nvidia.com (PGP Universal service); Tue, 05 Nov 2019 17:34:30 -0800 X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Tue, 05 Nov 2019 17:34:30 -0800 Received: from HKMAIL102.nvidia.com (10.18.16.11) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 01:34:29 +0000 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.53) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 6 Nov 2019 01:34:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X15C/VneE0AZK49V0oiKjhF/IfYs1vCq9MJACxSZd4j4ZZz/e0fWdwR6Ggr/j9UGCCVmdrB6UDuft2jUEsLPY0YatiLXpd+4pq/xUWxraAmwR+y7jJE9zb2xWNeA876yhyIV+1fglgO1powgPKSA0bpNbHD7FG697W8YBR9prsSRtdLCjR95+xOYLF2ubNZ+ru5QIMWqDjo63qUSBeMBEB6wEdjtW4xne7elUY8nwBaYLWuVI7o4N393z+3gGRimcf01B6jG5W9WMj1kFYd0FUS/pv7w4M4D3MNGUY9tcZedH8CPyTOR6bhLEqWXXsE9iDelNgRKtLDWPKZ9AQNexA== 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=OyasOyfT+agHCvK2T1NAdqtddGlcTurUpP5iM5Pa4ik=; b=dyoqza32eQ+je9ZxXE8xScllITCG04ZAd4YRgquND25u12bvv8jwS6JrbSWIY0RK10VG8lCbjdrkkpZ7eHMMP+ZbgqJHWqVhEnbcJBPVOQkiXjughDKc+p316vKmJpcpxG2nBcTJwIQItr1Sb1xvcKjmLvqToJ6KMhl/zicmdlBP3CE3cZfqnj7fGQwjB/zWwCbDWjHgw6QPE1kHV2F7MnIww/AnwVMUwafQ+xzL0xa9gn8WmEPFOoeptJKDEukIcxrWAn6BOSH3I94BjdJ4JKaM0A+hmq0ztq+RitPwCWHfGV+AkGP1VNMtNYiKAok4bwKNR2wy7s5sCLU0wYEvVQ== 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 BYAPR12MB3462.namprd12.prod.outlook.com (20.178.196.208) by BYAPR12MB3109.namprd12.prod.outlook.com (20.178.54.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Wed, 6 Nov 2019 01:34:24 +0000 Received: from BYAPR12MB3462.namprd12.prod.outlook.com ([fe80::75d1:6f54:3d0:69d8]) by BYAPR12MB3462.namprd12.prod.outlook.com ([fe80::75d1:6f54:3d0:69d8%6]) with mapi id 15.20.2408.024; Wed, 6 Nov 2019 01:34:24 +0000 From: "Jeff Brasen" To: Ashish Singhal , Laszlo Ersek , Andrew Fish CC: "devel@edk2.groups.io" , "Ni, Ray" , "Wang, Jian J" , "Wu, Hao A" , "Gao, Zhichao" , Mike Kinney Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration Thread-Topic: [edk2-devel] [PATCH] Support skipping automatic BM enumeration Thread-Index: AQHVlD5/488eXaMRxUa5BaRrbDICz6d9WZjR Date: Wed, 6 Nov 2019 01:34:23 +0000 Message-ID: References: <1b91c052-f64c-1dca-98ff-a2777afd7f77@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C34F98A@SHSMSX104.ccr.corp.intel.com> <6766B443-E14A-4F57-984E-5A865FB22CC9@apple.com> <37D801DD-41E8-452E-9F24-ADF52BFDB676@apple.com> <72ce1d71-2a65-a6c0-1dd8-7628429c5a3c@redhat.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=ashishsingha@nvidia.com; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_SetDate=2019-11-06T01:07:01.5543599Z; 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=f0b9ea9f-c6aa-4d5d-89a4-056a9aacfcd7; MSIP_Label_6b558183-044c-4105-8d9c-cea02a2a3d86_Extended_MSFT_Method=Automatic; authentication-results: spf=none (sender IP is ) smtp.mailfrom=jbrasen@nvidia.com; x-originating-ip: [2601:281:8100:1241:68d9:273b:bef9:99f9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d7c7bf1-7e22-46f0-28d7-08d762597463 x-ms-traffictypediagnostic: BYAPR12MB3109:|BYAPR12MB3109: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(396003)(376002)(366004)(346002)(39860400002)(136003)(189003)(199004)(55016002)(81166006)(71200400001)(52536014)(91956017)(66446008)(66946007)(7696005)(99286004)(478600001)(14454004)(14444005)(6436002)(110136005)(105004)(2906002)(6246003)(9686003)(316002)(54906003)(54896002)(86362001)(486006)(11346002)(66556008)(64756008)(446003)(46003)(66476007)(6116002)(186003)(4326008)(81156014)(8936002)(8676002)(19627405001)(7736002)(74316002)(476003)(229853002)(5660300002)(33656002)(6506007)(102836004)(76176011)(71190400001)(25786009)(256004)(76116006);DIR:OUT;SFP:1101;SCL:1;SRVR:BYAPR12MB3109;H:BYAPR12MB3462.namprd12.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:3; 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: YzWjk+QP9teNvwnLKFQWIOBu/VV5tnyhP0jgQ7ekoJNerHZIgw2b1DZ023oihpV2FBq5lXEDjX7fBg9o1iRaCIg+wV6ZUwxCS5Pqpi90ZyywpvHAAex+YySsPrfIbAFT1eruhLU+zR9gUm2CCtne09cUkWl1eRp1xXgdYfJWGYASAdaBGd0vPMFbd4SMdyyC2ZScV1lVB4DUXsVwpd5YQYdLMMs9h5HHLOXHe9xgV1OM79nCLPPq65MTw/UBRUQi5kfu6rC03q3Lfce8DT9ItNMkgTCx2YIf6YWhil/1Sq50x3oi4FAOXxrR1XNciAt4I9olOgBRwtBgxLfBsnLlK7LSDH94EQ6FwaEt6uk2YVEE/ivinWpD6OOoCvjqGjiGn+Le9vcPEMQw0yS2n8vssit9pSnTX7uxclTNoEjhHg1fvEtIX/z/sqIljAXqjBtL MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d7c7bf1-7e22-46f0-28d7-08d762597463 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 01:34:23.9382 (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: cDTlecfXRhbkpyONk6kqLtrZ68IDHvpO3p/rtCraNq/kPWMROBqMA3itTx0Ck2H9c9HLtsdOPVJkEAMmMJJrDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3109 Return-Path: jbrasen@nvidia.com X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1573004070; bh=fmd6garyxlhMPJ+ra+whzqZ6I3vSYILdc0qK82ULD1w=; 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=Hq7y3oDEdZ1k0MPMAQv55oqYq7CYFKV1n6lFYfk9YJQd3iMvY3q42ebvDT72qhAa/ 6wpnhRHjMGlL1Uf0b3ydzr3fklyPtCRk/GvF0ZvU8zQB+auQWl9oOZ6NB7gA2vVXUX rmtgnVa7osR8v8f/ynNCOoIrXWOFvmG2DfKpA9bZt6GpC4MC0k06wNGLbrduTRi8C4 C21olr1l/ztMe9kvpyY7jwrYvJamRtl8Bpuba7pEHWYR/O/Zw2wD5ykAfAWOP0TGpg kAczzlIXSF94FZDQ71pJfpgtNFiOiqwkmJ4kuW6JVLWlT7SC8yNqu5QIC2qnLdH3Pe IHKQlU7KjMXvw== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BYAPR12MB346238204D93AE9FD588F0D6CB790BYAPR12MB3462namp_" --_000_BYAPR12MB346238204D93AE9FD588F0D6CB790BYAPR12MB3462namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wouldn't having a variable that we create and delete on every boot put un= necessary stress on the SPI-NOR that the variable store lives on? What about the alternative approach where we allow the platform code to m= odify the attributes of the auto created variable to disable it with hidd= en/!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 o= n what to disable can 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 modified?= I would assume the NOR driver is smart enough to not update a variable th= at is not changing. The custom BDS could could only create the variable for this device if it= =20does not exist. [JB] The current flow with no changes in the boot manager would be as fol= lows =20 1. Scan for instance of the boot option in the variables =20 2. It will not be found, so create a new boot option store it to a v= ariable and update BootOrder =20 3. Platform code runs creates the options for the boot option it wan= ts and writes those to variable store =20 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 Bm= Boot.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 t= hat is the same boot option. If however we modify EfiBootManagerFindLoadOption to not compare the attr= ibutes (at least allow for differences in active and hidden) then the whe= n it refreshes every thing it would see the match and not delete/create a= =20new variable in the store and thus we wouldn't have changes every boot= . Thanks, Andrew Fish Thanks, Jeff -------------------------------------------------------------------------= ---------- This email message is for the sole use of the intended recipient(s) and m= ay contain confidential information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please contact the= =20sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------------= ---------- --_000_BYAPR12MB346238204D93AE9FD588F0D6CB790BYAPR12MB3462namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Wouldn't having a var= iable that we create and delete on every boot put unnecessary stress on t= he SPI-NOR that the variable store lives on?
What about the alternative approach where we allow the platform code to m= odify the attributes of the auto created variable to disable it with hidd= en/!active but still match for detection purposes so that it doesn't dele= te and recreate the modified variable =20each boot? That way all the logic on what to disable can still be in t= he 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 modified?= =20

I would assume the NOR driver is smart enough to not update a variable th= at is not changing.

The custom BDS could could only create the variable for this device if it= =20does not exist.

[JB] The current flow with no changes in the boot manager would be as fol= lows

  1. Scan for instance of the boot o= ption in the variables
  2. It will not be found, so create a new boot option store it to a variab= le and update BootOrder
  3. Platform code runs creates the options for the boot option it wants a= nd 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 would delete that and create a new o= ne as well as the code wouldn't recognize that is the same boot opti= on.

If however we modify EfiB= ootManagerFindLoadOption to not compare the attributes (at least allow fo= r differences in active and hidden) then the when it refreshes every thin= g it would see the match and not delete/create =20a new variable in the store and thus we wouldn't have changes every bo= ot.


Thanks,

Andrew Fish

Thanks,

Jeff


This email message is for the sole use of the intended recipient(s) = and may=20 contain confidential information.  Any unauthorized review, use, dis= closure=20 or distribution is prohibited.  If you are not the intended recipien= t,=20 please contact the sender by reply email and destroy all copies of the or= iginal=20 message.
--_000_BYAPR12MB346238204D93AE9FD588F0D6CB790BYAPR12MB3462namp_--