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

[Kristian Amlie]

On 02/09/2021 10:47, Ard Biesheuvel wrote:
> 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.

Thanks for checking! Then from my perspective you can consider this
issue resolved, and drop the patch.

-- 
Kristian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210902/ac36c596/attachment.sig>