Until now, the only way to get some networking with cloud-hypervisor
was to let the user create a TAP interface first, and then to provide
the name of this interface to the VMM.
This patch extend the previous behavior by adding the support for the
creation of a brand new TAP interface from the VMM itself. In case no
interface name is provided through "tap=<if_name>", we will assume
the user wants the VMM to create and set the interface on its behalf,
no matter the value of other parameters (ip, mask, and mac).
In this same scenario, because the user expects the VMM to create the
TAP interface, he can also provide the associated IP address and subnet
mask associated with it. In case those values are not provided, some
default ones will be picked.
No matter the value of "tap", the MAC address will always be set, and
if no value is provided, the VMM will come up with a default value for
it.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Most of the code is taken from crosvm(bbd24c5) but is modified to
be adapted to the current VirtioDevice definition and epoll
implementation.
A new command option '--rng' is provided and it gives one the option
to override the entropy source which is /dev/urandom by default.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Since more virtio devices will be added and this code can be reused
for any type of virtio device.
Signed-off-by: Chao Peng <chao.p.peng@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>
In order to provide connectivity through network interface between
host and guest, this patch introduces the virtio-net backend.
This code is based on Firecracker commit
d4a89cdc0bd2867f821e3678328dabad6dd8b767
It is a trimmed down version of the original files as it removes the
rate limiter support. It has been ported to support vm-memory crate
and the epoll handler has been modified in order to run a dedicated
epoll loop from the device itself. This epoll loop runs in its own
dedicated thread.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
"cargo fmt --all -- check" does not check all the other crates in the
repository so replace this with a find command. In the long term it
might be appropriate to use a cargo workspace to solve this problem.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
This is helpful and actually needed to ensure everyone is testing
from the same kernel reference.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
As it is necessary to return the interrupt EventFD and the queue EventFD
to the transport layer upon reset the activate function has been
modified to clone these descriptors as well as the underlying disk
itself.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
If the driver triggers a reset by writing zero into the status register
then reset the underlying device if supported. A device reset also
requires resetting various aspects of the queue.
In order to be able to do a subsequent reactivate it is required to
reclaim certain resources (interrupt and queue EventFDs.) If a device
reset is requested by the driver but the underlying device does not
support it then generate an error as the driver would not be able to
configure it anyway.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Add the BSD and Apache license.
Make all crosvm references point to the BSD license.
Add the right copyrights and identifier to our VMM code.
Add Intel copyright to the vm-virtio and pci crates.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to have proper output from the serial, we need to setup the
terminal in raw mode. When the VM is shutting down, it is also the
VMM responsibility to set the terminal back into canonical mode if we
don't want to get any weird behavior from the shell.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
In order to let the user choose which kernel parameters to append, the
kernel boot parameters can be now specified from the command line.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Based on the new virtio-blk support, this commit allows any user to
specify a --disk option in order to select the rootfs it wants to
use for the VM.
For now it assumes the partition 3 /dev/vd3 is the one where we can
find the rootfs.
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>
This commit introduces the virtio-blk backend implementation, which is
the first device implementing the VirtioDevice trait.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Copied from crosvm 107edb3e with one main modification: VirtioPciDevice
implements BusDevice.
We need this modification because it is the only way for us to be able
to add a VirtioPciDevice to the MMIO bus. Bus insertion takes a
BusDevice. The fact that VirtioPciDevice implements PciDevice which
itself implements BusDevice does not mean that Rust will automatically
downcast a VirtioPciDevice into a BusDevice.
crosvm works around that issue by having the PCI, virtio and BusDevice
implementations in the same crate.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Copied from Firecracker 17a9089d for the queue implementation and from
crosvm 107edb3e for the device Trait. The device trait has some PCI
specific methods hence its crosvm origin.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This crate is based on the crosvm devices/src/pci implementation from 107edb3e
We introduced a few changes:
- This one is a standalone crate. The device crate does not carry any
PCI specific bits.
- Simplified PCI root configuration. We only carry a pointer to a
PciConfiguration, not a wrapper around it.
- Simplified BAR allocation API. All BARs from the PciDevice instance
must be generated at once through the PciDevice.allocate_bars()
method.
- The PCI BARs are added to the MMIO bus from the PciRoot add_device()
method.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is the only clean, or not so dirty way for us to pass a BusDevice
instance to the PciRoot add_device() method.
This is very similar to what crosvm does and we now understand why...
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is based on the crosvm resource allocator from commit 107edb3e.
We only have PIO and MMIO address space to handle, and don't have a GPU
specific path and space.
Also, we support allocating a range at a specified address. This is
mostly useful for PIO, but might be also necessary for MMIO.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Introduce emulation of i8042 device to allow the guest to stop the
VM by issuing a reset event.
The device has been copied over from the Crosvm code base, relying on
the commit 0268e26e1ac9e09aa51d733482c5df139cd8d588.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
An exit event is required to be created and handled for the purpose
of letting the guest kernel stop the VM.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Instead of handling stdin in its own separate loop, we use a generic
one that can be reused for other events handling.
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>
Both crates are based on Firecracker commit 9cdb5b2.
They are ported to the new memory model and tests have been fixed
accordingly.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
