How Virtio Boosts I/O Performance in KVM/QEMU Virtualization

Virtio is a semi‑virtualized I/O solution that provides a unified programming interface for virtual devices across various hypervisors (KVM, QEMU, Xen, VMware). It creates a communication framework between guest‑VM applications and the virtual devices offered by the hypervisor, simplifying driver development and enhancing compatibility.

The following diagram shows the path model for a VM accessing hardware in a fully virtualized environment:

The guest driver issues an I/O request.

KVM’s I/O capture code intercepts the request.

KVM processes the request, places information in a shared I/O page, and notifies the user‑space QEMU process.

QEMU receives the request details and forwards them to the device emulation code, which may use real hardware or pure software simulation.

After the I/O operation completes, QEMU writes the result back to the shared page and notifies KVM’s capture code.

KVM reads the result from the shared page and returns it to the guest.

During this process the guest VM (a QEMU thread) may be blocked while waiting for I/O. For large DMA transfers, QEMU writes results directly into the guest’s memory via memory‑mapped I/O rather than the shared page, and KVM signals DMA completion.

Advantages and Disadvantages of Traditional Virtio I/O

Advantages:

Disadvantages:

Virtio was introduced to address these performance issues.

Virtio Advantages

Standardization: Virtio defines a uniform device interface and virtio‑ring provides a standard transport layer, allowing the same front‑end to work with block, network, PCI, SCSI, and other devices.

Ring‑based batch processing of I/O requests.

Reduces frequent kernel‑user space switches, lowering the overhead caused by VM‑host context transitions.

Virtio Disadvantages

The guest VM must load a Virtio front‑end driver.

By employing a semi‑emulated approach—adding a Virtio front‑end driver—virtual devices can use new event‑notification and data‑transfer mechanisms to greatly improve performance. For example, virtio‑blk uses io_event_fd for front‑to‑back notifications, interrupt injection for back‑to‑front notifications, and a shared virtio ring (vring) for data exchange.

Virtio consists of four layers:

Front‑end drivers in the guest (e.g., virtio_blk, virtio_net, virtio_scsi). virtio-pci: the device appears as a PCI device following the standard PCI bus model. virtio‑ring: implements control‑plane interfaces (queues, notifications) and data‑plane ring buffers for communication between front‑end and back‑end.

Back‑end: hypervisor‑side processing modules implemented in QEMU.

From a code perspective, Virtio is split between QEMU (which creates virtual devices before VM boot) and kernel drivers (which load inside the guest when the device is detected).

Virtual storage in QEMU is organized into three parts:

Top‑level virtual disks (e.g., virtio‑blk, virtio‑scsi, IDE) that the VM reads/writes; QEMU translates these I/O requests into host‑side disk operations.

Middle‑layer image formats (raw, qcow2, sheepdog) that implement advanced storage features such as cloning and snapshots.

Bottom‑layer host storage adapters that write/read actual files or block devices on the host.