<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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 (<a href="https://github.com/jiangliu/memory-model" class="">https://github.com/jiangliu/memory-model</a>) for v2 and the rust-vmm/memory-model repository will be deleted soon. Sorry for the inconvenience!</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1) Use the GuestMemory to represent a virtual machine address space, as it’s used currently by the firecracker and crosvm project.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"<span style="font-family: arial, helvetica, sans-serif;" class="">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.</span> “</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>So we can’t simply replace u64 with usize. With the introduction of the AddressSpace abstraction, the proposal to solve this conflict is:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>If the proposal is the right way to go, I will posted a v3 with the proposed solution.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="">Thanks,</div><div class="">Gerry</div></body></html>