On 15/09/2020 17:00, Heinrich Schuchardt wrote:
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:
[...]>>>> 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;"
I like that language & layout. I've pulled it into the draft patch. Thanks!
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.
Okay. I'm convinced. I'll specify EfiReservedMemoryType for memreserve.
g.