EFI memory allocation
Hi Heinrich, Ilias,
I had a bit of a look at how memory is allocated in EFI.
I see that efi_memory_init() is called quite early in U-Boot. It sometimes allocates memory for a bounce buffer, placing it somewhere in memory. How do we know that that memory is free and not being used by U-Boot?
To answer my own question, it excludes U-Boot's malloc() region from the map, so that it cannot overwrite that.
But then, what if we use lmb and start loading images into memory. Won't that conflict with EFI?
I also see that efi_allocate_pages() is called to allocate memory in the EFI code. But this just grabs memory from 'anywhere'...it doesn't respect the U-Boot malloc region.
It seems to me that most of the memory allocation in EFI should be done using malloc(). Of course the boot services need to efi_allocate_pages(), etc., but I am not sure that the internal tables should be skipping malloc()?
What do you think?
Regards, Simon
Hi Simon
On Sun, 3 Dec 2023 at 19:44, Simon Glass sjg@chromium.org wrote:
Hi Heinrich, Ilias,
I had a bit of a look at how memory is allocated in EFI.
I see that efi_memory_init() is called quite early in U-Boot. It sometimes allocates memory for a bounce buffer, placing it somewhere in memory. How do we know that that memory is free and not being used by U-Boot?
To answer my own question, it excludes U-Boot's malloc() region from the map, so that it cannot overwrite that.
But then, what if we use lmb and start loading images into memory. Won't that conflict with EFI?
Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and we have a 'todo' in the efi subsystem for a few years now [0] Michal (+cc'ed) has also pinged me for similar issues in the past.
I also see that efi_allocate_pages() is called to allocate memory in the EFI code. But this just grabs memory from 'anywhere'...it doesn't respect the U-Boot malloc region.
It seems to me that most of the memory allocation in EFI should be done using malloc(). Of course the boot services need to efi_allocate_pages(), etc., but I am not sure that the internal tables should be skipping malloc()?
What do you think?
I think that LMB, EFI and the whole memory reservations is a bit of a mess. Tom and I discussed this a bit in the past but I'll start working on it. It needs fixing, but without looking at the code first, I can't provide any useful feedback
[0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2
Thanks /Ilias
Regards, Simon
Hi Ilias,
On Mon, 4 Dec 2023 at 05:05, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon
On Sun, 3 Dec 2023 at 19:44, Simon Glass sjg@chromium.org wrote:
Hi Heinrich, Ilias,
I had a bit of a look at how memory is allocated in EFI.
I see that efi_memory_init() is called quite early in U-Boot. It sometimes allocates memory for a bounce buffer, placing it somewhere in memory. How do we know that that memory is free and not being used by U-Boot?
To answer my own question, it excludes U-Boot's malloc() region from the map, so that it cannot overwrite that.
But then, what if we use lmb and start loading images into memory. Won't that conflict with EFI?
Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and
OK, that looks very odd to me.
we have a 'todo' in the efi subsystem for a few years now [0] Michal (+cc'ed) has also pinged me for similar issues in the past.
I also see that efi_allocate_pages() is called to allocate memory in the EFI code. But this just grabs memory from 'anywhere'...it doesn't respect the U-Boot malloc region.
It seems to me that most of the memory allocation in EFI should be done using malloc(). Of course the boot services need to efi_allocate_pages(), etc., but I am not sure that the internal tables should be skipping malloc()?
What do you think?
I think that LMB, EFI and the whole memory reservations is a bit of a mess. Tom and I discussed this a bit in the past but I'll start working on it. It needs fixing, but without looking at the code first, I can't provide any useful feedback
[0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2
OK I mad a comment there. We should figure out a design before going ahead.
Regards, Simon
participants (2)
-
Ilias Apalodimas -
Simon Glass