Adopt the vm-memory crate from rust-vmm

[alexandruag]

Switch to using vm-memory instead of the memory_model Firecracker crate.

The next steps are merging this PR and going through the code one more time. After any potential changes are handled, we'll start experimenting with the actual integration.

[andreeaflorescu]

P.S. let's first publish a v0.1.0 of vm-memory on crates.io. I would rather not consume crates from GitHub. To publish it on crates.io there might be some other things that need to be addressed. Can you also open an issue on vm-memory with "publish to crates.io" so we can track the progress there?

[alexandruag]

Submitted rust-vmm/vm-memory#31.

[andreeaflorescu]

Copied my comment from the other issue for visibility:

This task is currently blocked by vm-memory not being published on crates.io.
Check the repository here: https://github.com/rust-vmm/vm-memory

@bonzini did the switch in his fork, but it's not ready for merging in Firecracker as per his comment.

[serban300]

CC: @firecracker-microvm/compute-capsule

Here is my strategy for adopting the rust-vmm/vm-memory crate:

In the first phase we will work in parallel on the following 2 directions:

1. Examining the rust-vmm/vm-memory crate. Here we have to check the following:

• the overall architecture is ok
• the crate is safe to use
• there are no methods that can generate undefined behavior
• all the unsafe blocks are absolutely necessary
• all the unsafe methods and traits are marked as unsafe

We will submit PRs to rust-vmm/vm-memory in order to fix problems as we discover them.

Owners: @alexandruag @serban300

2. Aligning firecracker/memory_model namings with rust-vmm/vm-memory without changing the functionality.

• We will change the GuestAddress inner value type from usize to u64.
• We will perform roughly the following steps for each of the memory model components (GuestAddress, DataInit/BytedValue, GuestMemory):
  • Check vm-memory naming and functionality in detail. Submit PR proposing changes if necessary.
  • Align firecracker/memory_model naming to rust-vmm/vm-memory naming.
  • Import the rust-vmm/vm-memory traits where applicable.
  • Add unit tests and documentation where necessary.
  • Submit a PR to rust-vmm/vm-memory with all the added unit tests and documentation.

It's true that direction 1. might affect the rust-vmm/vm-memory naming, but I don't expect it to have a significant impact here.

Owners: @serban300

In the second phase we will have to do the following:

• test firecracker with vm-memory on a local branch. Fix any problem that might occur.
• contribute with unit tests and documentation to rust-vmm/vm-memory where still needed
• work with the rust-vmm/vm-memory gatekeepers in order to publish the rust-vmm/vm-memory to crates.io
• make the switch to rust-vmm/vm-memory

Owners: @serban300

[serban300]

Work breakdown:

• Examine the rust-vmm/vm-memory crate

• [GuestAddress] use u64 instead of usize as inner type

• [memory_model] rename DataInit trait to ByteValued

• [GuestMemory] use rust-vmm/vm-memory method names

• make final adjustments for switching to rust-vmm/vm-memory

• contribute with unit tests and documentation to rust-vmm/vm-memory where still needed

• publish the rust-vmm/vm-memory to crates.io

[dianpopa]

Final switch to vm-memory was made in #1562.