loader.efi: combine GetMemoryMap and ExitBootServices and retry on error

MFC r292338: UEFI: combine GetMemoryMap and ExitBootServices and retry on error

The EFI memory map may change before or during the first
ExitBootServices call. In that case ExitBootServices returns an error,
and GetMemoryMap and ExitBootServices must be retried.

Glue together calls to GetMemoryMap(), ExitBootServices() and storage of
(now up-to-date) MODINFOMD_EFI_MAP metadata within a single function.

That new function - bi_add_efi_data_and_exit() - uses space previously
allocated in bi_load_efi_data() to store the memory map (it will fail if
that space is too short). It handles re-calling GetMemoryMap() once to
update the map key if necessary. Finally, if ExitBootServices() is
successful, it stores the memory map and its header as MODINFOMD_EFI_MAP
metadata.

ExitBootServices() calls are now done earlier, from within arch-
independent bi_load() code.

MFC r292442: loader.efi: show EFI error number, not full status value

EFI return values set the high bit to indicate an error. The log
messages changed here are printed only in the case of an error,
so including the error bit is redundant. Also switch to decimal to
match the error definitions (in sys/boot/efi/include/efierr.h).

MFC r292515: loader.efi: refresh size in GetMemoryMap retry loop

If ExitBootServices fails due to a changed efi_mapkey then GetMemoryMap
must be called again. In this case it is also possible for the memory
map to grow, so repeat the initial GetMemoryMap call to fetch the new
size.

Also roll bi_add_efi_data_and_exit into bi_load_efi_data as there's no
need for it to be a separate function.

PR:		202455
Relnotes:	Yes
Sponsored by:	The FreeBSD Foundation

0 files changed, 0 insertions, 0 deletions