Introduction to Virtio Protocol | openEuler

BlogIntroduction to Virtio Protocol

Introduction to Virtio Protocol<br>Ying Fang2020-11-04virtualizationvirtio

Abstract ​<br>Paravirtualization (virtio) devices have been widely used in cloud computing virtualization scenarios.<br>More and more physical devices support the virtio protocol, that is, virtio offload. The virtio protocol is offloaded to hardware (for example, virtio-net NICs and virtio-scsi) to accelerate physical machines and virtual machines (VMs).<br>This article describes some key points in the virtio technology to deepen our understanding of paravirtualization.<br>This article is intended for readers who have a basic understanding of I/O virtualization. It aims to help readers who want to understand the internal mechanism of virtio.<br>Before we start, let's think about the following questions:<br>How are virtio devices implemented?<br>What are the contents of the configuration space of the virtio-pci device?<br>The front-end and back-end of virtio communicate with each other through the shared memory mechanism. Why is there no lock?<br>What are the key data structures in the virtio mechanism? Where is the virtio configuration interface stored? How does virtio work?<br>How do the front-end and back-end of virtio communicate with each other? What are irqfd and ioeventfd? How are they used in the communication between the front-end and back-end of virtio?<br>Virtio devices support MSIx. How does QEMU/KVM simulate MSIx?<br>What are the new features of virtio modern compared with virtio legacy?<br>0. **Introduction to **Virtio Specifications ​<br>The virtio protocol was first proposed by IBM. As a standard protocol, virtio is managed by a dedicated technical committee.<br>For details about the specifications, visit the virtio official website.<br>Developers can submit a new virtio device proposal through a Request For Comments (RFC) to the technical committee. After the proposal is approved by the committee, new virtio device types can be added.<br>A virtio device consists of four parts: device status field, feature bits, device configuration space, and one or more virtqueues.<br>The device status field contains six states:<br>ACKNOWLEDGE (1): The GuestOS discovers the device and acknowledges it as a valid virtio device.<br>DRIVER (2): The GuestOS knows how to drive the device.<br>FAILED (128): The GuestOS cannot drive the device because something is wrong.<br>FEATURES_OK (8): The GuestOS acknowledges all features, and the features are negotiated.<br>DRIVER_OK (4): The driver is loaded and the device is ready to use.<br>DEVICE_NEEDS_RESET (64): The device encounters an error and needs to be reset to continue working.<br>The feature bits are used to identify the features supported by a device. Bits 0 to 23 are used by specific devices. Bits 24 to 37 are reserved for the queue and feature negotiation mechanisms. Bits 38 and above are reserved for other purposes in the future.<br>For example, for a virtio-net device, feature bit 0 indicates that the NIC supports checksum. The feature bit VIRTIO_F_VERSION_1 indicates whether a device supports the virtio 1.0 specifications.<br>In the virtio protocol, all devices use virtqueues to transmit data. Each device can have zero or more virtqueues, and each virtqueue occupies two or more 4-KB physical pages. Two virtqueue modes are supported: split virtqueues and packed virtqueues.<br>In split virtqueues mode, a virtqueue is divided into several parts, where each part is unidirectionally writable by the front-end driver or back-end device, but not both. Each virtqueue has a 16-bit queue size parameter, which indicates the total length of the queue. Each virtqueue consists of three parts:<br>+-------------------+--------------------------------+-----------------------+<br>| Descriptor Table | Available Ring (padding) | Used Ring |<br>+-------------------+--------------------------------+-----------------------+<br>Descriptor Table: stores I/O transmission request information.<br>Available Ring: records the updated items in the descriptor table. The ring can be written by the front-end driver and read only by the back-end device.<br>Used Ring: records the requests that have been submitted to the hardware in the descriptor table. The ring can be read only by the front-end driver and written by the back-end device.<br>The working mechanism of device I/O requests in the virtio protocol can be summarized as follows:<br>The front-end driver stores the I/O request in the descriptor table, updates the index to the available ring, and kicks the back-end device to obtain data.<br>The back-end device obtains the I/O request for processing, updates the result to the descriptor table and then the used ring, and sends an interrupt to notify the front-end driver.<br>According to the virtio protocol, virtio devices can be implemented in the following modes.<br>Virtio Over PCI BUS: Virtio devices comply with the PCI specifications and are mounted to the PCI bus as virtio-pci devices.<br>Virtio Over MMIO: Virtualization platforms that do not...