A Virtual Machine Monitor for modern Cloud workloads.
Go to file
Sebastien Boeuf 0ff074d2b8 vm-allocator: Fix potential allocation errors
There is one corner case which was not properly handled by the current
code from our AddressAllocator. If both the address start (from the
next range) and the requested region size are already aligned on the
same value as "alignment", when doing the substract of the requested
size + alignment, the returned address is already aligned. The problem
is that we might end up overlapping with an existing range since the
check between the available delta and the requested size does not take
into account a full extra alignment.

By substracting the requested size + alignment - 1 from the address
start of the next range, we ensure this kind of corner case would not
happen since the address won't be naturally aligned and after some
adjustment from the function align_address(), the correct start address
will be returned.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-07-25 11:45:38 +01:00
arch vm-allocator: Introduce an MMIO hole address allocator 2019-07-22 09:51:16 -07:00
arch_gen build: Run unit tests on the Jenkins server 2019-07-16 17:09:05 +02:00
devices devices: serial: Make the serial unit tests pass 2019-07-16 17:09:05 +02:00
docs docs: Add VFIO usage example 2019-07-24 07:17:03 -07:00
net_gen vendor: Move to the rust-vmm vmm-sys-util package 2019-06-04 17:51:52 +02:00
net_util net_util: Bump pnet dependency 2019-07-16 17:09:05 +02:00
pci pci: Fix end of address space check 2019-07-25 11:45:38 +01:00
qcow qcow: Add support for QCOW v2 header 2019-07-19 17:21:54 +02:00
resources tests: Add virtio-fs testing 2019-06-27 21:46:00 +02:00
scripts tests: Use custom kernel for all tests 2019-07-24 16:26:33 +02:00
src tests: Adjust down entropy expectation 2019-07-24 16:26:33 +02:00
test_data/cloud-init/openstack/latest tests: Add VFIO integration test 2019-07-24 11:55:08 +02:00
vfio vfio: Map MMIO regions into the guest 2019-07-24 11:55:08 +02:00
vfio-bindings vfio-bindings: Initial commit 2019-07-24 11:55:08 +02:00
vhost_rs vhost_rs: vhost_user: Update unit tests 2019-07-16 17:09:05 +02:00
virtio-bindings cloud-hypervisor: Add proper licensing 2019-05-09 15:44:17 +02:00
vm-allocator vm-allocator: Fix potential allocation errors 2019-07-25 11:45:38 +01:00
vm-virtio vm-virtio: Add virtio console device for single port operation 2019-07-22 23:08:56 +01:00
vmm vmm: Support direct device assignment 2019-07-24 11:55:08 +02:00
.gitignore gitignore: Don't track Cargo.lock files 2019-05-10 16:32:39 +02:00
.travis.yml build: Upload release binary on tag 2019-07-24 12:49:35 +01:00
Cargo.lock vmm: Support direct device assignment 2019-07-24 11:55:08 +02:00
Cargo.toml tests: Use incrementing IP and mac address for VMs 2019-07-18 18:01:18 +02:00
CODE_OF_CONDUCT.md cloud-hypervisor: Adopt the Contributor Covenant code of conduct 2019-05-12 23:15:30 +02:00
CONTRIBUTING.md main: refactored parameter parsing 2019-05-16 19:22:21 +01:00
CREDITS.md cloud-hypervisor: Add CREDITS 2019-05-12 23:15:30 +02:00
Jenkinsfile tests: Add VFIO integration test 2019-07-24 11:55:08 +02:00
LICENSE-APACHE cloud-hypervisor: Add proper licensing 2019-05-09 15:44:17 +02:00
LICENSE-BSD-3-Clause cloud-hypervisor: Add proper licensing 2019-05-09 15:44:17 +02:00
MAINTAINERS.md cloud-hypervisor: Add initial list of maintainers 2019-05-12 23:15:30 +02:00
README.md README: Fix kernel command line console argument 2019-07-24 07:16:48 -07:00

Build Status

  1. What is Cloud Hypervisor?
  2. Getting Started
  3. Status
  4. rust-vmm dependency
  5. Community
  6. Security

1. What is Cloud Hypervisor?

