vmm: extract receive_memory_regions from memory manager

The memory manager is guarded by a mutex, thus parallel accesses to it
and its members are not possible. But we have to execute this function
in parallel when we introduce multiple TCP connections. Otherwise, the
workers who receive the data and write it into guest memory will block
on each other, and thus slow down the migration.

Also rename the function to receive_memory_ranges for better naming
consistency.

On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
This commit is contained in:
Sebastian Eydam
2026-03-10 10:07:10 +01:00
committed by Bo Chen
parent e175ad64f2
commit ec42ee8004
3 changed files with 44 additions and 53 deletions
+38
View File
@@ -278,3 +278,41 @@ pub(crate) fn send_memory_ranges(
MigratableError::MigrateSend(anyhow!("Error during dirty memory migration")),
)
}
/// Receive memory contents for the given range table into guest memory.
pub(crate) fn receive_memory_ranges(
guest_memory: &GuestMemoryAtomic<GuestMemoryMmap>,
ranges: &MemoryRangeTable,
socket: &mut SocketStream,
) -> Result<(), MigratableError> {
let mem = guest_memory.memory();
for range in ranges.regions() {
let mut offset: u64 = 0;
// Here we are manually handling the retry in case we can't read the
// whole region at once because we can't use the implementation
// from vm-memory::GuestMemory of read_exact_from() as it is not
// following the correct behavior. For more info about this issue
// see: https://github.com/rust-vmm/vm-memory/issues/174
loop {
let bytes_read = mem
.read_volatile_from(
GuestAddress(range.gpa + offset),
socket,
(range.length - offset) as usize,
)
.map_err(|e| {
MigratableError::MigrateReceive(anyhow!(
"Error receiving memory from socket: {e}"
))
})?;
offset += bytes_read as u64;
if offset == range.length {
break;
}
}
}
Ok(())
}