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.458.1572976809427531566
 for <devel@edk2.groups.io>;
 Tue, 05 Nov 2019 10:00:10 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@nvidia.com header.s=n1 header.b=Kfyg5i4P;
 spf=pass (domain: nvidia.com, ip: 203.18.50.4, mailfrom: ashishsingha@nvidia.com)
Received: from hkpgpgate101.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
	id <B5dc1b8a70001>; Wed, 06 Nov 2019 02:00:07 +0800
Received: from HKMAIL104.nvidia.com ([10.18.16.13])
  by hkpgpgate101.nvidia.com (PGP Universal service);
  Tue, 05 Nov 2019 10:00:06 -0800
X-PGP-Universal: processed;
	by hkpgpgate101.nvidia.com on Tue, 05 Nov 2019 10:00:06 -0800
Received: from HKMAIL104.nvidia.com (10.18.16.13) by HKMAIL104.nvidia.com
 (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov
 2019 18:00:05 +0000
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.56) by
 HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id
 15.0.1473.3 via Frontend Transport; Tue, 5 Nov 2019 18:00:05 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KuNlpK7tt6mBtPssD4Lk7IzxaxDnOlT3lZctI3SKOdKaaWfHtTfVcf+iPUS0xsCbl9GtyHtorqJgXHBtmY+G8TjKOGZ/y4DCcwUK4hbns12JQw28+dfw4u2MjskNG7dzmqDAGZvD3x95vasMqeYGLJ1O1ttjPKKhTIcFzCEngQOkyGFg67pvSKL9xYAqKzmPPbCSz7XNQt+iJr3z8BnXY48V52vyNQpruMwDvylnth6i1vOvZxRw3V/Q2Qv7qfbIxTa/Vl4jAHNLSRvn2CmVGnNEF4q0s9O10R7Jnx1OIcXsMIjbCN0oGRhYZdvzFHJQYm+p3rhaaGsEYXnR+sByWQ==
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=pxvCN8EOrfunooqMD80bVrRDTrcVirgEqTaNQW5OPbU=;
 b=DrYO0NEBqjGILd3G2BArxwtGjyUZl5+ix0LmmDZrhiWjefQWq5c8RujiZKOxxnzapMAN050zja/jWBSJ8dKry0a1sw2rRLXxviGKTg+2MBStlCZ8BdnY4EatC2oxDlnOInkPoAdn6vL/ByVsqWhUGypY0ubA8JBv6iWTG0KzwOBe+6EL4pgKOTiDY/yyebfJQSNUG+dGhmuxYvOPPiTu27bCwdlnMXfcNU2f7QTNMIHs9R9DWPg1ym0bGGm9RUd6k3gLR/z/0GpBHfJGq0Hc8ZrF4hzC77XaLEuNFOfdtUN8PzQYiIkzbBajcqIKHfqaU8IrHBlmMjxldNlQ50pWNA==
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
 DM6PR12MB2906.namprd12.prod.outlook.com (20.179.71.212) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.2408.24; Tue, 5 Nov 2019 18:00:01 +0000
