| commit | d4eaa4056f84b256ccd7684d9cf7e4363b9cf413 | [log] [tgz] |
|---|---|---|
| author | Dylan Reid <dgreid@chromium.org> | Mon May 15 17:37:47 2017 -0700 |
| committer | chrome-bot <chrome-bot@chromium.org> | Thu May 25 22:51:14 2017 -0700 |
| tree | 728fbb294cf5b603fe232c7e284c00ffdd9904ed | |
| parent | 37285dc09d8fe5988fb98dc20bf00fdda38b0843 [diff] |
sys_util: Add guest_memory Add a module for accessing guest memory. This module will replace all the slices that are used to access it currently as those slices aren't valid because the memory is volatile and a volatile slice doesn't exist in rust. Modify the existing users so they no longer depend on the deprecated slice access. Change-Id: Ic0e86dacf66f68bd88ed9cc197cb14e45ada891d Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/509919
This component, known as crosvm, runs untrusted operating systems along with virtualized devices. No actual hardware is emulated. This only runs VMs through the Linux's KVM interface. What makes crosvm unique is a focus on safety within the programming language and a sandbox around the virtual devices to protect the kernel from attack in case of an exploit in the devices.
The crosvm source code is organized into crates, each with their own unit tests. These crates are:
kvm-sys low-level (mostly) auto-generated structures and constants for using KVMkvm unsafe, low-level wrapper code for using kvm-syscrosvm the top-level binary front-end for using crosvmCurrently there is no front-end, so the best you can do is run cargo test in each crate.