Timeline
Timeline
2026-07-22
init
VirtIO introduction
VirtIO, or Virtual Input/Output, is an abstraction layer for virtual machines on a host device. Essentially, it is an interface thatallows virtual machines to use the host’s devices through minimalist virtual devices (called VirtIO devices). These VirtIO devices are very minimalist because they only implement the basic requirements for sending and receiving data.
This is because in VirtIO, we let the host take care of most of the setup, maintenance, and processing of its actual hardware devices.The role of VirtIO devices is basically to transfer data to the host’s actual physical hardware。
- VM: I want to go to google.com. Hey virtio-net, can you tell the host to fetch this webpage for me?
- Virtio-net: Sure. Host, can you fetch this webpage for us?
- Host: Sure. I am currently fetching the webpage data.
- Host: Here is the requested webpage data
- Virtio-net: Thanks. Hey, VM, here is the webpage you requested
Although this is an overly simplified example, it still illustrates the core idea. That is, let the host’s hardware do as much work as possible, and let VirtIO handle sending and receiving data. Offloading most of the work to the host makes execution on the virtual machine faster and more efficient than emulated devices.
Another important aspect of VirtIO is that its core framework has been standardized as the official VirtIO specification. The VirtIO specification defines the standard requirements that VirtIO devices and drivers must meet (e.g., feature bits, status, configuration, general operations, etc.). This is important because it means that regardless of the environment or operating system using VirtIO, the core framework of its implementation must be the same.
While VirtIO implementations have a certain level of compliance, there is also some flexibility in their organization and setup. For example, the structure in the Linux kernel
virtqueuestructure is different from QEMU’sVirtQueuestructure.
VirtIO architecture
The architecture of VirtIO consists of three key parts:
- Frontend driver
- Backend device
- VirtQueues and VRings
The figure below shows the location of each component in a typical VirtIO host and guest configuration (without vHost, SR-IOV, etc.).
The frontend VirtIO driver resides in the Guest kernel, and the backend VirtIO device resides in the virtual machine (QEMU),and the communication between them is handled in the data plane through VirtQueue and VRing。
We can also see notifications issued from the VirtIO driver and device (such as VMExit, vCPU IRQ), which are routed to KVM interrupts.
VirtIO Driver (Front-End)
In a typical VirtIO Host and Guest configuration, the VirtIO driver resides in the Guest kernel. In the Guest operating system, each VirtIO driver is treated as a kernel module. The core responsibilities of the VirtIO driver include:
Accepting input/output requests from user processes
Transmitting these I/O requests to the corresponding backend VirtIO device
Retrieve completed requests from the VirtIO device counterpart
For example:
The I/O request for virtio-scsi might be a user wanting to retrieve a document from storage.
The virtio-scsi driver accepts the request to fetch the document and sends the request to the virtio-scsi device (backend).
After the VirtIO device completes the request, the document is provided to the VirtIO driver. The VirtIO driver retrieves the document and makes it available to the user.
VirtIO Device (Back-End)
Furthermore, in a typical Host and Guest configuration, VirtIO devices exist within the virtual machine. In the figure above, we will use QEMU as our (Type 2) virtual machine. This means our VirtIO device will exist within the QEMU process. The core responsibilities of the VirtIO device include:
- Accepting I/O requests from the corresponding frontend VirtIO driver
- Processing requests by offloading I/O operations to the host’s physical hardware
- Making the data of the processed request available to the VirtIO driver
Returning to the virtio-scsi example:
- The virtio-scsi driver notifies its device counterpart that the device needs to fetch the requested document from storage on the actual physical hardware.
- The virtio-scsi device accepts the request and makes the necessary calls to fetch the data from the physical hardware.
- Finally, the device makes the data available to the driver by placing the retrieved data into the shared VirtQueue.
VirtQueues
The final key component of the VirtIO architecture is the VirtQueue, which are data structures that help the device and driver perform various I/O operations.
VirtQueues are shared in Guest physical memory, meaning each VirtIO driver and device pair accesses the same page in RAM. In other words, the VirtQueue of the driver and the device are nottwo separate synchronized regions.
There are many inconsistencies in online descriptions of VirtQueues. Some use them synonymously with virtual rings (VRings, or Virtio-rings), while others describe them separately. This is because VRings are the main feature of VirtQueues; a VRing is the actual data structure that facilitates data transfer between the VirtIO device and driver. We will describe them separately here because a VirtQueue is more than just a VRing.