The virtio console device is a console for the communication between
the host and guest userspace. It has two parts: the device and the
driver. The console device is implemented here as a virtio-pci device
to the guest. On the other side, the guest OS expected to have a
character device driver which provides an interface to the userspace
applications.
The console device can have multiple ports where each port has one
transmit queue and one receive queue. The current implementation only
supports one port. For data IO communication, one or more empty
buffers are placed in the receive queue for incoming data, and
outgoing characters are placed in the transmit queue. Details spec
can be found from the following link.
https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7
Apart from the console, for the communication between guest and host,
the Cloud Hypervisor has a legacy serial device implemented. However,
the implementation of a console device lets us be independent of legacy
pin-based interrupts without losing the logs and access to the VM.
Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
With this new AddressAllocator as part of the SystemAllocator, the
VMM can now decide with finer granularity where to place memory.
By allocating the RAM and the hole into the MMIO address space, we
ensure that no memory will be allocated by accident where the RAM or
where the hole is.
And by creating the new MMIO hole address space, we create a subset
of the entire MMIO address space where we can place 32 bits BARs for
example.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The requested address for a range can be the base of the entire
address space, this is a valid use case.
In particular, when creating an MMIO address space of 0-64GiB, we
might want to create a range of 0-1GiB if the RAM of our VM is 1G.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
This patch fixes the function first_available_range() responsible
for finding the first range that could fit the requested size.
The algorithm was working, that is allocating ranges from the end
of the address space because we created an empty region right at the
end. But the problem is, the VMM might request for some specific
allocations at fixed address to allocate the RAM for example. In this
case, the RAM range could be 0-1GiB, which means with the previous
algorithm, the new available range would have been found right after
1GiB.
This is not the intended behavior, and that's why the algorithm has
been fixed by this patch, making sure to walk down existing ranges
starting from the end.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
GSI (Global System Interrupt) is an extension of just a linear array of
IRQs. It takes IOAPICs into account for example.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
There is alignment support for AddressAllocator but there are occations
that the alignment is known only when we call allocate(). One example
is PCI BAR which is natually aligned, means for which we have to align
the base address to its size.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
This is only for allocating the port IO address range.
If a platform does not have PIO devices at all, the address
range will simply be unused.
So, simplify the vm-allocator data structure by making both
MMIO and PIO mandatory.
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
This patch adds the support for both IO and Memory BARs by expecting
the function allocate_bars() to identify the type of each BAR.
Based on the type, register_mapping() insert the address range on the
appropriate bus (PIO or MMIO).
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The way the function write_reg() was implemented, it was not keeping
the bits supposed to be read-only whenever the guest was writing to one
of those. That's why this commit takes care of protecting those bits,
preventing them from being updated.
The tricky part is about the BARs since we also need to handle the very
specific case where the BAR is being written with all 1's. In that case
we want to return the size of the BAR instead of its address.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
A BAR can be three different types: IO, 32 bits Memory, or 64 bits
Memory. The VMM needs a way to set the right type depending on its
needs.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
In order to support use cases that require MSI, the pci crate is
being expanded with the description of an MSI PCI capability
structure through the new MsiCap Rust structure.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
This commit enhances the current msi-x code hosted in the pci crate
in order to be reused by the vfio crate. Specifically, it creates
several useful methods for the MsixCap structure that can simplify
the caller's code.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The QCOW2 format is documented here:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/qcow2.txt;hb=HEAD
The only difference between v2 and v3 is the addition of some extra
fields into the header in v3 for which there are default values in v2.
This introduces a new unit test for the behaviour but it has been
manually verified by the converting the image from v3 to v2
with a command like:
qemu-img convert -O qcow2 -o compat=0.10 clear-29620-cloud.img clear-29620-cloud.img.v2
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
In some situations it is possible for the setting of the capabilities to
fail due to the variable naming of the build artifacts resulting in the
first parameter to setcap being rejected and thus the whole command
failing.
Use xargs -n 1 to ensure that every potential target independently has
its caps set.
Further it was observed that in some situations the binary produced by
cargo test --all --no-run would not be used and instead a new binary
would be produced when the test was run using the second method. This
again would result in test failures as that binary did not have the
desired capabilities set. Therefore build the test binaries with the
same methodology used to run them.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
On the Jenkins build slaves disk I/O is a bottlneck so make /tmp a tmpfs
which removes I/O issues when running lots of VMs at the same time.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Create a struct to handle all the details for the guest under test
including details of network and disks.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Allow replacement of the network details used for the VM. By replacing
those from the file checked into the source tree we can continue to use
the file in the tree for manual testing but adjust the network per-VM to
allow parallel testing.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
In the future this will provide the basis for the ability to customise
the cloud-init file per VM.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
By sleeping more earlier this will speed up the tests as the SSH
connection will complete on the first attempt and thus alleviate timeout
and backoff delays.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Use the tempdir crate to create a temporary directory that is deleted
when the structure goes out of scope.
Use this temporary directory for all temporary test files created by the
tests. The cloud init file is still in /tmp as that is created by the
test wrapper code.
This is the first stage towards being able to run the integration tests
in parallel.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The addition of [workspace] to the top level Cargo.toml is necessary to
have the binaries colocated together.
The Cargo.lock files have also been refreshed by the change to the
Cargo.toml.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The type of interrupt_evt has changed along with the addition of an
msix_config member for the virtio device.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Rather than relying on shared memory for a temporary file for QCOW
testing instead use tempfile crate to get a temporary file. The vector
cache tests also need a trivial update after the refactor.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
With the adoption for rust-vmm linux-loader crate some small changes
were needed to update the unit tests to reflect this change:
* configure_system now takes an extra parameter
* the e820 entry structure comes from the linux-loader crate
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Some refactoring has taken place since the unit tests were written:
The read/write in BusDevice now take a base address and the interrupt
handling code has changed necessitating the need for a new TestInterrupt
struct.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The older version of pnet had a bug which broke some of the behaviour
that the unit tests relied upon.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Add a "--serial" command line that takes as input either "off", "tty"
(default and current behaviour) and "file=/path/to/file".
When "--serial off" is used the serial device is not added to the VM
configuration at all.
Integration tests added that check for interrupts present (or not) and
that when sending to a file the file contains the expected serial
output.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Now that cloud-hypervisor VMM supports virtio-pmem, it can directly
boot a VM from an image exposed as a persistent memory block device.
That's why there is no need to force the --disk option as being
mandatory.
Fixes#90
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Until now, the VMM was only accepting a single instance of virtio-net
device. This commit extends the virtio-net support by allowing several
devices to be created for a single VM.
Fixes#71
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
For every parameter dealing with a size as option, such as memory or
virtio-pmem, the CLI can now parse sizes with the suffixes K, M or G.
Fixes#70
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
PciConfigIo is a legacy pci bus dispatcher, which manages all pci
devices including a pci root bridge. However, it is unnecessary to
design a complex hierarchy which redirects every access by PciRoot.
Since pci root bridge is also a pci device instance, and only contains
easy config space read/write, and PciConfigIo actually acts as a pci bus
to dispatch resource based resolving when VMExit, we re-arrange to make
the pci hierarchy clean.
Signed-off-by: Jing Liu <jing2.liu@linux.intel.com>
When reading from or writing to a PCI BAR to handle a VM exit, we need
to have the BAR address itself to be able to support multiple BARs PCI
devices.
Fixes: #87
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
With the range base for the IO/MMIO vm exit address, a device with
multiple ranges has all the needed information for resolving which of
its range the exit is coming from
Fixes: #87
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When resolving an IO address to a device, return the range base address,
the offset, and the device itself.
This is needed for devices with multiple IO regions to find out which
region an IO/MMIO exit is coming from.
We also use this change as an opportunity to rename get_device to
resolve as we're doing more than just getting a device.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Partial sync as we're not going to use the the full_addr boolean.
This is based on crosvm commit 44863792.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
