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

[Ard Biesheuvel]

On Thu, 2 Sept 2021 at 10:43, Kristian Amlie
<kristian.amlie at 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 at kernel.org>
> >> *Gesendet:* 31. August 2021 12:33:56 MESZ
> >> *An:* Heinrich Schuchardt <xypron.glpk at gmx.de>
> >> *CC:* Kristian Amlie <kristian.amlie at 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 at 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.

-- 
Ard.