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.
/
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
