opensbi
opensbi copied to clipboard
riscv-software-src
Reserved memory subnodes and UEFI
The removal of the "no-map" property on reserved memory nodes for memory protected by the PMP in commit 6966ad0abe7077b1b5c9342f588621426d997c38 causes U-Boot to generate an EFI memory map that marks such reserved memory regions as EfiBootServicesData. This is problematic since an OS can assume that such regions are available as soon as it makes the UEFI ExitBootServices() call.
This behaviour is required by the current draft of the device tree specification: https://github.com/devicetree-org/devicetree-specification/blob/master/source/chapter3-devicenodes.rst#reserved-memory-and-uefi
Not sure what the best way to solve this issue is. I suppose what's needed is a way to indicate "feel free to map this region, but don't try to use it". Then U-Boot could make sure these regions are marked as EfiReservedMemoryType. Until that is sorted out, I'd suggest adding the "no-map" proprty back.
Did you see any crash due to an access ? IIRC, the reserved regions setup by OpenSBI lie in the beginning of DRAM. As the kernel boot from 2M aligned address, this region is always marked as reserved region in EFI memory map. I have not tried the latest kernel but this was a snippet from an old EFI boot..
`` [ 0.000000] efi: Processing EFI memory map: [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x000000003fe00000 reserved size = 0x0000000000000010 [ 0.000000] memory.cnt = 0x1 [ 0.000000] memory[0x0] [0x0000000080200000-0x00000000bfffffff], 0x000000003fe00000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x1 [ 0.000000] reserved[0x0] [0x00000000bd671020-0x00000000bd67102f], 0x0000000000000010 bytes flags: 0x0 [ 0.000000] memblock_remove: [0x0000000000000000-0xfffffffffffffffe] reserve_regions+0x56/0x134 [ 0.000000] efi: 0x000080000000-0x00008003ffff [Reserved | | | | | | | | | |WB| | | ] [ 0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0x80040000 [ 0.000000] efi: 0x000080040000-0x0000801fffff [Conventional Memory| | | | | | | | | |WB| | | ] .... .... [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x000000003fe00000 reserved size = 0x0000000001105010 [ 0.000000] memory.cnt = 0xb ... ... [ 0.000000] reserved.cnt = 0x5 [ 0.000000] reserved[0x0] [0x0000000080000000-0x000000008003ffff], 0x0000000000040000 bytes flags: 0x0 [ 0.000000] reserved[0x1] [0x0000000080200000-0x00000000812befff], 0x00000000010bf000 bytes flags: 0x0 [ 0.000000] reserved[0x2] [0x0000000087f00000-0x0000000087f04fff], 0x0000000000005000 bytes flags: 0x0 [ 0.000000] reserved[0x3] [0x00000000bd46e000-0x00000000bd46efff], 0x0000000000001000 bytes flags: 0x0 [ 0.000000] reserved[0x4] [0x00000000bd671020-0x00000000bd67102f], 0x0000000000000010 bytes flags: 0x0
The first 2MB of memory section are always reserved. Let us know if you don't see that any your logs.
I'm not booting a Linux kernel. We're adding RISC-V support to OpenBSD and ran into an issue where the kernel would boot fine with the opensbi that was shipped with QEMU 5.1 (v0.7), but would hang very early on with and updated opensbi (v0.9).
Ahh I see. Ignore my comments about Linux kernel logs. The logs were collected before the following relevant uboot patch was merged.
4cbb293 ("efi_loader: consider no-map property of reserved memory")
This patch marked any reserved memory region without no-map property as boot data. I am following up with U-Boot EFI maintainers to figure out the best approach to fix it.
The current U-Boot upstream follows what is describe in the device-tree specification draft.
https://github.com/devicetree-org/devicetree-specification/blob/master/source/chapter3-devicenodes.rst: Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All other reserved regions must be listed with type EfiBootServicesData
https://github.com/devicetree-org/devicetree-specification/blob/master/source/chapter5-flattened-format.rst: The memory reservation block entries should be listed with type EfiReservedMemoryType.
Commit 073e5db6729c ("efi_loader: fix memory type for memory reservation block") by @kettenis fixed an issue with 4cbb2930bd8c ("efi_loader: consider no-map property of reserved memory").
@xypron Thanks for the clarification.
@kettenis Linux kernel does reserve all the reserved regions after efi memory regions are parsed. This happens in setup_bootmem after efi_init where efi memory regions are passed. I guess OpenBSD needs to do something similar as suggested by @xypron.