Commit Graph

106 Commits

Author SHA1 Message Date
Rob Bradford
3b2faa9f11 vm-virtio: Reset underlying device on driver request
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>
2019-05-09 15:44:18 +02:00
Samuel Ortiz
040ea5432d cloud-hypervisor: Add proper licensing
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>
2019-05-09 15:44:17 +02:00
Sebastien Boeuf
b67e0b3dad vmm: Use virtio-blk to support booting from disk image
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>
2019-05-08 08:55:09 +02:00
Sebastien Boeuf
65f96e408f virtio: Add virtio-blk implementation
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>
2019-05-08 08:55:09 +02:00
Samuel Ortiz
c2c51dc9d1 vm-virtio: Add PCI transport support
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>
2019-05-08 08:55:06 +02:00
Samuel Ortiz
8246434710 vm-virtio: Initial crate
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>
2019-05-08 08:55:06 +02:00