Conversation
Signed-off-by: Simon LUCIDO <simon.lucido@etu.umontpellier.fr>
An arbitrary value for the gap size has been chosen for now. Signed-off-by: Nils Ponsard <nilsponsard@gmail.com>
sameo
left a comment
There was a problem hiding this comment.
Please rebase the PR and remove the code formatting part and we'll get that merged.
| /// Size of the MMIO gap | ||
| const MMIO_GAP_SIZE: usize = 32 << 20; | ||
| /// Start of the MMIO gap | ||
| const MMIO_GAP_START: usize = MMIO_GAP_END - MMIO_GAP_SIZE; |
There was a problem hiding this comment.
FWIW, placing the MMIO gap under 32 bits is meant for supporting 32-bit architecture. The PCI memory hole (Which MMIO is taking advantage of) is a legacy burden that's carried over to support MMIO based devices on 32-bit CPUs.
It does not matter where you place it, and at the end of the 32-bit address space is fine. But you should know that this could be placed e.g. way further in the 64-bit address space, and leave RAM unfragmented.
There was a problem hiding this comment.
I don't think we need to support 32bit OSes ? Then we could instead use something like an allocator to place the MMIO devices after the guest's memory ?
| &mut self, | ||
| console_path: Option<String> | ||
| ) -> Result<()> { | ||
| pub fn configure_console(&mut self, console_path: Option<String>) -> Result<()> { |
| mem_size_mb: u32, | ||
| kernel_path: &str, | ||
| console: Option<String>, | ||
| ) -> Result<()> { |
|
replaced by #41 |
This PR adds a GAP at the end of 32-bit guest memory space to allocate MMIO devices.
The sizes is an arbitrary one, I didn't find any resource explaining which size to choose.
This PR fixes #34.