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. > ``/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. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
