You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Semantically, this is where it belong - the memory is associated with
the virtual machine, not the virtual machine manager.
But independently of this, it is needed for borrowchk reasons: In the
future, each Vm will have two guest memory regions associated with it.
One for traditional guest memory, and another that is dedicated to I/O
(swiotlb region). Storing these two GuestMemoryMmap in `struct Vm`
allows for a function as follows:
fn io_memory(&self) -> &GuestMemoryMmap {
self.io_memory.as_ref()
.unwrap_or(&self.normal_memory)
}
Such a function cannot live in `struct Vmm`, as that would mean
borrowing the guest memory implies borrowing the entire `Vmm` object
(because rustc is not intelligent enough to project split borrows past
function calls - e.g. it doesn't know the references returned by
io_memory() really only borrows the io_memory and normal_memory fields,
not everything else.). However, this means it cannot be used in
callsites where such splitting of borrows is required (e.g. everywhere
where both a guest memory reference _and_ another Vmm field are passed
by reference to a function).
The `Option`-ness of the the guest_memory field is transitory.
Signed-off-by: Patrick Roy <[email protected]>
0 commit comments