Pick the right multicore virtualization use case for your design
Use Case 2 – Utilization
Improving computer hardware utilization has been the classic use case for virtualization. The first mainframe operating systems in the 1960’s were inherently single-user, and batch processing was used to efficiently use the mainframe compute resources—one job after another was fed into the mainframe for processing.
At the time allowing a person to interactively program and use a computer would have been extremely inefficient with the mainframe’s CPU being substantially idle as a user slowly typed at a terminal.
To enable multiple users to interactively use a mainframe at the same time, in the mid-1960’s IBM introduced the concept of a virtual machine monitor which was used to “time share” the mainframe for multiple users— each user had a virtual machine (VM) capable of running their own private instance of the OS.
The virtual machine monitor time sliced processing cycles among the virtual machines, thus accomplishing the goal of allowing direct user interaction with the computer while still maintaining a high level of utilization.
The need to improve hardware utilization manifested itself again in the early 2000’s with the emergence of data centers based on commodity servers where it was found that many servers running Windows and Linux were greatly underutilized.
Virtualization provided a means run many virtual machines on a single server, improving system utilization, and resulting in huge power and cost savings. Utilization is frequently less of a concern in embedded systems, but there are situations as shown in Figure 4 below where a software domain may require less than the processing power of an entire CPU and the system can benefit by consolidating several such domains onto a single CPU.
Figure 4. Virtualization provides better system utilization, resulting in power & cost savings.
Suppose a system designer wants add a web-browser accessible administration interface, based on Linux to a network appliance. It would be reasonably straightforward to implement a VM running Linux dedicated to providing this administration service.
However, a configuration GUI would be typically invoked infrequently meaning that CPU cycles would be only needed occasionally. Thus, the physical CPU which runs the VM could be shared by other VMs.
This use case requires a capable scheduler in the hypervisor to make effective use of the CPU by scheduling the allocation of CPU cycles to the different software domains sharing the CPU. In summary, virtualization can enable sharing of a CPU and flexible fine-grained control over CPU utilization-- how CPU cycles are allocated to virtual machines.
Use Case 3 – Sandboxing
Embedded systems are typically fixed function devices designed for a specific purpose, and naturally are quite different than general purpose computers which allow a variety of end user installed applications.
Software in embedded systems will commonly be “closed” with limited ability to change or add new software. However, there is an increasing interest by OEMs to provide ways for customers to extend the capabilities of systems by adding 3rd party or other custom software.
An OEM may provide an SDK that allows creating of this type of software, which then can be installed on the embedded device. To introduce “untrusted” software into a system while maintaining system integrity requires isolating or partitioning any untrusted software components away from the rest of the system.
Click on image to enlarge.
Figure 5: Sandboxing Use Case
A hypervisor can provide the needed security to enforce the boundaries of the “sandbox” in which the untrusted software operates.
Loading comments... Write a comment