How VirtIO Boosts I/O Performance in Cloud Virtualization

VirtIO

VirtIO was developed by Rusty Russell originally to support his lguest hypervisor, aiming to provide near‑physical I/O performance and functionality in virtualized environments while avoiding the need for extra drivers inside the guest OS. It later evolved into an open‑source virtual device interface standard widely supported by KVM, QEMU, Xen, and VMware.

To achieve higher performance and lower overhead, VirtIO uses para‑virtualization, contrasting with the slower full virtualization (e.g., QEMU I/O emulation). This requires the guest OS to install a non‑native VirtIO front‑end driver, and the overall architecture is defined by a front‑end (guest kernel driver) and a back‑end (VMM provider) that follow a unified transport protocol.

Applying VirtIO brings several benefits despite the need for an extra front‑end driver (usually pre‑installed in QCOW2 images):

High performance : VirtIO eliminates the trap overhead of full virtualization, allowing the guest OS to interact directly with device emulation via VirtIO interfaces.

Low overhead : It reduces CPU overhead caused by frequent kernel‑user mode switches and VM entry/exit transitions.

Standardization : VirtIO provides a unified virtual device interface that can be used across multiple virtualization solutions.

VirtIO Virtual Device Interface Standard

To mitigate the cross‑platform compatibility challenges of para‑virtualization, VirtIO embraced open source, building a standardized ecosystem that minimizes compatibility issues and turns them into advantages.

The VirtIO standard defines multiple subsystems, each specifying a set of virtual device types and protocols, such as:

VirtIO‑Block : virtual block device interface.

VirtIO‑Net : virtual network device interface.

VirtIO‑Serial : virtual serial device interface.

VirtIO‑Memory : virtual memory device interface.

VirtIO‑Input : virtual input device interface.

Additional types include VirtIO‑SCSI, VirtIO‑NVMe, VirtIO‑GPU, VirtIO‑FS, VirtIO‑VSock, among others.

VirtIO Front‑End/Back‑End Layered Architecture

The layered software architecture of the VirtIO standard is illustrated below:

Front‑end : a set of generic drivers installed in the guest OS kernel that invoke the back‑end via hyper‑calls.

Back‑end : hypervisor‑specific device emulation programs running in the VMM, providing hyper‑call interfaces.

Transport : a standard transport layer interface based on ring buffers for batch I/O processing.

VirtIO Control‑Path and Data‑Path Separation

VirtIO defines separate control and data paths. The control plane emphasizes flexibility to support various devices and vendors, while the data plane focuses on high‑throughput packet forwarding.

Control path : manages the establishment or removal of data paths between front‑end and back‑end, providing manageable flexibility.

Data path : handles data transfer between front‑end and back‑end, prioritizing performance.

The standard itself is split into two parts:

VirtIO Spec : defines how to build the control and data paths between front‑end and back‑end, e.g., using ring‑buffer layouts for the data path.

Vhost Protocol : defines high‑performance implementations of the data path, such as kernel‑based, DPDK, or SmartNIC offloading.

For example, QEMU implements the control path according to the VirtIO Spec, while the data path can bypass QEMU using vhost‑net, vhost‑user, etc.

VirtIO Transport Layer Standard

The transport layer is called Virtqueues. In a virtual NIC (e.g., QEMU VirtIO‑Net), two Virtqueues correspond to the NIC’s Rx/Tx queues, using shared memory IPC between host and guest to avoid inefficient VMM processing.

Each Virtqueue consists of two rings:

Available Ring : stores buffer addresses that the front‑end makes available to the back‑end.

Used Ring : stores buffer addresses that the back‑end has processed.

Bidirectional notification mechanisms coordinate the two sides:

Available Buffer Notification : front‑end notifies the back‑end of pending buffers.

Used Buffer Notification : back‑end notifies the front‑end that buffers have been processed.

When the guest sends data, the front‑end fills the Send Queue, records the address in the Available Ring, and notifies the back‑end. The back‑end retrieves the data, processes it, records the buffer in the Used Ring, and sends a Used Buffer Notification. The front‑end then releases the buffer.

When the guest receives data, the front‑end allocates a Receive Queue buffer, records it in the Available Ring, and notifies the back‑end. The back‑end fills the buffer, records it in the Used Ring, and notifies the front‑end, which then reads the data.

In PCI passthrough scenarios, virtio‑pci (often via VFIO) still uses the same notification mechanism, but the data path is handled by DMA and dedicated queues, offering higher performance and illustrating the benefits of control/data path separation.

VirtIO Implementation in Linux

With the layered architecture and control/data path separation in place, VirtIO is implemented in Linux as follows:

Driver layer (Front‑end) : various I/O device drivers installed in the guest OS kernel, e.g., virtio‑net, virtio‑blk.

Transport layer : defines control and data plane transport standards, e.g., vhost‑net (kernel), vhost‑user (DPDK), virtio‑pci (PCI/PCIe).

Control plane communication (virtio) : handles exchange and negotiation of control signals between front‑end and back‑end.

Data plane communication (Transport) : handles actual data transfer, such as Virtqueues.

Device layer (Back‑end) : device emulation programs running on the hypervisor or real hardware devices.