Output from discussion on EBBR issue: https://github.com/ARM-software/ebbr/issues/52 When using the UEFI ABI for booting, the DT memory map is ignored and instead UEFI GetMemoryMap() is used to find system memory. Also, regions described in /reserved-memory need to also be added to the UEFI memory map to protect against overlapping allocations. The patch adds language to cover both of those cases. Signed-off-by: Grant Likely <grant.likely@xxxxxxx> Cc: Heinrich Schuchardt <xypron.glpk@xxxxxx> Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> --- source/chapter3-devicenodes.rst | 26 +++++++++++++++++++++++--- source/chapter5-flattened-format.rst | 10 ++++++++++ source/references.rst | 4 ++++ 3 files changed, 37 insertions(+), 3 deletions(-) diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst index 3043b8a..a78a742 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. ``/memory`` Examples ~~~~~~~~~~~~~~~~~~~~ @@ -308,12 +314,12 @@ is ignored. Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition ======================================================================================================= -.. note:: All other standard properties (section - :ref:`sect-standard-properties`) are allowed but are optional. - The ``no-map`` and ``reusable`` properties are mutually exclusive and both must not be used together in the same node. +Dynamic reserved memory regions must not be listed in the [UEFI]_ memory map +because they are allocated by the OS after exiting firmware boot services. + Linux implementation notes: - If a ``linux,cma-default`` property is present, then Linux will use the @@ -341,6 +347,20 @@ nodes by adding a ``memory-region`` property to the device node. Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition ======================================================================================================= +.. _sect-reserved-memory-uefi: + +``/reserved-memory`` and UEFI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +When booting via [UEFI]_, static ``/reserved-memory`` regions must +also be listed in the system memory map obtained via the GetMemoryMap() +UEFI boot time service as defined in [UEFI]_ § 7.2. +The reserved memory regions need to be included in the UEFI memory map to +protect against allocations by UEFI applications. + +Reserved regions with the ``no-map`` property must be listed in the memory +map with type ``EfiReservedMemoryType``. +All other reserved regions must be listed with type ``EfiBootServicesData``. + ``/reserved-memory`` Example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/chapter5-flattened-format.rst b/source/chapter5-flattened-format.rst index 28e5bd4..b1e2b8b 100644 --- a/source/chapter5-flattened-format.rst +++ b/source/chapter5-flattened-format.rst @@ -234,6 +234,16 @@ reservation block as a whole, shall be located at an 8-byte aligned offset from the beginning of the devicetree blob (see section :ref:`sect-fdt-alignment`). +Memory Reservation Block and UEFI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As with the ``/reserved-memory`` node (section :ref:`sect-reserved-memory-uefi`), +when booting via [UEFI]_ entries in the Memory Reservation Block must also be +listed in the system memory map obtained via the GetMemoryMap() to protect against +allocations by UEFI applications. +The memory reservation block entries should be listed with type +``EfiBootServicesData``. + .. _sect-fdt-structure-block: Structure Block diff --git a/source/references.rst b/source/references.rst index 961fa20..8400e96 100644 --- a/source/references.rst +++ b/source/references.rst @@ -23,3 +23,7 @@ .. [EPAPR] *Power.org Standard for Embedded Power Architecture Platform Requirements*, power.org, 2011, https://www.power.org/documentation/power-org-standard-for-embedded-power-architecture-platform-requirements-epapr-v1-1-2/ + +.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A + <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, + February 2020, `UEFI Forum <http://www.uefi.org>`_ -- 2.20.1
