On 15.09.20 15:46, Leif Lindholm wrote: > On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote: >>>>>>>> +``/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 <[email protected]> >>> Date: Mon Sep 8 13:01:08 2014 -0400 >>> >>> efi/arm64: Fix fdt-related memory reservation >> >> Does that still make sense? I understand why it was done, but is it >> right to ignore those reservations outright? > > Yes. It is duplication of (sources of) information, forcing the > operating system to make runtime, or compile time, judgement calls of > which source(s) of information to respect. > >> As more U-Boot platforms >> turn on UEFI there could be unexpected consequences if the memory >> reservation block are silently ignored. I'm think that on the U-Boot >> platforms it is more likely that /memreserve/ is in use. > > That should also make it easy to intercept? Like putting a hook in the > DT update code that triggers build error/warning (or even update the > UEFI memory map) if someone is trying to memreserve with the UEFI > interface enabled. > >> It should be fine for /memreserve/ entries to get applied to the memmap >> during boot. Are there problems that I'm missing? > > Sure. They can be applied in the UEFI memory map. By u-boot, during > boot. The device-tree spec says they are used for device tree blobs. So I guess in the memory map returned by GetMemoryMap() they would have to be EfiACPIReclaimMemory like the area for the device-tree itself. We should define this in the EBBR.
In the device-tree spec an example showing the syntax of /memreserve/ nodes should be added. Best regards Heinrich > > / > Leif > >> g. >> 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
