On Tue, 15 Sep 2020 at 15:59, Grant Likely <grant.lik...@arm.com> wrote: > > > > On 15/09/2020 13:35, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 15:34, Grant Likely <grant.lik...@arm.com> wrote: > >> > >> > >> > >> On 15/09/2020 13:25, Ard Biesheuvel wrote: > >>> On Tue, 15 Sep 2020 at 15:22, Grant Likely <grant.lik...@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.g...@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 <msal...@redhat.com> Date: Mon Sep 8 13:01:08 2014 -0400 efi/arm64: Fix fdt-related memory reservation _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
