[Rust-VMM] RFC:

Liu Jiang liuj97 at gmail.com
Sun Feb 10 05:11:45 UTC 2019


On Feb 9, 2019, at 2:10 AM, Zach Reizner <zachr at google.com <mailto:zachr at google.com>> wrote:
> 
> On Fri, Feb 8, 2019 at 2:18 AM Liu Jiang <liuj97 at gmail.com <mailto:liuj97 at gmail.com>> wrote:
> Hi all,
> 	As we have discussed during the meeting, I have created a memory-model repository under rust-vmm project and  posted the initial version at https://github.com/rust-vmm/memory-model <https://github.com/rust-vmm/memory-model> .
> The initial version tries to merge current code from the upstream crosvm and firecracker projects. And the most sensitive user visible change is changing from u64 to usize for memory related data fields.
> 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.
Hi Zach,
	Good point. So seems that the AddressSpace abstraction may help to solve this conflict. 
1) The AddressSpace represents virtual machine physical address space, which contains memory and MMIO regions. For simplicity, u64 will be used here for both 32-bits and 64-bits virtual machines. And GuestAddress should be u64 too.
2) The GuestMemory represents partial or full mapping of an AddressSpace into current process, so usize should be used here for memory related fields because they are used to save pointer/size in current process. And MemoryMapping should be usize too.
What’s your thoughts?
Thanks,
Gerry

> So please help to comment on whether this is the right way to go, and next step plan is:
> 1) import endian.rs <http://endian.rs/> from crosvm
> 2) add address space abstraction for virtual machine
> Thanks,
> Gerry
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org <mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm <http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20190210/eccd38d9/attachment.html>


More information about the Rust-vmm mailing list