All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.