In order to have access to the newly added signal_msi() function
from the kvm-ioctls crate, this commit updates the version of the
kvm-ioctls to the latest one.
Because set_user_memory_region() has been swtiched to "unsafe", we
also need to handle this small change in our cloud-hypervisor code
directly.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Launch the test binary by command rather than using using the vmm layer.
This makes it easier to manage the running VM as you can explicitly kill
it.
Also switch to using credibility for the tests which catches assertions
and continues with subsequent commands and reports the issues at the
end. This means it is possible to cleanup even on failed test runs.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Add basic integration testing of the hypervisor using a cloud-init to
configure the VM at boot and SSH to control it at runtime.
Initial test just boots the VM up checks some basic resources and
reboots. With a second test that calls into the first to check that
subsequent tests work correctly.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The cargo interaction with the .cargo/config does not meet our
requirements.
Regardless of .cargo/config explicitly replacing our external sources
with vendored ones, cargo build will rely first on Cargo.lock to update
its local source cache. If a dependency has been push forced, build
fails because of our top level Cargo.toml description.
This prevents us from actually pinning dependencies, which defeats the
vendoring purpose.
We're removing vendoring for now, until we understand it better.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since the top-level Cargo.toml specifies a vmm-sys-util revision
but not the sub crates, Cargo.lock points at 2 different crates.
cargo vendor copies both of them into the vendor directory but
forces the build to use the one coming from the top level driven
requirement.
Although this is a waste of space, this is a cargo vendor limitation
that we have to live with for now.
Also, because the dependency onto linux-loader had to be updated,
we had to specify a newly introduced feature called "elf".
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
We use cargo vendor to generate a .cargo/config file and the vendor
directory. Vendoring allows us to lock our dependencies and to modify
them easily from the top level Cargo.toml.
We vendor all dependencies, including the crates.io ones, which allows
for network isolated builds.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Use a catchall case for all reasons that we do not handle, and
move the vCPU run switch into its own function.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch expand the device registration to add a new virtio-net
device in case the user provide the appropriate flag --net from the
command line.
If the flag is provided, the code will parse the TAP interface name
and the expected MAC address from the command line. The VM will be
connected to the provided TAP interface, and it will communicate the
MAC address to the virtio-net driver.
If the flag is not provided, the VM will not register any virtio-net
device, therefore it will not have any connectivity with the host.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The newly added virtio-net implementation needs to interact with TAP
interfaces and MAC addresses, which is the reason why it is easier
to rely on existing packages net_util and net_gen.
One more thing, both net_util and net_gen could be trimmed down,
based on using only the things we need from cloud-hypervisor.
Both net_util, net_gen and sys_util are based on Firecracker
commit d4a89cdc0bd2867f821e3678328dabad6dd8b767.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
After the virtio-blk device support has been introduced in the
previous commit, the vmm need to rely on this new device to boot
from disk images instead of initrd built into the kernel.
In order to achieve the proper support of virtio-blk, this commit
had to handle a few things:
- Register an ioevent fd for each virtqueue. This important to be
notified from the virtio driver that something has been written
on the queue.
- Fix the retrieval of 64bits BAR address. This is needed to provide
the right address which need to be registered as the notification
address from the virtio driver.
- Fix the write_bar and read_bar functions. They were both assuming
to be provided with an address, from which they were trying to
find the associated offset. But the reality is that the offset is
directly provided by the Bus layer.
- Register a new virtio-blk device as a virtio-pci device from the
vm.rs code. When the VM is started, it expects a block device to
be created, using this block device as the VM rootfs.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
After starting all vCPUs, we loop for STDIN input.
We need a more scalable eventfd control loop, obviously.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Based on the Firecracker devices crate from commit 9cdb5b2.
It is a trimmed down version compared to the Firecracker one, to remove
a bunch of pulled dependencies (logger, metrics, rate limiter, etc...).
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
