Skip to content

Instantly share code, notes, and snippets.

@andreeaflorescu
Last active January 24, 2019 09:36
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save andreeaflorescu/ce4190b442dea2c48a0d783019579ad3 to your computer and use it in GitHub Desktop.
Save andreeaflorescu/ce4190b442dea2c48a0d783019579ad3 to your computer and use it in GitHub Desktop.
Firecracker and Crosvm Common Crates - WIP

Firecracker and Crosvm Common Crates

The purpose of this gist is to get a discussion started about what the Firecracker team can contribute to crosvm.

This comparison is based on the following commits:

This comparison only touches the common crates of Firecracker and crosvm.

Kernel-related crates

In Firecracker we unified the kernel_loader and kernel_cmdline crates in one crate with two modules:

  • loader - corresponds to kernel_loader in crosvm
  • cmdline - corresponds to kernel_cmdline in crosvm

Firecracker changes to cmdline

  • added derive clone to the Cmdline structure
  • in the constructor, we use the capacity to initialize the string as advertised by the doc string.

Firecracker changes to kernel loader:

  • Removed unnecessary defines from elf.rs. This file was originally generated with bindgen from linux “include/uapi/linux/elf.h” file.
  • Added an extra sanity check for e_entry, which is required to be < the high memory start.
  • The load_kernel function returns the entry address of the kernel.

Crosvm changes:

  • load_kernel function has a new parameter in the signature: kernel_start. The parameter is used for computing the guest memory offset.

The unit tests are also changed a bit.

Potential changes to contribute to crosvm

  • kernel_loader: e_entry sanity check
  • kernel_loader: stripped down version of the elf.rs file
  • kernel_cmdline: initialize the cmdline string with the capacity specified in the function signature.

Memory-related

In Firecracker we moved all the memory related utilities in the memory_model crate. Initially this crate was the same as the data_model crate from crosvm.

We moved the following files from sys_util to memory_model: guest_address.rs, guest_memory.rs, mmap.rs.

Firecracker changes:

guest_address.rs

  • The GuestAddress is represented as usize instead of u64.
  • Added more unit tests

guest_memory.rs

  • Added map and fold function for memory regions. This is a helper function for counting the guest dirty pages.
  • Added immutable version of the with_regions function.

mmap.rs

  • Use overflowing_add() to validate requested address range and avoid panicking at runtime.

Crosvm Changes:

guest_memory.rs

  • Function for getting the memory size (we should also do this instead of making the MemoryRegion a public structure).
  • Function for madvising an adress range
  • Implementation for Volatile Memory.

mmap.rs

  • When initializing the memory, use madvise MADV_DONTDUMP, which specifies that the memory regions should be excluded from a core dump.
  • split from_fd in 2 functions: from_fd and from_fd_offset.
  • function for removing memory region (using madvise).
  • volatile memory support.

Potential changes to contribute to crosvm

  • Overflow add in mmap.rs
  • Others?.

KVM-related crates

In Firecracker all generated files are in _gen crates. KVM bindings are generated from the kernel version 4.13. In Crosvm, the autogenerated files are in _sys crates. The implementation of the kvm wrappers seems to have divereged, so I am just going to highlight some things that might be useful to contribute back.

Potential changes to contribute to crosvm:

  • Added get_api_version
  • Updated check_extensionto return true for KVM_CHECK_EXTENSION >=1 as per KVM documentation (before it was == 1).
  • Others?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment