Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

["Ashish Singhal" <ashishsingha@nvidia.com>]

[-- Attachment #1: Type: text/plain, Size: 4384 bytes --]

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 it here.

First of all, I do want the boot option to be created for the load file protocol I am installing, but I need specific optional data for my platform.

Right now, UefiBootManagerLib looks for all instances of Block IO, Simple FS and Load File protocol handles and creates a boot option for them with mBmAutoCreateBootOptionGuid being the optional data. This GUID as optional data is used to keep track of whether the boot option is an auto-created 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 option. Now I agree that I can use the platform boot manager protocol to modify the boot variable and give the custom optional data I need, but that would not stop UefiBootManagerLib from creating another boot option with mBmAutoCreateBootOptionGuid as the optional data on the next bootup which I would have to delete every time in the platform boot manager driver. With the patch that I have proposed, UefiBootManagerLib would never create a boot option automatically if the platform wants it not to do it and it can be dealt with in the platform boot manager driver.

Alternatively, we 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 the specific optional data we want. This would require changing EfiBootMangerFindLoadOption function to ignore differences in Attributes as otherwise, the system will recreate a new option with the active attribute set and delete the hidden one.

Thanks
Ashish
________________________________
From: afish@apple.com <afish@apple.com> on behalf of Andrew Fish <afish@apple.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 <ashishsingha@nvidia.com>; 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



> 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 File 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 nvram 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 to write the nvram boot variable with the EFI_LOAD_OPTION (BootXXXX variable name, XXXX is the UINT16 hex value in BootoOrder) info. The reasons being the EFI code may not know the path to the OS Loader, or the arguments that should be passed to the OS Loader.

I'd also point out EFI_LOAD_OPTION.Attributes has LOAD_OPTION_ACTIVE  and LOAD_OPTION_HIDDEN bits that give you more control of how the Boot Manager/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 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.
-----------------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 9135 bytes --]