On 15/09/2020 14:59, Heinrich Schuchardt wrote:
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 <[email protected]>
Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservation
Does 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.
What bit is that? I see the text saying /memreserve/ adds an entry to
the blob's reservation table, but not that it is used for device tree blobs:
Memory reservations define an entry for the devicetree blob’s memory
reservation table. They have the form: e.g., /memreserve/ <address>
<length>; Where <address> and <length> are 64-bit C-style integers.
g.
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
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
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
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