This project is an experiment and should not be used with production workloads.

Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) that runs on top of KVM. The project focuses on exclusively running modern, cloud workloads, on top of a limited set of hardware architectures and platforms. Cloud workloads refers to those that are usually run by customers inside a cloud provider. For our purposes this means modern Linux* distributions with most I/O handled by paravirtualised devices (i.e. virtio), no requirement for legacy devices and recent CPUs and KVM.

Cloud Hypervisor is implemented in Rust and is based on the rust-vmm crates.

Objectives

High Level

  • KVM and KVM only based
  • Minimal emulation
  • Low latency
  • Low memory footprint
  • Low complexity
  • High performance
  • Small attack surface
  • 64-bit support only
  • Build time configurable CPU, memory, PCI and NVDIMM hotplug
  • Machine to machine migration

Architectures

cloud-hypervisor only supports the x86-64 CPU architecture for now.

We're planning to add support for the AArch64 architecture in the future.

Guest OS

  • 64-bit Linux

Support for modern 64-bit Windows guest is being evaluated.

2. Getting Started

We create a folder to build and run cloud-hypervisor at $HOME/cloud-hypervisor

$ export CLOUDH=$HOME/cloud-hypervisor
$ mkdir $CLOUDH

Clone and build

First you need to clone and build the cloud-hypervisor repo:

$ pushd $CLOUDH
$ git clone https://github.com/intel/cloud-hypervisor.git
$ cd cloud-hypervisor
$ cargo build --release

# We need to give the cloud-hypervisor binary the NET_ADMIN capabilities for it to set TAP interfaces up on the host.
$ sudo setcap cap_net_admin+ep ./target/release/cloud-hypervisor

$ popd

This will build a cloud-hypervisor binary under $CLOUDH/cloud-hypervisor/target/release/cloud-hypervisor.

Run

You can run a guest VM by either using an existing cloud image or booting into your own kernel and disk image.

Cloud image

cloud-hypervisor supports booting disk images containing all needed components to run cloud workloads, a.k.a. cloud images. To do that we rely on the Rust Hypervisor Firmware project to provide an ELF formatted KVM firmware for cloud-hypervisor to directly boot into.

We need to get the latest rust-hypervisor-firmware release and also a working cloud image. Here we will use a Clear Linux image:

$ pushd $CLOUDH
$ wget https://download.clearlinux.org/releases/29160/clear/clear-29160-kvm.img.xz
$ unxz clear-29160-kvm.img.xz
$ wget https://github.com/intel/rust-hypervisor-firmware/releases/download/0.1.0/hypervisor-fw
$ popd
$ pushd $CLOUDH
$ sudo setcap cap_net_admin+ep ./cloud-hypervisor/target/release/cloud-hypervisor
$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel ./hypervisor-fw \
	--disk ./clear-29160-kvm.img \
	--cpus 4 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask=" \
	--rng
$ popd

Multiple arguments can be given to the --disk parameter, currently the firmware requires that the bootable image is on the first disk.

Custom kernel and disk image

Building your kernel

cloud-hypervisor also supports direct kernel boot into a vmlinux ELF kernel image. You want to build such an image first:


# Clone a 5.0 Linux kernel
$ pushd $CLOUDH
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-cloud-hypervisor
$ cd linux-cloud-hypervisor
$ git reset --hard v5.0

# Use the cloud-hypervisor kernel config to build your kernel
$ cp $CLOUDH/cloud-hypervisor/resources/linux-5.0-config .config
$ make bzImage -j `nproc`
$ popd

The vmlinux kernel image will then be located at linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin.

Disk image

For the disk image, we will use a Clear Linux cloud image that contains a root partition:

$ pushd $CLOUDH
$ wget https://download.clearlinux.org/releases/29160/clear/clear-29160-kvm.img.xz
$ unxz clear-29160-kvm.img.xz
$ popd

Booting the guest VM

Now we can directly boot into our custom kernel and make it use the Clear Linux root partition. If we want to have 4 vCPUs and 512 MBytes of memory:

$ pushd $CLOUDH
$ sudo setcap cap_net_admin+ep ./cloud-hypervisor/target/release/cloud-hypervisor
$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel ./linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin \
	--disk ./clear-29160-kvm.img \
	--cmdline "console=hvc0 reboot=k panic=1 nomodules i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd root=/dev/vda3" \
	--cpus 4 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask=" \
	--rng

