[Rust-VMM] RFC v2: propose to host memory-model crate under the rust-vm project

Liu, Jiang liuj97 at gmail.com
Sun Feb 10 06:00:22 UTC 2019

Hi all,
	I have posted the first version of memory-model crate under rust-vmm/memory-model, which breaks the repository inclusion process of the rust-vmm community. So I have created a personal GitHub repository (https://github.com/jiangliu/memory-model) for v2 and the rust-vmm/memory-model repository will be deleted soon. Sorry for the inconvenience!
	The main change from v1 to v2 is the introduction of the AddressSpace abstraction, which is used to present the physical address space of a virtual machine. An AddressSpace object contains guest memory(RAM) regions and MMIO regions for devices. There are two possible ways to make use of the memory-model crate:
	1) Use the GuestMemory to represent a virtual machine address space, as it’s used currently by the firecracker and crosvm project.
	2) Use the AddressSpace to represent a virtual machine address space, and build GuestMemory objects from the AddressSpace object on demand. So different permission and protection mechanisms may be applied to different regions in guest address space. For example we may protect guest kernel code region with advanced EPT permission flags. It may help to mitigate the security concerns mentioned on the last meeting.

	On the other hand, the memory-model crate needs to satisfy requirements from both crosvm and firecracker, and currently the most sensitive conflict is that crosvm uses u64 for memory related fields but firecracker uses usize instead. As the valid usage case Zack has mentioned:
	"On 64-bit arm devices, we usually run a 32-bit userspace with a 64-bit kernel. In this case, the machine word size (usize) that crosvm is compiled with (32-bit) isn't the same as the one the guest kernel, host kernel, hardware is using (64-bit). We used u64 to ensure that the size was always at least as big as needed. “
	So we can’t simply replace u64 with usize. With the introduction of the AddressSpace abstraction, the proposal to solve this conflict is:
	1) Use u64 for all fields related to virtual machine physical address space. Most fields of the AddressSpace and GuestAddress structure falls into this category.
	2) Use usize for all fields representing address/size in current process(VMM). Most fields of the MemoryMapping and GuestMemory structure falls into this category.
	If the proposal is the right way to go, I will posted a v3 with the proposed solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20190210/bc024c30/attachment-0001.html>

More information about the Rust-vmm mailing list