LoongArch architecture development
 help / color / mirror / Atom feed
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


  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