For example, right now the MAC address is passed as a String. We should validate that it is a MAC address before accepting it. We should go over all resources and check for similar shortcomings.

We need to add details about the components so we can publish it on crates.io.

For this we can follow the README template: https://github.com/rust-vmm/crate-template#crate-name

We are using rust-vmm-ci for testing this crate.

This is related to creating a minimal reference VMM using rust-vmm components. The serial console only needs the I/O Bus trait which is already merged into master.

I'm opening this issue to start the discussion around adding interrupt abstractions to the vm-device crate.

Motivation

Firecracker is working on adding support for PCI devices which naturally require support for MSI/MSI-X interrupts. CloudHypervisor already has PCI support implemented and has added support for MSI interrupts. Firecracker currently does not support MSI interrupts and uses a very simple model based on irqfds to implement interrupt delivery.

There is a large amount of device code that can be reused and shared across both CloudHypervisor and Firecracker that is not quite interoperable between VMMs today, one of the reasons being that they use different ways to work with interrupts.

Requirements

The goal is to create some abstractions in vm-device that can model the interface for working with interrupts.
This would allow devices to have VMM-independent implementations that can be reused.

Devices should be able to:

• generate events that signal and interrupt the VM vCPUs
• configure interrupts based on a pre-defined specification
• enable/disable interrupt generation
• mask/unmask interrupts
• request new interrupts

The VMM should be able to:

• implement different interrupt mechanisms based on the machine specification
• manage interrupt sources
• deliver events generated by the devices to the vCPUs
• not need device specific knowledge or implementation (apart from standard configuration templates)

General requirements:

• interrupt events should not depend on the type of hypervisor used by the VM
• while new interrupt mechanisms rarely get added, the interfaces should allow for future extension and addition of new interrupt types
• vm-device can hold standard interfaces and templates for common interrupt types (e.g. ISA, INTx, MSI)

Even though the interface will allow VMMs to implement interrupt mechanisms independently, it may be a good idea to also have a reference implementation in vm-device for a common use-case (e.g. KVM in-kernel IRQChip).

Prior work

There have been several PRs to add Interrupt management support to vm-device (#21 and #23).
There is also a different vm-device fork implementing these types of abstractions in the Cloud Hypervisor Github org (cloud-hypervisor#5) and an implementation that Cloud Hypervisor uses (https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/vm-device/src/interrupt/mod.rs).
Crossvm is using a similar interface the Trigger proposal (called Event) and adds functionality around that primitive when needed by sending requests to the hypervisor (e.g. VmIrqRequest) through a Tube (https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/main/devices/src/pci/vfio_pci.rs#178).

Next steps

We're working on proposal and a POC in Firecracker to showcase how this interface would work. The proposal is based on the previous work mentioned above and satisfies the requirements listed.
It would be great if we can get more input on the requirements of this interface.

This is a parent issue for tasks related to publishing on crates.io.

• #28
• #34
• #40
• #27

The crate needs to use rust-vmm-ci instead.

It would be great to build some benchmark test cases for struct Bus<A: BusAddress, D>. It would be useful to test for

1. there are a few devices/resource ranges registered on a bus.
2. there are plenty devices/resource ranges registered on a bus.

For details check rust-vmm/community#14

Improve the documentation of the public modules/structs/traits/functions related to the IO manager and bus abstractions.

We defined a type for the PIO offset.

Should we do the same for the MMIO one? Right now it is defined as an u64:

X86 systems supports both MMIO and PIO, most other systems only support MMIO.
To use unify interfaces to support both MMIO and PIO on x86 systems, some enums are introduced:

/// IO Addresses.
#[derive(Debug, Copy, Clone, Deserialize, Serialize)]
pub enum IoAddress {
    /// Port I/O address.
    Pio(u16),

    /// Memory mapped I/O address.
    Mmio(u64),
}

This design causes much extra works to driver implementations and unit test cases. Even on the vCPU thread, we need to encapsulate PIO address and MMIO address into IoAddress. It works as:

1. vCPU threads create IoAddress from PIO/MMIO address
2. IoManager looks up device driver by IoAddress
3. device driver decode IoAddress into PIO/MMIO address.

It also needs more storage/register to store IoAddress than Pio/MMIO address.

On the other hand, DeviceManager already has dedicated interfaces for PIO and MMIO, so suggest to build dedicated interfaces for PIO in DeviceIo, and make PIO related interfaces as conditional compilation for x86 only.

The current implementation of struct IoManager (and, generally, the device buses) can't be shared across threads (== sent to the vCPUs) because the Send and Sync constraints aren't enforced anywhere.

Please add a CODEOWNERS file with the details of the maintainers. Please use the following format as outlined in: https://help.github.com/en/articles/about-code-owners

Most projects can simply follow the wildcard syntax. e.g.

* @owner1 @owner2

Not only does this provide a way to see who is responsible or this repository they will also automatically be notified of incoming PR reviews.

Hi, everyone. Do we have a road-map/plan about what devices will be supported in this repo?
Maybe we can make a checklist here for future contribution.

I just noticed that in the interface of Bus we are returning Option<(&BusRange<A>, &D)>, where A is the address type and D is the device type.

This is not really documented in the code, but why do we need to return both the range and the device? Given the name I was expecting the function to just return the device. I would guess this is some sort of optimization so that you don't need to retrieve them separately.

As a next step, I'd like to clarify this in the code as well since we're planning on publishing this to crates.io.

Pinging @alexandruag @jiangliu @sboeuf @rbradford @sameo