From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: loongarch@lists.linux.dev, linux@armlinux.org.uk,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Huacai Chen <chenhuacai@loongson.cn>,
Xi Ruoyao <xry111@xry111.site>
Subject: [PATCH 05/12] efi: libstub: avoid efi_get_memory_map() for allocating the virt map
Date: Sun, 18 Sep 2022 23:35:37 +0200 [thread overview]
Message-ID: <20220918213544.2176249-6-ardb@kernel.org> (raw)
In-Reply-To: <20220918213544.2176249-1-ardb@kernel.org>
The virt map is a set of efi_memory_desc_t descriptors that are passed
to SetVirtualAddressMap() to inform the firmware about the desired
virtual mapping of the regions marked as EFI_MEMORY_RUNTIME. The only
reason we currently call the efi_get_memory_map() helper is that it
gives us an allocation that is guaranteed to be of sufficient size.
However, efi_get_memory_map() has grown some additional complexity over
the years, and today, we're actually better off calling the EFI boot
service directly with a zero size, which tells us how much memory should
be enough for the virt map.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
drivers/firmware/efi/libstub/efi-stub.c | 31 ++++++++++++++++++++
drivers/firmware/efi/libstub/efistub.h | 2 ++
drivers/firmware/efi/libstub/fdt.c | 27 +++++------------
3 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c
index 97eaa487fdfd..6d9ce2c89576 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -319,6 +319,35 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
return status;
}
+/*
+ * efi_allocate_virtmap() - create a pool allocation for the virtmap
+ *
+ * Create an allocation that is of sufficient size to hold all the memory
+ * descriptors that will be passed to SetVirtualAddressMap() to inform the
+ * firmware about the virtual mapping that will be used under the OS to call
+ * into the firmware.
+ */
+efi_status_t efi_alloc_virtmap(efi_memory_desc_t **virtmap,
+ unsigned long *desc_size, u32 *desc_ver)
+{
+ unsigned long size, mmap_key;
+ efi_status_t status;
+
+ /*
+ * Use the size of the current memory map as an upper bound for the
+ * size of the buffer we need to pass to SetVirtualAddressMap() to
+ * cover all EFI_MEMORY_RUNTIME regions.
+ */
+ size = 0;
+ status = efi_bs_call(get_memory_map, &size, NULL, &mmap_key, desc_size,
+ desc_ver);
+ if (status != EFI_BUFFER_TOO_SMALL)
+ return EFI_LOAD_ERROR;
+
+ return efi_bs_call(allocate_pool, EFI_LOADER_DATA, size,
+ (void **)virtmap);
+}
+
/*
* efi_get_virtmap() - create a virtual mapping for the EFI memory map
*
@@ -334,6 +363,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
efi_memory_desc_t *in, *out = runtime_map;
int l;
+ *count = 0;
+
for (l = 0; l < map_size; l += desc_size) {
u64 paddr, size;
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 02fb5f7c8eff..20705712deff 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -885,6 +885,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
void *get_fdt(unsigned long *fdt_size);
+efi_status_t efi_alloc_virtmap(efi_memory_desc_t **virtmap,
+ unsigned long *desc_size, u32 *desc_ver);
void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
unsigned long desc_size, efi_memory_desc_t *runtime_map,
int *count);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 804f542be3f2..ab59889c38f1 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -199,7 +199,7 @@ static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)
struct exit_boot_struct {
efi_memory_desc_t *runtime_map;
- int *runtime_entry_count;
+ int runtime_entry_count;
void *new_fdt_addr;
};
@@ -213,7 +213,7 @@ static efi_status_t exit_boot_func(struct efi_boot_memmap *map,
* entries so that we can pass it straight to SetVirtualAddressMap()
*/
efi_get_virtmap(*map->map, *map->map_size, *map->desc_size,
- p->runtime_map, p->runtime_entry_count);
+ p->runtime_map, &p->runtime_entry_count);
return update_fdt_memmap(p->new_fdt_addr, map);
}
@@ -246,26 +246,18 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
unsigned long map_size, desc_size, buff_size;
u32 desc_ver;
unsigned long mmap_key;
- efi_memory_desc_t *memory_map, *runtime_map;
+ efi_memory_desc_t *memory_map;
efi_status_t status;
- int runtime_entry_count;
struct efi_boot_memmap map;
struct exit_boot_struct priv;
- map.map = &runtime_map;
map.map_size = &map_size;
map.desc_size = &desc_size;
map.desc_ver = &desc_ver;
map.key_ptr = &mmap_key;
map.buff_size = &buff_size;
- /*
- * Get a copy of the current memory map that we will use to prepare
- * the input for SetVirtualAddressMap(). We don't have to worry about
- * subsequent allocations adding entries, since they could not affect
- * the number of EFI_MEMORY_RUNTIME regions.
- */
- status = efi_get_memory_map(&map);
+ status = efi_alloc_virtmap(&priv.runtime_map, &desc_size, &desc_ver);
if (status != EFI_SUCCESS) {
efi_err("Unable to retrieve UEFI memory map.\n");
return status;
@@ -289,10 +281,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
goto fail_free_new_fdt;
}
- runtime_entry_count = 0;
- priv.runtime_map = runtime_map;
- priv.runtime_entry_count = &runtime_entry_count;
- priv.new_fdt_addr = (void *)*new_fdt_addr;
+ priv.new_fdt_addr = (void *)*new_fdt_addr;
status = efi_exit_boot_services(handle, &map, &priv, exit_boot_func);
@@ -304,8 +293,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
/* Install the new virtual address map */
svam = efi_system_table->runtime->set_virtual_address_map;
- status = svam(runtime_entry_count * desc_size, desc_size,
- desc_ver, runtime_map);
+ status = svam(priv.runtime_entry_count * desc_size, desc_size,
+ desc_ver, priv.runtime_map);
/*
* We are beyond the point of no return here, so if the call to
@@ -337,7 +326,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle,
efi_free(MAX_FDT_SIZE, *new_fdt_addr);
fail:
- efi_system_table->boottime->free_pool(runtime_map);
+ efi_bs_call(free_pool, priv.runtime_map);
return EFI_LOAD_ERROR;
}
--
2.35.1
next prev parent reply other threads:[~2022-09-18 21:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 21:35 [PATCH 00/12] efi: disentangle the generic EFI stub from FDT Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 01/12] efi: libstub: drop pointless get_memory_map() call Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 02/12] efi/arm: libstub: move ARM specific code out of generic routines Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 03/12] efi: libstub: fix up the last remaining open coded boot service call Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 04/12] efi: libstub: fix type confusion for load_options_size Ard Biesheuvel
2022-09-18 21:35 ` Ard Biesheuvel [this message]
2022-09-18 21:35 ` [PATCH 06/12] efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 07/12] efi: libstub: unify initrd loading between architectures Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 08/12] efi: libstub: remove DT dependency from generic stub Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 09/12] efi: libstub: install boot-time memory map as config table Ard Biesheuvel
2022-09-20 10:40 ` Joey Gouly
2022-09-20 11:37 ` Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 10/12] efi: libstub: remove pointless goto kludge Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 11/12] efi/loongarch: libstub: remove dependency on flattened DT Ard Biesheuvel
2022-09-19 1:58 ` Huacai Chen
2022-09-19 5:15 ` Ard Biesheuvel
2022-09-19 6:06 ` Huacai Chen
2022-09-19 6:22 ` Ard Biesheuvel
2022-09-19 6:33 ` Ard Biesheuvel
2022-09-19 10:33 ` Huacai Chen
2022-09-19 10:37 ` Ard Biesheuvel
2022-09-19 10:47 ` Huacai Chen
2022-09-19 10:49 ` Ard Biesheuvel
2022-09-19 11:15 ` Huacai Chen
2022-09-19 11:21 ` Ard Biesheuvel
2022-09-19 11:57 ` Huacai Chen
2022-09-19 12:10 ` Ard Biesheuvel
2022-09-19 12:14 ` Huacai Chen
2022-09-19 12:27 ` Ard Biesheuvel
2022-09-19 14:25 ` Huacai Chen
2022-09-19 14:32 ` Ard Biesheuvel
2022-09-19 14:43 ` Huacai Chen
2022-09-19 14:44 ` Ard Biesheuvel
2022-09-19 15:08 ` Huacai Chen
2022-09-19 15:50 ` Ard Biesheuvel
2022-09-20 1:44 ` Huacai Chen
2022-09-20 8:04 ` Ard Biesheuvel
2022-09-20 13:12 ` Huacai Chen
2022-09-20 14:53 ` Ard Biesheuvel
2022-09-18 21:35 ` [PATCH 12/12] efi: loongarch: add support for DT hardware descriptions Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220918213544.2176249-6-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=chenhuacai@loongson.cn \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=loongarch@lists.linux.dev \
--cc=xry111@xry111.site \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox