Virtio Design Improvements

[andreeaflorescu]

Redesign virtio devices in Firecracker.

The plan is to consume virtio devices building blocks from rust-vmm. For this goal, we need to make sure that:

• MMIO transport can be easily replaced with PCI
• Rate Limiter is not tightly coupled to the emulation of virtio
• Metrics are opt-in
• Logging is done via the default Rust logger implementation
• others?

The output of this issue is a design doc for virtio devices that takes in consideration the aforementioned constraints.

[alxiord]

re:others:

• device identification is split into device type (currently exposed by the VirtioDevice trait) + user-facing device ID. See Create Vsock device during configuration instead of boot-time #1737 (comment)

[andreeaflorescu]

@aghecenco how about we created a separate issue for the device identification? This issue was created before the decoupling work was started and I assume that now we have a few more things that need to be done. We can link the separate issues in this one.

[andreeaflorescu]

Task Breakdown:

• Have MMDS as a plug in component of Virtio Network #1761
• Remove logger dependency from devices crate #1760
• [devices] Use GuestMemory trait instead of the GuestMemoryMmap #1762
• Use component defined metrics #1759
• Separate Rate Limiter from core virtio implementation #1758
• Create composite device IDs #1763

[alxiord]

Done & added #1763 to the list above

[serban300]

Just wanted to mention a couple of very high-level points that might be worth taking into consideration here. I didn't create tasks since I don't have a detailed design.

Modularity

A virtual net device is mostly an intermediary. It forwards Ethernet frames from the host or MMDS to the guest and vice-versa. If we consider its purpose and also take into account special cases where a frame can’t be forwarded because of lack of space or other constraints, a basic net device could contain only frame forwarding, frame buffering and constraints checking (e.g. rate limiting) logic.

In the Firecracker net device this basic logic is also coupled with some extra logic. In order to keep the net device as simple as possible it would be nice to decouple this extra logic in different components. At least 3 come to mind:

• a FrontEnd or GuestEnd that would contain the logic for reading/writing to virtio queues. It could just implement Read and Write:

pub struct GuestEnd {
    queues: Vec<Queue>,
    queue_evts: Vec<EventFd>,
    interrupt_evt: EventFd,
}

impl GuestEnd {
    pub fn write(&mut self, frame: &[u8], mem: &GuestMemoryMmap) -> Result<(), Error> {
        ...
    }

    pub fn read(&mut self, frame: &mut [u8], mem: &GuestMemoryMmap) -> Result<(), Error> {
        ...
    }

    pub fn interrupt(&self) -> Result<(), Error> {
        ...
    }
}

• a BackEnd or HostEnd that would contain the logic for wrouting to the MMDS or tap. Also It could simply implement Read and Write.

• a special structure for handling frame buffering

Performance

• it would be nice if we could simplify and improve the frame deferring strategy. Notification suppression would be an option here.

[mattschlebusch]

This request has become quite old with some elements being done already, and others being considered as a part of RustVMM.