Received: from DM6PR12MB3324.namprd12.prod.outlook.com
 ([fe80::b53a:559d:9ca3:8ad1]) by DM6PR12MB3324.namprd12.prod.outlook.com
 ([fe80::b53a:559d:9ca3:8ad1%6]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019
 18:00:00 +0000
From: "Ashish Singhal" <ashishsingha@nvidia.com>
To: Andrew Fish <afish@apple.com>, Laszlo Ersek <lersek@redhat.com>
CC: "devel@edk2.groups.io" <devel@edk2.groups.io>, "Ni, Ray"
	<ray.ni@intel.com>, "Wang, Jian J" <jian.j.wang@intel.com>, "Wu, Hao A"
	<hao.a.wu@intel.com>, "Gao, Zhichao" <zhichao.gao@intel.com>, Mike Kinney
	<michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration
Thread-Topic: [edk2-devel] [PATCH] Support skipping automatic BM enumeration
Thread-Index: AQHVjtTHCLhtaIcUyUSCzPyxqDHpbqd0il+AgAddNoCAAAtAEIAAG3QAgAAAwxCAAAUjgIAAA/WwgAALDQCAAD03AIAAdMEAgAAMtNs=
Date: Tue, 5 Nov 2019 18:00:00 +0000
Message-ID: <DM6PR12MB3324C021FE6B4EEB8B3AFAB8BA7E0@DM6PR12MB3324.namprd12.prod.outlook.com>
References: <cover.1572406843.git.ashishsingha@nvidia.com>
 <1b91c052-f64c-1dca-98ff-a2777afd7f77@redhat.com>
 <734D49CCEBEEF84792F5B80ED585239D5C34F98A@SHSMSX104.ccr.corp.intel.com>
 <DM6PR12MB332406FB62323F3ADAA5ABCCBA7E0@DM6PR12MB3324.namprd12.prod.outlook.com>
 <F02935A4-473B-4AA8-A3BB-746FF766BFA2@apple.com>
 <DM6PR12MB3324CE666FB10EA7CB9F99D7BA7E0@DM6PR12MB3324.namprd12.prod.outlook.com>
 <6766B443-E14A-4F57-984E-5A865FB22CC9@apple.com>
 <DM6PR12MB3324D16C9DC312DB99F98420BA7E0@DM6PR12MB3324.namprd12.prod.outlook.com>
 <CE9489DD-4BF3-48D8-9A0F-49891F0782C2@apple.com>
 <aa11cd46-7051-aaa1-3320-52797d6d3fc8@redhat.com>,<37D801DD-41E8-452E-9F24-ADF52BFDB676@apple.com>
In-Reply-To: <37D801DD-41E8-452E-9F24-ADF52BFDB676@apple.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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: 74f42324-63b3-490d-1612-08d76219fa55
x-ms-traffictypediagnostic: DM6PR12MB2906:
x-microsoft-antispam-prvs: <DM6PR12MB2906929D2CC59D669B516A44BA7E0@DM6PR12MB2906.namprd12.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(366004)(376002)(199004)(189003)(446003)(54906003)(76176011)(66446008)(66476007)(66556008)(66946007)(54896002)(81166006)(110136005)(2906002)(7736002)(52536014)(229853002)(8676002)(19627405001)(6246003)(8936002)(6436002)(64756008)(76116006)(6116002)(33656002)(3846002)(316002)(55016002)(478600001)(7696005)(476003)(6506007)(53546011)(81156014)(99286004)(86362001)(5660300002)(74316002)(9686003)(11346002)(102836004)(14454004)(26005)(256004)(486006)(186003)(14444005)(25786009)(105004)(66066001)(71200400001)(91956017)(4326008)(71190400001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM6PR12MB2906;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: 3nRaJbgtR6dRCfYRThI8L06PW9rhCZysvdxzB1zv7Q1qjgmeenKuXwsgc90XzRto31bYUMEfxLihQ9sYLfJWCFcYkp2L3ngL/0opX9LVVJv2/eHXPwXry6iz/Pkllb3obooy4haQp8csTilgReF/SbIOIXHG8tDhdbNYTvZwjlgTSGIPthgvyx7MW3TFI6eiCpn83/4zCQUMipPKkXcAb8XpInV5YaxOlVJyU8Owu5gWbDb8UL66aO3xhoSEliOXChD8m+1IdV3gKA1+XTMcLsKpoBL4/u/3Y2oVSHP+sm3+LEiFXBRxAI2lhKjRw2fX6IKnCEoWjB+YxgnbkYiiVgZ2qlJ3Btwry7Cltn4eJvK6fnFGTaMyNUwwllY4yquQK2H/Bm8g4uxDn3sGPy7JQpdMwOSsIKEpYj46+bpoPYgbtTZdS2R9TLyoUnXUKiXV
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 74f42324-63b3-490d-1612-08d76219fa55
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 18:00:00.8629
 (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: E88qpc0n78kv+K5mtnMqxzcxDJDDiqIx4Fkm1JbPTB52Gqr4EBnwSI+m0N5+8WewkPcRQ7P9tybJslYuYnE0cA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2906
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=1572976808; bh=BxPDHIuX4hXBXVBmZ9fkg/sQcVvVGJ8GaYDXrkvSTWc=;
	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:
	 authentication-results:x-originating-ip:x-ms-publictraffictype:
	 x-ms-office365-filtering-correlation-id:x-ms-traffictypediagnostic:
	 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:x-ms-exchange-transport-forked:
	 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=Kfyg5i4P9q/FltS6FpZIiPNR/Xn+MpDbN6fAVUD0D3eshp/lF3xdYAEXeMcSxWtvf
	 0s+AGXtrq3n3EBqPdFE3EnYJdEAOEXUCPC+NU1D/3jaCdECwi2GymXlRBTuSoTpBCf
	 yuvBLKgTdZLPCpCnAd4v3o/MBut3Lbcu96rckE6NP+k2s496qi1YBRIAe/QTW8UMrk
	 suj+DSFImwXq9DwL45VdHEh9AIpuz/PPd3B7IiuOePWBAQHuqK1fCb/toIBTfuV6VG
	 eisLFinGyRNXPVy/DRp2HCnEBIMZ1ovYiImSxCfDz96YtWWOIW9fbvN0eXw7RT8021
	 +SluIq1Zu0mvg==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DM6PR12MB3324C021FE6B4EEB8B3AFAB8BA7E0DM6PR12MB3324namp_"

--_000_DM6PR12MB3324C021FE6B4EEB8B3AFAB8BA7E0DM6PR12MB3324namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Andrew/Laszlo,

Thank you for walking me through the steps that happen and what I can do =
in terms of modifying variables. I think I did not do a good job stating =
the exact issue I see when I try these options so I will try to explain i=
t here.

First of all, I do want the boot option to be created for the load file p=
rotocol I am installing, but I need specific optional data for my platfor=
m.

Right now, UefiBootManagerLib looks for all instances of Block IO, Simple=
=20FS and Load File protocol handles and creates a boot option for them w=
ith mBmAutoCreateBootOptionGuid being the optional data. This GUID as opt=
ional data is used to keep track of whether the boot option is an auto-cr=
eated one from the library or not. Because of this, however, there is no =
way right now for a platform to have its own optional data for the boot o=
ption. Now I agree that I can use the platform boot manager protocol to m=
odify the boot variable and give the custom optional data I need, but tha=
t would not stop UefiBootManagerLib from creating another boot option wit=
h mBmAutoCreateBootOptionGuid as the optional data on the next bootup whi=
ch I would have to delete every time in the platform boot manager driver.=
=20With the patch that I have proposed, UefiBootManagerLib would never cr=
eate a boot option automatically if the platform wants it not to do it an=
d it can be dealt with in the platform boot manager driver.

Alternatively, we can have platform boot manager driver change the attrib=
ute of such a boot option to be hidden and not active, and add a new boot=
=20option with the specific optional data we want. This would require cha=
nging EfiBootMangerFindLoadOption function to ignore differences in Attri=
butes as otherwise, the system will recreate a new option with the active=
=20attribute set and delete the hidden one.

Thanks
Ashish
________________________________
From: afish@apple.com <afish@apple.com> on behalf of Andrew Fish <afish@a=
pple.com>
Sent: Tuesday, November 5, 2019 9:52 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Ashish Singhal <ashishsi=
ngha@nvidia.com>; Ni, Ray <ray.ni@intel.com>; Wang, Jian J <jian.j.wang@i=
ntel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@inte=
l.com>; Mike Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumerati=
on



> On Nov 5, 2019, at 3:54 AM, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 11/05/19 07:15, Andrew Fish via Groups.Io wrote:
>
>> You could also edit any existing variables that point to your Load Fil=
e to make sure they follow the rules you care about?
>>
>> It is legal from an UEFI spec point of view for a platform to edit the=
=20nvram boot variables based on platform boot policy.
>
> Good point; for example OVMF and ArmVirtQemu* do this, with the help of=

> QemuBootOrderLib. In essence:
>
> - connect a particular set of devices ("ConnectDevicesFromQemu")
>  - if that fails, call EfiBootManagerConnectAll()
>
> - call EfiBootManagerRefreshAllBootOption()
>
> - register UEFI Shell boot option manually
>
> - filter and reorder boot options in a platform specific way
>  ("RemoveStaleFvFileOptions", "SetBootOrderFromQemu")
>
> All this happens in PlatformBootManagerAfterConsole().
>


The intent of the EFI Boot Variables was generally for the OS Installer t=
o write the nvram boot variable with the EFI_LOAD_OPTION (BootXXXX variab=
le name, XXXX is the UINT16 hex value in BootoOrder) info. The reasons be=
ing the EFI code may not know the path to the OS Loader, or the arguments=
=20that should be passed to the OS Loader.

I'd also point out EFI_LOAD_OPTION.Attributes has LOAD_OPTION_ACTIVE  and=
=20LOAD_OPTION_HIDDEN bits that give you more control of how the Boot Man=
ager/BDS will deal with the existing nvram boot option.

Thanks,

Andrew Fish


> Thanks,
> Laszlo
>


-------------------------------------------------------------------------=
----------
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_DM6PR12MB3324C021FE6B4EEB8B3AFAB8BA7E0DM6PR12MB3324namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-asci=
i">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-=
bottom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
Hello Andrew/Laszlo,</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
Thank you for walking me through the steps that happen and what I can do =
in terms of modifying variables. I think I did not do a good job stating =
the exact issue I see when I try these options so I will try to explain i=
t here.</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
First of all, I do want the boot option to be created for the load file p=
rotocol I am installing, but I need specific optional data for my platfor=
m.</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
Right now, UefiBootManagerLib looks for all instances of Block IO, Simple=
=20FS and Load File protocol handles and creates a boot option for them w=
ith&nbsp;mBmAutoCreateBootOptionGuid being the optional data. This GUID a=
s optional data is used to keep track of whether
=20the boot option is an auto-created one from the library or not. Becaus=
e of this, however, there is no way right now for a platform to have its =
own optional data for the boot option. Now I agree that I can use the pla=
tform boot manager protocol to modify the
=20boot variable and give the custom optional data I need, but that would=
=20not stop&nbsp;<span style=3D"font-family: Calibri, Arial, Helvetica, s=
ans-serif; background-color: rgb(255, 255, 255); display: inline !importa=
nt">UefiBootManagerLib from creating another boot
=20option with&nbsp;<span style=3D"font-family: Calibri, Arial, Helvetica=
, sans-serif; background-color: rgb(255, 255, 255); display: inline !impo=
rtant">mBmAutoCreateBootOptionGuid as the optional data on the next bootu=
p which I would have to delete every time in the
=20platform boot manager driver. With the patch that I have proposed,&nbs=
p;<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; back=
ground-color: rgb(255, 255, 255); display: inline !important">UefiBootMan=
agerLib would never create a boot option automatically
=20if the platform wants it not to do it and it can be dealt with in the =
platform boot manager driver.</span></span></span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; backgr=
ound-color: rgb(255, 255, 255); display: inline !important"><span style=3D=
"font-family: Calibri, Arial, Helvetica, sans-serif; background-color: rg=
b(255, 255, 255); display: inline !important"><span style=3D"font-family:=
=20Calibri, Arial, Helvetica, sans-serif; background-color: rgb(255, 255,=
=20255); display: inline !important"><br>
</span></span></span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; backgr=
ound-color: rgb(255, 255, 255); display: inline !important"><span style=3D=
"font-family: Calibri, Arial, Helvetica, sans-serif; background-color: rg=
b(255, 255, 255); display: inline !important"><span style=3D"font-family:=
=20Calibri, Arial, Helvetica, sans-serif; background-color: rgb(255, 255,=
=20255); display: inline !important">Alternatively,
=20we can have platform boot manager driver change the attribute of such =
a boot option to be hidden and not active, and add a new boot option with=
=20the specific optional data we want. This would require changing EfiBoo=
tMangerFindLoadOption function to ignore differences
=20in Attributes as otherwise, the system will recreate a new option with=
=20the active attribute set and delete the hidden one.</span></span></spa=
n></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; backgr=
ound-color: rgb(255, 255, 255); display: inline !important"><span style=3D=
"font-family: Calibri, Arial, Helvetica, sans-serif; background-color: rg=
b(255, 255, 255); display: inline !important"><span style=3D"font-family:=
=20Calibri, Arial, Helvetica, sans-serif; background-color: rgb(255, 255,=
=20255); display: inline !important"><br>
</span></span></span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; backgr=
ound-color: rgb(255, 255, 255); display: inline !important"><span style=3D=
"font-family: Calibri, Arial, Helvetica, sans-serif; background-color: rg=
b(255, 255, 255); display: inline !important"><span style=3D"font-family:=
=20Calibri, Arial, Helvetica, sans-serif; background-color: rgb(255, 255,=
=20255); display: inline !important">Thanks</span></span></span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-si=
ze: 12pt; color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; backgr=
ound-color: rgb(255, 255, 255); display: inline !important"><span style=3D=
"font-family: Calibri, Arial, Helvetica, sans-serif; background-color: rg=
b(255, 255, 255); display: inline !important"><span style=3D"font-family:=
=20Calibri, Arial, Helvetica, sans-serif; background-color: rgb(255, 255,=
=20255); display: inline !important">Ashish</span></span></span></div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
style=3D"font-size:11pt" color=3D"#000000"><b>From:</b> afish@apple.com &=
lt;afish@apple.com&gt; on behalf of Andrew Fish &lt;afish@apple.com&gt;<b=
r>
<b>Sent:</b> Tuesday, November 5, 2019 9:52 AM<br>
<b>To:</b> Laszlo Ersek &lt;lersek@redhat.com&gt;<br>
<b>Cc:</b> devel@edk2.groups.io &lt;devel@edk2.groups.io&gt;; Ashish Sing=
hal &lt;ashishsingha@nvidia.com&gt;; Ni, Ray &lt;ray.ni@intel.com&gt;; Wa=
ng, Jian J &lt;jian.j.wang@intel.com&gt;; Wu, Hao A &lt;hao.a.wu@intel.co=
m&gt;; Gao, Zhichao &lt;zhichao.gao@intel.com&gt;; Mike Kinney &lt;michae=
l.d.kinney@intel.com&gt;<br>
<b>Subject:</b> Re: [edk2-devel] [PATCH] Support skipping automatic BM en=
umeration</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11p=
t;">
<div class=3D"PlainText"><br>
<br>
&gt; On Nov 5, 2019, at 3:54 AM, Laszlo Ersek &lt;lersek@redhat.com&gt; w=
rote:<br>
&gt; <br>
&gt; On 11/05/19 07:15, Andrew Fish via Groups.Io wrote:<br>
&gt; <br>
&gt;&gt; You could also edit any existing variables that point to your Lo=
ad File to make sure they follow the rules you care about?
<br>
&gt;&gt; <br>
&gt;&gt; It is legal from an UEFI spec point of view for a platform to ed=
it the nvram boot variables based on platform boot policy.
<br>
&gt; <br>
&gt; Good point; for example OVMF and ArmVirtQemu* do this, with the help=
=20of<br>
&gt; QemuBootOrderLib. In essence:<br>
&gt; <br>
&gt; - connect a particular set of devices (&quot;ConnectDevicesFromQemu&=
quot;)<br>
&gt;&nbsp; - if that fails, call EfiBootManagerConnectAll()<br>
&gt; <br>
&gt; - call EfiBootManagerRefreshAllBootOption()<br>
&gt; <br>
&gt; - register UEFI Shell boot option manually<br>
&gt; <br>
&gt; - filter and reorder boot options in a platform specific way<br>
&gt;&nbsp; (&quot;RemoveStaleFvFileOptions&quot;, &quot;SetBootOrderFromQ=
emu&quot;)<br>
&gt; <br>
&gt; All this happens in PlatformBootManagerAfterConsole().<br>
&gt; <br>
<br>
<br>
The intent of the EFI Boot Variables was generally for the OS Installer t=
o write the nvram boot variable with the EFI_LOAD_OPTION (BootXXXX variab=
le name, XXXX is the UINT16 hex value in BootoOrder) info. The reasons be=
ing the EFI code may not know the path
=20to the OS Loader, or the arguments that should be passed to the OS Loa=
der. <br>
<br>
I'd also point out EFI_LOAD_OPTION.Attributes has LOAD_OPTION_ACTIVE&nbsp=
; and LOAD_OPTION_HIDDEN bits that give you more control of how the Boot =
Manager/BDS will deal with the existing nvram boot option.
<br>
<br>
Thanks,<br>
<br>
Andrew Fish<br>
<br>
<br>
&gt; Thanks,<br>
&gt; Laszlo<br>
&gt; <br>
<br>
</div>
</span></font></div>

<DIV>
<HR>
</DIV>
<DIV>This email message is for the sole use of the intended recipient(s) =
and may=20
contain confidential information.&nbsp; Any unauthorized review, use, dis=
closure=20
or distribution is prohibited.&nbsp; 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. </DIV>
<DIV>
<HR>
</DIV>
</body>
</html>

--_000_DM6PR12MB3324C021FE6B4EEB8B3AFAB8BA7E0DM6PR12MB3324namp_--