KVM exposes CPUID 0BH when host supports that, but the APIC ID that KVM
provides is the host APIC ID so we need replace that with ours.
Without this Linux guest reports something like:
[Firmware Bug]: CPU1: APIC id mismatch. Firmware: 1 APIC: 21
Fixes#42
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
As mentioned in the KVM documentation, TSC_DEADLINE_TIMER feature
needs some special checks to validate that it is supported as the
cpuid will always report it as disabled.
We need to use the KVM_CHECK_EXTENSION ioctl to request the value
of KVM_CAP_TSC_DEADLINE_TIMER. In case it is supported through
the local APIC emulation provided by the CREATE_IRQCHIP in KVM,
we have to set manually this feature by patching the cpuid.
Here quoted from the KVM documentation:
```
The TSC deadline timer feature (CPUID leaf 1, ecx[24]) is always
returned as false, since the feature depends on KVM_CREATE_IRQCHIP
for local APIC support. Instead it is reported via
ioctl(KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)
if that returns true and you use KVM_CREATE_IRQCHIP, or if you
emulate the feature in userspace, then you can enable the feature
for KVM_SET_CPUID2.
```
This patch implements the behavior described above, and this allows
the VMM to remove the emulated Programmable Interval Timer (PIT) when
the TSC_DEADLINE_TIMER feature can be enabled.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
When the KVM capability KVM_CAP_SIGNAL_MSI is not present, the VMM
falls back from MSI-X onto pin based interrupts. Unfortunately, this
was not working as expected because the VirtioPciDevice object was
always creating an MSI-X capability structure in the PCI configuration
space. This was causing the guest drivers to expect MSI-X interrupts
instead of the pin based generated ones.
This patch takes care of avoiding the creation of a dedicated MSI-X
capability structure when MSI is not supported by KVM.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
In order to factorize the complexity brought by closures, this commit
merges IrqClosure and MsixClosure into a generic InterruptDelivery one.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
In order to allow virtio-pci devices to use MSI-X messages instead
of legacy pin based interrupts, this patch implements the MSI-X
support for cloud-hypervisor. The VMM code and virtio-pci bits have
been modified based on the "msix" module previously added to the pci
crate.
Fixes#12
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
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>
Because we cannot always assume the irq fd will be the way to send
an IRQ to the guest, this means we cannot make the assumption that
every virtio device implementation should expect an EventFd to
trigger an IRQ.
This commit organizes the code related to virtio devices so that it
now expects a Rust closure instead of a known EventFd. This lets the
caller decide what should be done whenever a device needs to trigger
an interrupt to the guest.
The closure will allow for other type of interrupt mechanism such as
MSI to be implemented. From the device perspective, it could be a
pin based interrupt or an MSI, it does not matter since the device
will simply call into the provided callback, passing the appropriate
Queue as a reference. This design keeps the device model generic.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
When not running on a tty (tested with libc's isatty()) disable stdin
and do not reconfigure the terminal.
This is required to ensure that the VM responds correctly when running
in a headless environment such as Jenkins.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Instead return from the control_loop() and calling function cleanly.
This is helpful for the testing framework as that means we can launch
multiple VMs in a row.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The command line parsing of the user input was not properly
abstracted from the vmm specific code. In the case of --net,
the parsing was done when the device manager was adding devices.
In order to fix this confusion, this patch introduces a new
module "config" dedicated to the translation of a VmParams
structure into a VmCfg structure. The former is built based
on the input provided by the user, while the latter is the
result of the parsing of every options.
VmCfg is meant to be consumed by the vmm specific code, and
it is also a fully public structure so that it can directly
be built from a testing environment.
Fixes#31
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Store the list of disks in a Vec<PathBuf> and then iterate over that
when creating the block devices.
Signed-off-by: Rob Bradford <robert.bradford@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>
In order to get meaningful error messages, we want to make sure all
errors are passed up the call stack. This patch fixes this previous
limitation by separating errors related to the DeviceManager from
errors related to the Vm.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
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>
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>
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>