The above example use the virtio-console device as the guest console, and this device may not be enabled soon enough by the guest kernel to get early kernel debug messages.

When in need for earlier debug messages, using the legacy serial device based console is preferred:

$ ./cloud-hypervisor/target/release/cloud-hypervisor \
	--kernel ./linux-cloud-hypervisor/arch/x86/boot/compressed/vmlinux.bin \
	--console off \
	--serial tty \
	--disk ./clear-29160-kvm.img \
	--cmdline "console=ttyS0 reboot=k panic=1 nomodules i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd root=/dev/vda3" \
	--cpus 4 \
	--memory size=1024M \
	--net "tap=,mac=,ip=,mask=" \
	--rng

3. Status

cloud-hypervisor is in a very early, pre-alpha stage. Use at your own risk!

As of 2019/05/12, booting cloud images has only been tested with Clear Linux images. Direct kernel boot to userspace should work with most rootfs and it's been tested with Clear Linux root partitions, and also basic initrd/initramfs images.

TODO

We are not tracking the cloud-hypervisor TODO list from a specific git tracked file but through github issues instead.

4. rust-vmm project dependency

In order to satisfy the design goal of having a high-performance, security-focused hypervisor the decision was made to use the Rust programming language. The language's strong focus on memory and thread safety makes it an ideal candidate for implementing VMMs

Instead of implementing the VMM components from scratch, cloud-hypervisor is importing the rust-vmm crates, and sharing code and architecture together with other VMMs like e.g. Amazon's Firecracker and Google's crosvm.

cloud-hypervisor embraces the rust-vmm project goals, which is to be able to share and re-use as many virtualization crates as possible. As such, the cloud-hypervisor relationship with the rust-vmm project is twofold:

  1. It will use as much of the rust-vmm code as possible. Any new rust-vmm crate that's relevant to the project goals will be integrated as soon as possible.
  2. As it is likely that the rust-vmm project will lack some of the features that cloud-hypervisor needs (e.g. ACPI, VFIO, vhost-user, etc), we will be using the cloud-hypervisor VMM to implement and test them, and contribute them back to the rust-vmm project.

Firecracker and crosvm

A large part of the cloud-hypervisor code is based on either the Firecracker or the crosvm projects implementations. Both of these are VMMs written in Rust with a focus on safety and security, like Cloud Hypervisor.

However we want to emphasize that the Cloud Hypervisor project is neither a fork nor a reimplementation of any of those projects. The goals and use cases we're trying to meet are different. We're aiming at supporting cloud workloads, i.e. those modern, full Linux distribution images currently being run by Cloud Service Provider (CSP) tenants.

Our primary target is not to support client or serverless use cases, and as such our code base already diverges from the crosvm and Firecracker ones. As we add more features to support our use cases, we believe that the divergence will increase while at the same time sharing as much of the fundamental virtualization code through the rust-vmm project crates as possible.

5. Community

We are working on building a global, diverse and collaborative community around the Cloud Hypervisor project. Anyone who is interested in contributing to the project is welcome to participate.

We believe that contributing to a open source project like Cloud Hypervisor covers a lot more than just sending code. Testing, documentation, pull request reviews, bug reports, feature requests, project improvement suggestions, etc, are all equal and welcome means of contribution. See the CONTRIBUTING document for more details.

Join us

Get an invite to our Slack channel and join us on Slack.

6. Security

Reporting a Potential Security Vulnerability: If you have discovered potential security vulnerability in this project, please send an e-mail to secure@intel.com. For issues related to Intel Products, please visit https://security-center.intel.com.

It is important to include the following details:

  • The projects and versions affected
  • Detailed description of the vulnerability
  • Information on known exploits

Vulnerability information is extremely sensitive. Please encrypt all security vulnerability reports using our PGP key

A member of the Intel Product Security Team will review your e-mail and contact you to to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see: Vulnerability Handling Guidelines

PGP Key: https://www.intel.com/content/www/us/en/security-center/pgp-public-key.html

Vulnerability Handling Guidelines: https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html