[Rust-VMM] RFC:

[Zach Reizner]

On Sat, Feb 9, 2019 at 9:11 PM Liu Jiang <liuj97 at gmail.com> wrote:

> On Feb 9, 2019, at 2:10 AM, Zach Reizner <zachr at google.com> wrote:
>
>
> On Fri, Feb 8, 2019 at 2:18 AM Liu Jiang <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 .
>> 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?
>
That seems like a good solution. As long as GuestAddress can be used with
GuestMemory methods automatically, independent of the compiled word size,
then this will be suitable.

> 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 from crosvm
>> 2) add address space abstraction for virtual machine
>> Thanks,
>> Gerry
>> _______________________________________________
>> Rust-vmm mailing list
>> Rust-vmm at lists.opendev.org
>> 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/20190211/320f3361/attachment-0001.html>