public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Tom Rini <trini@konsulko.com>,
	Liviu Dudau <liviu.dudau@foss.arm.com>,
	Simon Glass <sjg@chromium.org>, Stefan Roese <sr@denx.de>,
	Patrick Delaunay <patrick.delaunay@foss.st.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Michal Simek <michal.simek@amd.com>,
	Patrice Chotard <patrice.chotard@foss.st.com>,
	Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc()
Date: Mon, 9 Jan 2023 09:18:34 +0200	[thread overview]
Message-ID: <Y7u/yoceToX7Lc0m@hades> (raw)
In-Reply-To: <20230105202536.190392-3-heinrich.schuchardt@canonical.com>

On Thu, Jan 05, 2023 at 09:25:35PM +0100, Heinrich Schuchardt wrote:
> Carve out code from efidebug command used to read the memory map.
> 
> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> ---
> v2:
> 	new patch
> ---
>  cmd/efidebug.c              | 18 ++++--------------
>  include/efi_loader.h        |  3 +++
>  lib/efi_loader/efi_memory.c | 34 ++++++++++++++++++++++++++++++++++
>  3 files changed, 41 insertions(+), 14 deletions(-)
> 
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 569003ae2e..e6959ede93 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -591,25 +591,15 @@ static void print_memory_attributes(u64 attributes)
>  static int do_efi_show_memmap(struct cmd_tbl *cmdtp, int flag,
>  			      int argc, char *const argv[])
>  {
> -	struct efi_mem_desc *memmap = NULL, *map;
> -	efi_uintn_t map_size = 0;
> +	struct efi_mem_desc *memmap, *map;
> +	efi_uintn_t map_size;
>  	const char *type;
>  	int i;
>  	efi_status_t ret;
>  
> -	ret = efi_get_memory_map(&map_size, memmap, NULL, NULL, NULL);
> -	if (ret == EFI_BUFFER_TOO_SMALL) {
> -		map_size += sizeof(struct efi_mem_desc); /* for my own */
> -		ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
> -					(void *)&memmap);
> -		if (ret != EFI_SUCCESS)
> -			return CMD_RET_FAILURE;
> -		ret = efi_get_memory_map(&map_size, memmap, NULL, NULL, NULL);
> -	}
> -	if (ret != EFI_SUCCESS) {
> -		efi_free_pool(memmap);
> +	ret = efi_get_memory_map_alloc(&map_size, &memmap);
> +	if (ret != EFI_SUCCESS)
>  		return CMD_RET_FAILURE;
> -	}
>  
>  	printf("Type             Start%.*s End%.*s Attributes\n",
>  	       EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0899e293e5..02d151b715 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -734,6 +734,9 @@ efi_status_t efi_allocate_pool(enum efi_memory_type pool_type,
>  			       efi_uintn_t size, void **buffer);
>  /* EFI pool memory free function. */
>  efi_status_t efi_free_pool(void *buffer);
> +/* Allocate and retrieve EFI memory map */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> +				      struct efi_mem_desc **memory_map);
>  /* Returns the EFI memory map */
>  efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
>  				struct efi_mem_desc *memory_map,
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 8d347f101f..32254d2433 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -736,6 +736,40 @@ efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
>  	return EFI_SUCCESS;
>  }
>  
> +/**
> + * efi_get_memory_map_alloc() - allocate map describing memory usage
> + *
> + * The caller is responsible for calling FreePool() if the call succeeds.
> + *
> + * @memory_map		buffer to which the memory map is written
> + * @map_size		size of the memory map
> + * Return:		status code
> + */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> +				      struct efi_mem_desc **memory_map)
> +{
> +	efi_status_t ret;
> +
> +	*memory_map = NULL;
> +	*map_size = 0;
> +	ret = efi_get_memory_map(map_size, *memory_map, NULL, NULL, NULL);

Although this is correct and efi_get_memory_map() will only return
EFI_BUFFER_TOO_SMALL, since we initialize the map_size to 0,  I don't know
if code analysis tools are smart enough to understand this.  Perhaps we
should initialize ret?


> +	if (ret == EFI_BUFFER_TOO_SMALL) {
> +		*map_size += sizeof(struct efi_mem_desc); /* for the map */
> +		ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, *map_size,
> +					(void **)memory_map);
> +		if (ret != EFI_SUCCESS)
> +			return ret;
> +		ret = efi_get_memory_map(map_size, *memory_map,
> +					 NULL, NULL, NULL);
> +		if (ret != EFI_SUCCESS) {
> +			efi_free_pool(*memory_map);
> +			*memory_map = NULL;
> +		}
> +	}
> +
> +	return ret;
> +}
> +
>  /**
>   * efi_add_conventional_memory_map() - add a RAM memory area to the map
>   *
> -- 
> 2.37.2
> 

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>


  parent reply	other threads:[~2023-01-09  7:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 20:25 [PATCH v2 0/3] efi_loader: consider EFI memory map Heinrich Schuchardt
2023-01-05 20:25 ` [PATCH v2 1/3] vexpress: adjust loadaddr Heinrich Schuchardt
2023-01-05 20:25 ` [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc() Heinrich Schuchardt
2023-01-06 23:22   ` Vagrant Cascadian
2023-01-09  7:18   ` Ilias Apalodimas [this message]
2023-01-09  8:06     ` Heinrich Schuchardt
2023-01-09 13:00       ` Ilias Apalodimas
2023-01-05 20:25 ` [PATCH v2 3/3] lmb: consider EFI memory map Heinrich Schuchardt
2023-01-06 23:22   ` Vagrant Cascadian
2023-01-09  7:19   ` Ilias Apalodimas
2023-01-09 20:11   ` Simon Glass
2023-01-09 20:20     ` Mark Kettenis
2023-01-09 20:31       ` Simon Glass
2023-01-09 20:53         ` Heinrich Schuchardt
2023-01-11  0:15           ` Simon Glass
2023-01-11  7:43             ` Heinrich Schuchardt
2023-01-11 13:59               ` Tom Rini
2023-01-11 16:48                 ` Simon Glass
2023-01-11 16:59                   ` Heinrich Schuchardt
2023-01-11 17:40                     ` Mark Kettenis
2023-01-11 17:50                       ` Heinrich Schuchardt
2023-01-11 17:55                     ` Simon Glass
2023-01-11 18:03                       ` Heinrich Schuchardt
2023-01-11 21:08                         ` Simon Glass
2023-01-11 22:59                           ` Mark Kettenis
2023-01-11 23:35                             ` Heinrich Schuchardt
2023-01-12  1:13                               ` Tom Rini
2023-01-11 23:36                             ` Simon Glass

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=Y7u/yoceToX7Lc0m@hades \
    --to=ilias.apalodimas@linaro.org \
    --cc=ashok.reddy.soma@xilinx.com \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=jh80.chung@samsung.com \
    --cc=liviu.dudau@foss.arm.com \
    --cc=michal.simek@amd.com \
    --cc=patrice.chotard@foss.st.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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