On Tue, 15 Sep 2020 at 15:59, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 13:35, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:34, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 13:25, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:22, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 09:33, Heinrich Schuchardt wrote:
Closes: #52
The no-map property of the /reserved-memory device tree nodes is used to signal that a memory region shall not be accessed by the operating system, even not via speculative access.
/reserved-memory nodes without the no-map property describe memory that have special usage by the operating system.
This difference has to be reflected in the memory map returned by GetMemoryMap().
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
source/chapter2-uefi.rst | 13 +++++++++++++ source/references.rst | 4 ++++ 2 files changed, 17 insertions(+)diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 74ef70e..f410c57 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.+In the device tree reserved memory in modelled as a /reserved-memory nodes +[RESMEM]_. The reserved-memory node MAY carry either the no-map or the resue +property. It MUST NOT carry both properties as this would be contradictary.
After having looked at reserved-memory.txt in the kernel and the devicetree spec, I think this should just go straight into dtspec or into the kernel tree. I drafted a couple patches yesterday that first imports /reserved-memory into dtspec, and then adds the UEFI annotations. Here's the current patch for the latter:
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst index 3043b8a..647e487 100644 --- a/source/chapter3-devicenodes.rst +++ b/source/chapter3-devicenodes.rst @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with VLE=0. .. note:: All other standard properties (section :ref:`sect-standard-properties`) are allowed but are optional.
+``/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 reservation