On Tue, Sep 15, 2020 at 15:04:44 +0100, Grant Likely 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 reservationDoes 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.
Sure. They can keep their reservations in the device tree, but if a platform boots in UEFI mode, those reservations should be present in the UEFI memory map. Then linux can keep ignoring the DT reservations if booted through the EFI stub.
Or in other words, the master source of information is the .dts file, not the firmware itself.
This does not absolve u-boot from doing something sensible with what it's passed. This would not be the first thing u-boot would be runtime-processing the DT for.
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
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?).
Other options?
I'll defer to Ard on the actual selection.
But while care should take not to actively *break* Linux (esp wrt backwards compatibility), if we end up picking one over the other based only (or mainly) on Linux internals, we need to very clearly call that out in the spec.
Regards,
Leif