On 15.09.20 16:50, Grant Likely wrote:
On 15/09/2020 15:36, Heinrich Schuchardt wrote:
On 15.09.20 16:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com 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 msalter@redhat.com > 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.)
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.
The device-tree spec specifically says /mmemreserve/ serve to "define an entry for the devicetree blob’s memory reservation table."
I think this is just poorly worded. It would be better written as: "Memory reservations create entries in the devicetree blob’s memory reservation table."
Shouldn't the description of /memreserve/ refer to chapter 5.3 Memory Reservation Block? E.g.
"Memory reservations blocks (see chapter 5.3) are represented by lines of the form
/memreserve/ <address> <length>;
where <address> and <length> are 64-bit C-style integers, e.g.
/memreserve/ 0x10000000 0x0004000;"
Some requirements in chapter 5.3.1 sound similar to the description of the no-map sub-nodes of /reserved-memory, e.g. speculative access is prohibited:
"Any memory that is declared in a memory node and is accessed by the boot program or caused to be accessed by the boot program after client entry must be reserved. Examples of this type of access include (e.g., speculative memory reads through a non-guarded virtual page)."
So in line with our discussion concerning no-map EfiReservedMemoryType seems the most appropriate.
UEFI runtime drivers will be relocated by SetVirtualMemoryMap(). So the requirement in the above citation does not make much sense for memory that is EfiRuntimeServicesCode or EfiRuntimeServicesData. So those should not be modeled as /memreserve/. Just another issue with the DT spec.
Best regards
Heinrich
If I look at Linux code I find things like:
/* First 4KB has trampoline code for secondary cores. */ /memreserve/ 0x00000000 0x0001000;
/* firmware-provided startup stubs live here, where the secondary CPUs are * spinning. */ /memreserve/ 0x00000000 0x00001000;
/memreserve/ 0x10000000 0x0004000;*/ /* DSP RAM */
CPUs with a 'spin-table' enable-method "should spin outside of the kernel in a reserved area of memory (communicated to the kernel by a /memreserve/ region in the device tree".
This usage is not what I would have understood under the description in the devicetree spec. So the DT spec needs some clarification.
The problem with EfiRuntimeServicesData is that it can be moved anywhere in the virtual address space via SetVirtualAddressMap(). But do we know that the firmware can handle such a relocation?
Best regards
Heinrich
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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.