Virtio: Linux I/O virtualization framework (IBM)

In summary,VirtioIs the abstraction layer in the semi-virtualized hypervisor located above the device.VirtioDeveloped by Rusty Russell, he aimed to support his own virtualization solutionLguest. This article introduces the semi-virtualization and analog devices at the beginning, and then exploresVirtio. The focus of this article is from the 2.6.30 kernel releaseVirtioFramework.

Linux is the hypervisor booth. As described in my analysis of Linux hypervisor, Linux provides various hypervisor solutions that have their own characteristics and advantages. These solutions include kernel-based Virtual Machine (KVM ),LguestAnd user-mode Linux. Having these different hypervisor solutions on Linux puts a burden on the operating system, depending on the needs of each solution. One of the overhead is the virtualization of the device.VirtioMultiple Device Simulation mechanisms (for networks, blocks, and other drivers) are not provided.Program), But to provide a common front-end for these device simulation, so as to standardize the interface and increaseCode.

Full virtualization and semi-Virtualization

Join the Green Group on my developerworks to discuss energy, efficiency, and environment topics and share resources in the green it report space and green Computing Group on my developerworks.

Let's quickly discuss two completely different virtualization modes: full virtualization and semi-virtualization. InFull VirtualizationThe guest operating system runs on the hypervisor on the physical machine. The guest operating system does not know that it has been virtualized and can work in this configuration without any changes. On the contrarySemi-VirtualizationThe guest operating system not only knows that it runs on the hypervisor, but also contains the code to make the guest operating system more efficient to the hypervisor (see figure 1 ).

In full virtualization mode, the hypervisor must simulate the hardware of the device, which is simulated at the lowest level of the session (for example, the Network Driver ). Although the simulation in this abstract is clean, it is also the most inefficient and complex. In the semi-virtualization mode, the guest operating system and hypervisor can work together to make the simulation more efficient. The disadvantage of the semi-virtualization method is that the operating system knows that it is virtualized and must be modified before it can work.

Figure 1. Device Simulation in fully virtualized and semi-virtualized Environments

The hardware is constantly changing with the virtualization technology. The new processor incorporates advanced commands to make the transition from the guest operating system to the hypervisor more efficient. In addition, the hardware also follows the input/output (I/O) virtualization is constantly changing (see references for Peripheral Controller interconnect [PCI] passthrough and single-and multi-root I/O virtualization ).

Replacement of virtio

VirtioIt is not the only overlord in this field. Xen provides drivers for semi-virtualization devices, and VMWare also providesGuest tools.

However, in a traditional fully virtualized environment, hypervisor must capture these requests and then simulate the behavior of physical hardware. While doing so provides great flexibility (that is, running an unchanged operating system), it is less efficient (see figure 1 on the left ). The right side of Figure 1 is a semi-virtualization example. Here, the guest operating system knows that it runs on the hypervisor and contains a driver acting as the front-end. Hypervisor simulates backend drivers for specific devices. In these front-end and back-end driversVirtioTo provide standardized interfaces for the development of simulation devices, so as to increase the cross-platform code reuse rate and improve efficiency.

Back to Top

Linux Abstraction

As you can see in the previous section,VirtioIs the abstraction of a group of common analog devices in a half-virtualized hypervisor. This setting also allows the hypervisor to export a set of common analog devices and make them available through a common application programming interface (API. Figure 2 shows why this is important. With a semi-virtualized hypervisor, the guest operating system can implement a set of common interfaces and use specific device simulation after a set of backend drivers. Backend drivers do not need to be generic because they only implement the behavior required by the front-end.

Figure 2. virtio driver Abstraction

Note: In reality (though not required), device simulation occurs in the space where qemu is used. Therefore, the backend driver interacts with the hypervisor user space, to facilitate I/O through qemu. Qemu is a system simulator that provides a guest operating system virtualization platform and the entire system (pCI host controller, disk, network, Video hardware, USB controller, and other hardware elements).

VirtioThe API relies on a simple buffer abstraction to encapsulate the commands and data required by the guest operating system. Let's checkVirtioAPI and its components.

Back to Top

Virtio Architecture

In addition to front-end drivers (implemented in the guest operating system) and back-end drivers (implemented in hypervisor,VirtioTwo layers are also defined to support communication between the guest operating system and hypervisor. At the top level (calledVirtio) Is the Virtual Queue interface, which attaches the front-end driver to the back-end driver in concept. The driver can use 0 or more queues. The specific quantity depends on the requirement. For example,VirtioThe network driver uses two virtual queues (one for receiving and the other for sending), whileVirtioThe block driver uses only one virtual queue. The Virtual Queue is actually implemented as the connection point between the guest operating system and hypervisor. However, this can be implemented in any way, provided that the guest operating system and hypervisor implement it in the same way.

Figure 3. advanced architecture of the vital framework

As shown in figure 3, five front-end drivers are listed for Block devices (such as disks), network devices, PCI simulation, and balloon drivers. Each frontend driver has a corresponding backend driver in the hypervisor.

Conceptual Hierarchy

From the perspective of the guest operating system,Object hierarchyAs shown in figure 4. Top-levelVirtio_driverIt indicates the front-end driver in the guest operating system. The device that matches the driverVirtio_deviceEncapsulation of a device in the guest operating system. This referenceVirtio_config_opsStructure (which defines the configurationVirtioDevice operation ).Virtio_deviceByVirtqueueReference (it containsVirtio_device). Finally, eachVirtqueueObject ReferenceVirtqueue_opsObject, which defines the underlying queue operations that process the hypervisor driver. Although the queue operation isVirtioAt the core of the API, I will briefly discuss new discoveries and then discuss them in detail.Virtqueue_opsOperation.

Figure 4. object hierarchy of virtio front-end

This process is used to createVirtio_driverAnd passRegister_virtio_driverStart registration.Virtio_driverThe structure defines the upper-layer device drivers, the list of device IDs supported by the drivers, a feature form (depending on the device type), and a callback function list. When hypervisor identifies a new device that matches the device ID in the device listProbeFunctionVirtio_driverObject) to pass inVirtio_deviceObject. Cache the management data of this object and the device (Cache independently of the driver ). It may be calledVirtio_config_opsFunction to obtain or set device-specific options, for exampleVirtio_blkThe device obtains the read/write status of the disk or sets the block size of the block device, depending on the type of the initiator.

Note,Virtio_deviceDoes not includeVirtqueue(VirtqueueActually referencedVirtio_device). To identify andVirtio_deviceAssociatedVirtqueue, You need to useVirtio_config_opsObject andFind_vqFunction. This object is returned with thisVirtio_deviceThe Virtual Queue associated with the instance.Find_vqThe function also allowsVirtqueueSpecify a callback function (viewVirtqueueStructure ).

VirtqueueIs a simple structure, which recognizes an optional callback function (called when hypervisor uses the buffer pool),Virtio_deviceToVirtqueueOperation Reference, as well as a reference to use the underlying Implementation of the specialPrivReference. AlthoughCallbackIt is optional, but it can enable or disable callback dynamically.

The core of this hierarchy isVirtqueue_opsIt defines how to move commands and data between the guest operating system and hypervisor. Let's first explore how to add to or fromVirtqueueThe object to be removed.

Virtio Buffer Pool

The guest operating system (front-end) driver interacts with hypervisor through the buffer pool. For I/O, the guest operating system provides one or more buffer pools that represent requests. For example, you can provide three buffer pools. The first one represents the read request, and the second two represents the response data. This configuration is internally represented as a scatter-gather list. Each entry in the list represents an address and a length.

Core APIs

PassVirtio_deviceAndVirtqueue(More common) link the guest operating system driver with the hypervisor driver.VirtqueueSupports its own APIs composed of five functions. You can use the first functionAdd_bufTo provide a request to the hypervisor. As described above, the request exists in the form of a scattered set list. ForAdd_bufThe guest operating system providesVirtqueueThe number of buffer pools used as output entries (the target is the underlying hypervisor, and the number of buffer pools used as input entries (hypervisor will store data for them and return data to the guest operating system. WhenAdd_bufWhen sending a request to hypervisor, the guest operating system canKickThe function notifies hypervisor of new requests. In order to achieve the best performance, the guest operating system shouldKickLoad as many buffer pools as possibleVirtqueue.

PassGet_bufThe function triggers a response from the hypervisor. The guest operating system only needs to call this function orVirtqueue callbackThe function can be polling after the notification is sent. When the guest operating system knows that the buffer zone is available, callGet_bufReturn the completed buffer.

VirtqueueThe last two functions of the API are:Enable_cbAndDisable_cb. You can use these two functions to enable or disable the callback ProcessVirtqueueFromVirtqueueInitializedCallbackFunction ). Note that the callback function and hypervisor are in an independent address space, so the call is triggered by an indirect hypervisor (for exampleKvm_hypercall).

The format, sequence, and content of the buffer are only meaningful to the front-end and back-end drivers. Internal transmission (connection points in the current implementation) only moves the buffer zone and does not know their internal representation.

Back to Top

Example virtio driver

You can find the front-end drivers in the./drivers subdirectory of the Linux kernel.Source code. You can find it in./Drivers/NET/virtio_net.c.VirtioFind the network driver in./Drivers/block/virtio_blk.cVirtioBlock driver. Subdirectory./Drivers/virtio providesVirtioInterface implementation (VirtioDevice, driver,VirtqueueAnd connection points ).VirtioIt is also applied in high-performance computing (HPC) research to develop inter-Virtual Machine (VM) communication transmitted through shared memory. In particular, this is done by usingVirtioThe virtual PCI interface of the PCI driver. You can learn more about this point in the references section.

Now, you can practice this semi-virtualization infrastructure in the Linux kernel. What you need includes a kernel that acts as a hypervisor, a guest operational kernel, and a qemu used for device simulation. You can use KVM (a module located in the host kernel) or Rusty Russell'sLguest(Modified Linux guest operating system kernel ). Both virtualization solutions supportVirtio(And qemu used for System Simulation and for virtualization Management)Libvirt).

Rusty'sLguestIt is a simpler code library for semi-virtualization drivers and faster simulation of Virtual Devices. But more importantly, practice has provedVirtioBetter performance than existing commercial solutions (network I/O can be improved by 2-3 times ). Performance improvement requires a price, but if you use Linux as the hypervisor and guest operating system, it is worthwhile to do so.

Back to Top

Conclusion

Maybe you have neverVirtioA front-end or back-end driver has been developed, which implements an interesting architecture and deserves your careful exploration.VirtioIt brings new opportunities to improve the efficiency of the semi-virtualized I/O environment, and to take advantage of the achievements of xen. Linux constantly proves that it is a product hypervisor and a new virtualization technology research platform.VirtioThis example demonstrates the strength and openness of using Linux as a hypervisor.

 

References

Learning

• Rusty Russell's "virtio: towards a de factor standard for virtual I/O devices"VirtioThe best technology resources. This paper elaborates onVirtioAnd its internal structure.

   

   

• This articleArticleWe will talk about two virtualization mechanisms: full virtualization and semi-virtualization. To learn more about various virtualization mechanisms in Linux, refer to Tim's article "virtual Linux" (developerworks, December 2006 ).

   

   

• VirtioThe secret behind this is the use of semi-virtualization to improve overall I/O performance. To learn about using Linux as a hypervisor and device simulation, see Tim's article "profiling Linux hypervisor" (developerworks, May 2009) and "Linux virtualization and PCI passthrough technology" (developerworks, october 2009 ).

   

   

• This article discusses device simulation. One of the most important applications that provide this function is qemu (A System Simulator ). Read Tim's article "using qemu for system simulation" (developerworks, February September 2007) to learn more about qemu.

   

   

• Xen also includes the virtualization driver concept. Paravirtual windowsdrivers discusses semi-virtualization and hardware-assisted Virtualization (hvm), especially the latter.

   

   

• VirtioOne of the most important advantages is to improve efficiency in a semi-virtualized environment. This blog from BTM. Geek shows how to use KVMVirtio.

   

   

• This article discussesLibvirt(An open-source virtualization API) andVirtioFramework similarity. Libvirt wiki shows howLibvirtSpecified inVirtioDevice.

   

   

• This article discusses two exploitation methodsVirtioFramework hypervisor solution: lguest is an x86 hypervisor developed by Rusty Russell. KVM is another Linux-based hypervisor, which is the first hypervisor built into the Linux kernel.

   

   

• VirtioOne of the interesting applications is to develop shared memory message transmission so that VMS can communicate with each other through hypervisor. This is described in springerlink's thesis.