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>
