aarch64: reserve low memory for UEFI device space - #4372
aarch64: reserve low memory for UEFI device space#4372Henry Li (henryli001) wants to merge 1 commit into
Conversation
Keep a 32 MiB firmware RAM window at GPA 0 and place the remaining UEFI RAM above 1 GiB. Reserve the intervening range for device space so VFIO mappings do not collide with the GIC MSI reserved IOVA region, while leaving direct Linux boot unchanged.
There was a problem hiding this comment.
🟡 Changes recommended
The aarch64 layout selection currently applies to all non-Linux load modes (not just UEFI), which is broader than the stated scope and may unintentionally change IGVM/other boot paths.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR adjusts the ARM64 guest RAM placement for UEFI boots to keep a small RAM window at GPA 0 while moving the remaining RAM above 1 GiB, leaving the intervening region unbacked so VFIO/iommufd device mappings don’t collide with the host MSI doorbell IOVA reservation.
Changes:
- Extend the memory layout resolver to support a split RAM layout via a new
low_ram_window_sizeinput (low RAM at GPA 0 + bulk RAM aboveram_start_address). - Update aarch64 VM initialization to request a 32 MiB low RAM window for UEFI while keeping Linux direct boot behavior (bulk RAM above 1 GiB).
- Add unit tests validating the new low RAM window behavior and that the MSI doorbell range remains unbacked.
File summaries
| File | Description |
|---|---|
| openvmm/openvmm_core/src/worker/memory_layout.rs | Adds low_ram_window_size support, reserves a low-memory device-space gap, allocates a small RAM prefix at GPA 0, and includes tests for the new layout. |
| openvmm/openvmm_core/src/worker/dispatch.rs | Sets ram_start_address/low_ram_window_size for aarch64 so UEFI gets a 32 MiB low RAM window while RAM otherwise starts at 1 GiB. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| let (ram_start_address, low_ram_window_size) = if cfg!(guest_arch = "aarch64") { | ||
| let start = 1024 * 1024 * 1024; | ||
| let low_window = if matches!(cfg.load_mode, LoadMode::Linux { .. }) { | ||
| 0 | ||
| } else { | ||
| 32 * 1024 * 1024 | ||
| }; | ||
| (start, low_window) | ||
| } else { | ||
| (0, 0) | ||
| }; |
| // GPA 0 to reach DXE, so retain a small low window and resume bulk RAM | ||
| // at 1 GiB, leaving the MSI doorbell range unbacked. | ||
| let (ram_start_address, low_ram_window_size) = if cfg!(guest_arch = "aarch64") { | ||
| let start = 1024 * 1024 * 1024; |
There was a problem hiding this comment.
I think we will want this to be configurable to support different allocation modes for UEFI. Or do we think it's reasonable to just do this everywhere on aarch64? John/others thoughts?
Summary
Give ARM64 UEFI guests a split low/high RAM layout that leaves the device-space region unbacked.
Changes
This is the memory-layout portion split out of #4344 for independent review.
Scope
The layout applies to ARM64 UEFI boots and leaves direct Linux boot unchanged.
Within UEFI it is unconditional: backing the device-space gap would reintroduce
the reserved-IOVA collision this layout prevents. A mode can still be added if
a concrete compatibility case requires the legacy contiguous layout.
Validation
OPENVMM_GUEST_TARGET=aarch64 cargo check -p openvmm_corecargo test -p openvmm_core --lib worker::memory_layout(25 passed)cargo xtask fmt --only-diffed