On 15/09/2020 15:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely <[email protected]> wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
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.
Not quite that simple. We're not talking about a clean cut-over from
non-UEFI to UEFI platforms, but rather a phased transition where with a
given DT, both the non-UEFI and UEFI boot paths need to work. e.g.,
U-Boot platforms where most people are using 'bootm', but want to start
encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file,
not the firmware itself.
The other issue is that the reserved memory region may not be about
firmware at all, but rather a memory layout that is wanted only by the
OS. Regardless of the approach we take here, those regions must be
respected.
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 not be an error to use /memreserve/. That creates a hard break
between UEFI and non-UEFI boot paths for /memreserve/. Updating the
memory map is fine, which leads to the question of what memory type
should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but
nothing protects it after ExitBootServices (would require leaving
/memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but
causes a change in behaviour. The memory will not appear in the linear
map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be
referenced by other nodes and explicitly tagged as reusable,
/memreserve/s are anonymous holes that are punched into the memory
map, so I don't see how a driver would be able to get a reference to
that memory (and gets its linear address if it _happens_ to be in
lowmem in the first place.)
In the typical use case, the driver doesn't directly use the
/memreserve/ entry, but rather knowledge of the hole is implicit; the
driver expects it to exist via some other mechanism. E.g., a property in
the device node. If /memreserve/ gets cleared out, the device node will
probably still try to use the region as if it had been reserved.
e.g.:
powerpc/boot/dts/akebono.dts: <0x1f00000 0x100000> is reserved, and then
used in the cpu-release-address property. This is a case where the
memory should still be in the linear map.
These are old use cases, and /memreserve/ is definitely deprecated in
favour of the /reserved-memory node, but it has users and I absolutely
do not want to create barriers to adopting the UEFI boot flow.
EfiRuntimeServicesData: Keeps the region protected and in the linear
map, but feels 'wrong'. An OS might decide to reclaim it anyway if it
doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map
it in the EFI page tables for access by the firmware itself at
runtime, so it is not an option here.
Ah, right. So that isn't right either.
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
