U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Vincent Stehlé" <vincent.stehle@arm.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Tom Rini <trini@konsulko.com>,
	Sughosh Ganu <sughosh.ganu@linaro.org>,
	AKASHI Takahiro <akashi.tkhro@gmail.com>,
	Eugene Uriev <eugeneuriev@gmail.com>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Masahisa Kojima <kojima.masahisa@socionext.com>,
	Richard Weinberger <richard@nod.at>,
	Sean Anderson <seanga2@gmail.com>
Subject: Re: [PATCH v3 0/3] efi: Start tidying up memory management
Date: Thu, 5 Sep 2024 09:46:55 +0200	[thread overview]
Message-ID: <Ztlh70H-G6eP0wOr@debian> (raw)
In-Reply-To: <20240901222259.456932-1-sjg@chromium.org>

On Sun, Sep 01, 2024 at 04:22:56PM -0600, Simon Glass wrote:
> We have been discussing the state of EFI memory management for some
> years so I thought it might be best to send a short series showing some
> of the issues we have talked about.
> 
> This one just deals with memory allocation. It provides a way to detect
> EFI 'page allocations' when U-Boot' malloc() should be used. It should
> help us to clean up this area of U-Boot.
> 
> It also updates EFI to use U-Boot memory allocation for the pool. Most
> functions use that anyway and it is much more efficient. It also avoids
> allocating things 'in space' in conflict with the loaded images.

Hi Simon,

Thank you for this series.

I did test it on top of v2024.10-rc4 with AArch64 simulators (FVP & Qemu), with
OS boots and ACS-IR, and I see no regression. Same with sandbox on x86 and the
python tests.

Best regards,
Vincent.

> 
> This series also includes a little patch to show more information in
> the index for the EFI pages.
> 
> Note that this series is independent from Sugosh's lmb series[1],
> although I believe it will point the way to simplifying some of the
> later patches in that series.
> 
> Overall, some issues which should be resolved are:
> - allocation inconsistency, e.g. efi_add_protocol() uses malloc() but
>   efi_dp_dup() does not (this series makes a start)
> - change efi_bl_init() to register events later, when the devices are
>   actually used
> - rather than efi_set_bootdev(), provide a bootstd way to take note of
>   the device images came from and allow EFI to query that when needed
> - EFI_LOADER_BOUNCE_BUFFER - can use U-Boot bounce buffers?
> 
> Minor questions on my mind:
> - is unaligned access useful? Is there a performance penalty?
> - API confusion about whether something is an address or a pointer
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=416441
> 
> Changes in v3:
> - Add new patch to drop the memset() from efi_alloc()
> - Drop patch to convert device_path allocation to use malloc()
> 
> Changes in v2:
> - Drop patch 'Show more information in efi index'
> - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()'
> - Add the word 'warning', use log_warning() and show the end address
> 
> Simon Glass (3):
>   efi: Drop the memset() from efi_alloc()
>   efi: Allow use of malloc() for the EFI pool
>   efi: Show the location of the bounce buffer
> 
>  common/dlmalloc.c            |   7 +++
>  include/efi_loader.h         |  29 ++++++++-
>  include/malloc.h             |   7 +++
>  lib/efi_loader/efi_bootbin.c |  11 ++++
>  lib/efi_loader/efi_memory.c  | 119 ++++++++++++++++++++++++-----------
>  5 files changed, 136 insertions(+), 37 deletions(-)
> 
> -- 
> 2.34.1
> 

  parent reply	other threads:[~2024-09-05  7:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-01 22:22 [PATCH v3 0/3] efi: Start tidying up memory management Simon Glass
2024-09-01 22:22 ` [PATCH v3 1/3] efi: Drop the memset() from efi_alloc() Simon Glass
2024-09-14  7:34   ` Heinrich Schuchardt
2024-09-19 14:13     ` Simon Glass
2024-09-23 12:15       ` Heinrich Schuchardt
2024-09-25 12:50         ` Simon Glass
2024-09-01 22:22 ` [PATCH v3 2/3] efi: Allow use of malloc() for the EFI pool Simon Glass
2024-09-06  6:22   ` Sughosh Ganu
2024-09-06 13:01     ` Simon Glass
2024-09-09  7:44       ` Sughosh Ganu
2024-09-10 18:44         ` Simon Glass
2024-09-11  6:49           ` Sughosh Ganu
2024-09-12  0:59             ` Simon Glass
2024-09-23 12:30               ` Heinrich Schuchardt
2024-09-25 12:48                 ` Simon Glass
2024-09-06  7:12   ` Ilias Apalodimas
2024-09-06 13:01     ` Simon Glass
2024-09-12  6:37       ` Ilias Apalodimas
2024-09-16 15:42         ` Simon Glass
2024-09-20 12:10           ` Ilias Apalodimas
2024-09-20 16:03             ` Simon Glass
2024-09-23 10:02               ` Ilias Apalodimas
2024-09-25 12:55                 ` Simon Glass
2024-09-01 22:22 ` [PATCH v3 3/3] efi: Show the location of the bounce buffer Simon Glass
2024-09-02 11:42   ` Heinrich Schuchardt
2024-09-10 18:41     ` Simon Glass
2024-09-05  7:46 ` Vincent Stehlé [this message]
2024-09-06  0:28   ` [PATCH v3 0/3] efi: Start tidying up memory management 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=Ztlh70H-G6eP0wOr@debian \
    --to=vincent.stehle@arm.com \
    --cc=akashi.tkhro@gmail.com \
    --cc=eugeneuriev@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kojima.masahisa@socionext.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=richard@nod.at \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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