On Tue, 15 Sep 2020 at 15:34, Grant Likely <[email protected]> wrote: > > > > On 15/09/2020 13:25, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 15:22, Grant Likely <[email protected]> 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 <[email protected]> > >>> --- > >>> 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. > > > > >> ``/memory`` Examples > >> ~~~~~~~~~~~~~~~~~~~~ > >> @@ -314,6 +320,9 @@ is ignored. > >> 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 listed in the [UEFI]_ memory map > > > > not be listed > > > >> +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 +350,19 @@ nodes by adding a ``memory-region`` property to the > >> device node. > >> Usage legend: R=Required, O=Optional, OR=Optional but Recommended, > >> SD=See Definition > >> > >> ======================================================================================================= > >> > >> +``/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 them from memory 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 the type > >> +``EfiBootServicesData``. > >> + > >> ``/reserved-memory`` Example > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> 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>`_ > >> 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. > 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
