Re: Fwd: Re: [PATCH] efi_loader: Omit memory with "no-map" when returning memory map.

2 Sep 2021

      On 02/09/2021 10:47, Ard Biesheuvel wrote:
...
On Thu, 2 Sept 2021 at 10:43, Kristian Amlie
kristian.amlie@northern.tech wrote:
...
On 31/08/2021 13:12, Kristian Amlie wrote:
...
On 31/08/2021 12:46, Heinrich Schuchardt wrote:
...

*Von:* Ard Biesheuvel ardb@kernel.org
*Gesendet:* 31. August 2021 12:33:56 MESZ
*An:* Heinrich Schuchardt xypron.glpk@gmx.de
*CC:* Kristian Amlie kristian.amlie@northern.tech
*Betreff:* Re: [PATCH] efi_loader: Omit memory with "no-map" when
returning memory map.
On Tue, 31 Aug 2021 at 08:41, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/27/21 9:55 AM, Kristian Amlie wrote:

You can use scripts/get_maintainer.pl to find the right addressees for
your patches.

    efi_reserve_memory() states that memory marked with "no-map"
    shall not
    be accessed by the UEFI payload. Make sure efi_get_memory_map()
    honors
    this.

Accessing memory and describing memory are two different things.
Describing reserved memory in the memory map is important, because it
helps us distinguish it from MMIO regions.
Ok, my mistake, I thought the kernel would deduce this separately
through the DTB.
...
    This helps the case when booting vexpress_ca9x4 under QEMU. Because
    the kernel wants to use an address in the lowest 128MiB of the
    range,
    but this range is reserved with "no-map", the kernel complains
    that it
    can not allocate the low memory it needs. In reality the actual
    usable
    memory starts much higher, which is reflected correctly in the
    memory
    map after this fix.

This is a u-boot patch right? (I cannot tell from the context, as
there are no mailing lists on cc)
It is u-boot's job to describe all the memory, no matter how it is
used. Even if the kernel itself may not use it as system memory, there
are cases where kernel infrastructure is used to map these regions:
for instance, the ACPI core may need to map a SystemMemory OpRegion,
and we need the EFI memory map to tell us whether to use memory or I/O
semantics.
As for the 128 MB issue: can you reproduce this with a recent kernel?
We made some changes recently to the EFI stub as well as the
decompressor code to prevent the decompressor code from relocating
itself to the base of DRAM, and to allow the decompressed kernel to
reside at any 2 MB aligned offset in memory.
I'll try this and get back to you!
The result have been a bit inconclusive. I *think* it works, but the
system later crashes because init is killed. Which may be a problem with
that kernel in general, I don't know. I would require more time to
figure out exactly what's causing it. The early boot and all the memory
initialization seems to work just fine though.
I have pasted the log below if you want to look at it, but to me the
error looks unrelated.
Agreed. systemd-init crashes for some reason, but this is highly
unlikely to be caused by the EFI memory map containing reserved memory
regions.
Thanks for checking! Then from my perspective you can consider this
issue resolved, and drop the patch.
-- 
Kristian