arm64: added memory layout representation #991
Conversation
| pub fn arch_memory_regions(size: usize) -> Vec<(GuestAddress, usize)> { | ||
| vec![(GuestAddress(0), size)] | ||
| let dram_size = min(size, layout::DRAM_MEM_END); | ||
| vec![(GuestAddress(layout::DRAM_MEM_START), dram_size)] |
There was a problem hiding this comment.
Judging from the ASCII art above, it seems there are multiple gaps from DRAM_START to DRAM_END, and some of them are even "Hole or DRAM". Does this warrant having multiple memory regions, instead of just one big region from DRAM_START to DRAM_END? Can setting things up with a single region lead to issues because we or the guest accidentally think we can use some memory area that's actually a gap, reserved or some other non-DRAM type of zone?
There was a problem hiding this comment.
A reserved/gap space is a space that exists but reserved for some hidden component. Reserved space does not necessarily mean that it is not available. Let s say that the firmware will need 2 MiB of RAM and then mark them as reserved. Reserved regions were really introduced to tell you that someone stole something from your DRAM. One thing that we could worry about is if the kernel entry point that we are using supports starting a kernel that is loaded at > 16 GiB but we should not have this problem since we are placing the kernel at the start of the RAM.
The code follows the memory address mapping of a 64-bit guest. Signed-off-by: Diana Popa <[email protected]>
|
@aghecenco addressed suggestions. Let me know. |
The code follows the memory address mapping of a 64-bit guest.
Link to documentation can be found in the following diff.
Issue #, if available: #757
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.