On 15.09.20 15:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
>> +``/memory`` node and UEFI >> +~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +When booting via [UEFI]_, the system memory map is obtained via the >> +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ ยง 7.2, >> +and if present, the OS must ignore any ``/memory`` nodes. >> > > This should cover /memreserve/ entries as well.
What memory type should be used for /memreserve/? The memory reserve block isn't nearly as expressive, so we don't have details about how to use it. Be conservative and specify EfiReservedMemoryType?
Currently, we simply ignore memreserve's like we ignore the memory nodes as well.
Looks like in Linux the memory is reserved without the nomap behaviour (not removed). Unlike with /reserved-memory, EfiBootServicesData won't currently give us the behaviour we want if the kernel is currently ignoring the memory reserved block. (for /reserved-memory, the kernel 'finds' the reservations again during early boot, so the UEFI protections only need to extend to the ExitBootServices() call. With the memory reserved block, the kernel has no way to know if it should continue to respect those reservations after ExitBootServices if it isn't parsing the block.
Should the kernel still respect Memory Reserved block when booting via UEFI? At this point I'm inclined to say yes.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
The device-tree spec says they are used for device tree blobs. So I guess in the memory map returned by GetMemoryMap() they would have to be EfiACPIReclaimMemory like the area for the device-tree itself. We should define this in the EBBR.
In the device-tree spec an example showing the syntax of /memreserve/ nodes should be added.
Best regards
Heinrich
/ Leif
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture