Any electrical or computer engineer that reads industry publications today has likely seen the word “virtualization” enough times to know that it's a hot topic. In fact, a quick search of embedded.com yields over 200 results for the buzz word. How real is this trend? Does virtualization provide real savings? This article will attempt to answer these questions by outlining the major engineering use cases for virtualization, discussing how it impacts performance, and addressing a topic that is critical in engineering designs: hardware I/O. The goal is to allow you to make a straightforward assessment of virtualization technology for your application–independent of the hype.
Note that on December 8-10, National Instruments and Intel will present a webinar series on Embedded Virtualization.
To fully understand the performance implications of using virtualization in your own designs, it helps to know the basic principles that make virtualization hardware and software. The basic goal of virtualization is to run multiple operating systems in parallel on one computer such that no individual operating system affects the others in any way. In simple terms, any individual operating system (called a virtual machine) cannot be allowed to affect shared system resources except in very special circumstances. For example, envision several operating systems inadvertently accessing the same memory location at the same time. This situation would be a nightmare to debug, as any operating system could overwrite the stored value at any time.
The key component required to make virtualization work is a piece of software called a virtual machine monitor (VMM), also known as a hypervisor. See Figure 1 for a conceptual representation of how this software fits into a virtualized system. The VMM's mission is straightforward: prevent individual operating systems (virtual machines or VMs) from altering shared system state, therefore making sure that conflicts do not occur. In more exact terms, a VMM cannot allow individual VMs to independently execute “privileged instructions” such as accessing memory or I/O devices that could potentially conflict with other VMs accessing the same resource.
Note that there are two basic categories of VMM software: hosted and bare-metal. Because hosted VMM solutions (such as VMWare Workstation) rely on a host operating system for scheduling and I/O access, they are generally not a good fit for deployed engineering applications. Therefore, we will focus on bare-metal VMM software for the remainder of this piece.
To effectively manage shared system resources, VMM software must be called whenever an operating system wishes to execute a privileged instruction. For instance, the VMM should intervene when a particular operating system attempts to write to an Ethernet port that is shared by several OSes. In practice, there are three different ways of making sure that this happens:
• Binary translation–Software is used to translate pieces of code on the fly and call the VMM when necessary.
• Hardware assist–Virtualization features built into a processor (such as Intel-VT or AMD-V) are used to call the VMM automatically when an operating system attempts to execute privileged instructions.
• Paravirtualization–Operating system code is explicitly modified (if source code is available) to call the VMM.
Regardless of which of the methods above is used to call the VMM, the performance implications of virtualization can be compared to context switches in multithreaded applications. Every time that an operating system must call virtual machine monitor software, the state of that operating system needs to be saved in a memory structure. Likewise, this memory must be restored when control is transitioned back to the operating system. This can be a very time-consuming operation, and therefore, it's advantageous to avoid VMM intervention at all costs.
In practice, VMM intervention can be kept to a minimum with some clever design techniques. First of all, by using a multicore processor in your virtualized system and dedicating individual processor cores to individual operating systems, you can avoid using the VMM for operating system scheduling. Instead, each operating system can run independently as long as privileged instructions are not executed. Next, by partitioning memory between operating systems and configuring individual operating systems to access a certain block of physical memory, you can reduce or eliminate address translation overhead. Finally, by assigning I/O devices to individual operating systems and carefully routing interrupts, you can avoid invoking the VMM upon each I/O access or interrupt. The trend here is clear: in virtualized systems, partition where you can and share only when you must to guarantee the best performance.
To summarize, incorporating virtualization into an engineering design by using VMM software has the potential of adding some overhead to your application that can reduce performance. The exact amount of this overhead will depend on how many times the VMM software must be called to abstract shared system resources from individual virtual machines. For designers that must share system components between operating systems, a number of technologies exist that attempt to minimize the performance hit. When possible, the best strategy is to avoid VMM intervention altogether using partitioning.
It should also be noted that virtualizing two operating systems to run on a single computer (as opposed to using two or more computers) inherently means that only a fraction of the overall processing power may be present in the system. Virtualization technology is meant to use computer hardware, including processor resources, in an efficient way. It doesn't mean that a given application will necessarily be able to run with a fraction of the computing cycles.
I/O access in virtualized systems
One of the most important considerations when evaluating virtualization options for your application is I/O. Does the piece of VMM software that you are evaluating support sharing I/O devices if needed? What is the performance overhead introduced when the VMM deals with incoming interrupts? Can the VMM penalty be reduced to near zero when I/O devices are partitioned (assigned to a given operating system)?
Let us first consider the case of sharing a certain I/O device amongst different virtual machines. There are two major challenges to this approach: additional software complexity and performance degradation. VMMs that share I/O devices between operating systems must contain a driver for accessing those I/O devices (as shown in Figure 2 ), which can mean additional development time. In addition, under a sharing scheme VMMs must present virtual machines with an emulated view of the hardware that is shared. As mentioned in the previous section, because shared I/O devices lead to more VMM intervention, some performance overhead is typically added with each I/O request or incoming interrupt.
A good example of shared I/O in a virtualized system is an Ethernet device. Sharing a single Ethernet connection between different virtual machines can be advantageous for reducing hardware while providing connectivity to each operating system. To make this possible, VMM software must include a driver for communicating with the physical Ethernet device and also present individual VMs with an emulated view of the Ethernet device. When a VM wishes to communicate via Ethernet, the VMM intervenes and uses its driver to actually perform the communication, adding some latency in the process.
In contrast, let us consider partitioning of I/O devices between virtual machines. If access to a certain I/O resource such as a data acquisition device is only needed from a particular VM, performance can be increased and software complexity decreased. In this scheme, VMM software doesn't need to intervene at all if configured correctly. VMs can use their native I/O drivers to access partitioned devices without conflicts, as long as the VMM software hides these I/O devices from all other VMs. See Figure 3 for a diagram showing how this works. For example, in the case of a partitioned data-acquisition board the virtual machine monitor doesn't need a built-in data-acquisition driver. A performance hit can be minimized or avoided by allowing a single operating system to access the device directly using its native data-acquisition drivers.
The lesson here is simple: remember to think carefully about I/O when considering virtualization for your application. VMMs that share devices can provide convenience, but may require additional development effort and mean a higher performance hit. VMMs that partition devices typically provide higher performance and enable the use of native device drivers by individual VMs, which can greatly reduce development time.
When to use virtualization
Though virtualization is a promising technology that can be beneficial in many systems, it is important to understand the performance and I/O implications when looking at incorporating virtualization into your application. Specifically, virtualization may be useful if:
• you're using multiple operating systems and reducing cost or physical footprint of your design is important;
• you aren't currently using multiple operating systems, but you wish to isolate pieces of your application from each other or reduce development time by leveraging operating system capabilities;
• you're willing to take some performance hit in exchange for the consolidation that virtualization brings (this can be minimized by partitioning system resources or choosing a VMM that incorporates advanced technology);
• you can afford to spend some development time integrating a VMM into your application and developing drivers for shared I/O devices (less development time may be required with a turnkey virtualization solution or one that partitions devices).
As engineering designs continue to evolve, virtualization will play an important role by decreasing system cost and physical footprint while increasing capability. It is time for engineers to look at virtualization technology seriously, while at the same time carefully consider the engineering tradeoffs that virtualization brings and make sound decisions. Ultimately, it's up to you to decide whether virtualization lives up to the buzz.
Casey Weltzin is a product manager for real-time solutions at National Instruments. Weltzin manages the LabVIEW Real-Time product line, with special emphasis in multicore processing and virtualization technology solutions. Weltzin joined NI in 2005 and has worked as an applications engineer and manager for the Engineering Leadership Program. He holds a degree in electrical engineering from the University of Wisconsin-Madison.