Module vsock 

The Firecracker vsock device aims to provide full virtio-vsock support to software running inside the guest VM, while bypassing vhost kernel code on the host. To that end, Firecracker implements the virtio-vsock device model, and mediates communication between AF_UNIX sockets (on the host end) and AF_VSOCK sockets (on the guest end).

Modules

metrics

Defines the metrics system for vsock devices.

persist

Defines state and support structures for persisting Vsock devices and backends.

Structs

Vsock

Structure representing the vsock device.

VsockUnixBackend

The vsock connection multiplexer.

Enums

VsockError

Vsock device related errors.

VsockUnixBackendError

Vsock backend related errors.

Constants

VSOCK_DEV_ID

Device ID used in MMIO device identification. Because Vsock is unique per-vm, this ID can be hardcoded.

Traits

VsockBackend

The vsock backend, which is basically an epoll-event-driven vsock channel. Currently, the only implementation we have is crate::devices::virtio::unix::muxer::VsockMuxer, which translates guest-side vsock connections to host-side Unix domain socket connections.

VsockChannel

Any channel that handles vsock packet traffic: sending and receiving packets. Since we’re implementing the device model here, our responsibility is to always process the sending of packets (i.e. the TX queue). So, any locally generated data, addressed to the driver (e.g. a connection response or RST), will have to be queued, until we get to processing the RX queue.

VsockEpollListener

A passive, event-driven object, that needs to be notified whenever an epoll-able event occurs. An event-polling control loop will use as_raw_fd() and get_polled_evset() to query the listener for the file descriptor and the set of events it’s interested in. When such an event occurs, the control loop will route the event to the listener via notify().