In networking applications, primarily using multi-core devices, there are considerable advantages in virtualization.  For example virtualization allows for considerably more efficient load balancing as it is now possible to move virtual machines, and their hosted process, from core to core dynamically as conditions change. This same mechanism can drive power savings as it’s now possible to consolidate processing on fewer cores during low traffic periods and shut down unused cores. Higher up-time is possible as it is now possible to download updated firmware in the background, validate the new image, and then migrate process to the new firmware, all without taking the system off line. In systems where it’s necessary to support many different firmware versions this capability is enormously compelling.

 

In highly secure environments it is now possible to add a secure processing element to an SOC, without having to have a separate security processor. The Payment Card Industry Pin Entry Device (PCI-PED) certification imposes an extremely rigorous set of requirements on manufacturers from the standpoint of separating the user interface from the pin entry device.  With virtualization what had previously required two devices, can now be accomplished with a single physical device, with a hypervisor hosting multiple secure execution environments, one for the user interface, and one for the pin entry device.

 

In applications where there is a concern about how best to preserve proprietary IP, and still get the benefit from using open source code released under GPL, virtualization provides a way of isolating those two domains.  Integrate GPL code with your proprietary IP, and under the terms of the license, you have to release the full source.  With virtualization it’s now possible to compartmentalize the GPL code, and control the amount of proprietary code that must be released to the public.  (http://www.trango-vp.com/dynamic/front_downloadFile.php?fileName=TGO-TEC-0340-TRANGO_GPL.pdf registration required)

 

There are numerous ways of creating virtual machines for embedded applications. While just assigning a name to a particular approach does very little to illuminate the critical issues, it is important to understand the foundation upon which a product design is undertaken as it quite often has substantial impacts on the design’s final character. 

 

We’ve labeled the most typical approaches to virtualization that we run across in our day to day work as microscheduler, microkernel, and ‘nanokernel’ (I’ll explain the quotes later).  After a quick once-over of each approach I’ll try to focus on key attributes that customers should be aware of.

 

In a microkernel, an OS kernel is stripped down to its bare essence by removing services that are not strictly required to allow the microkernel to run.  This leaves thread management, interprocess communications, scheduling, and address management.  Hooks and catches are then put in place that allow designers to add those services at a user level.  What this means in practice is that the user mode/kernel mode separation is maintained so a high level of security and robustness is similarly achieved.  But, due to the nature of the originating kernel architecture, there are architectural preferences in the nature of the hosted OS.  In other words, a Linux derived microkernel will have an affinity for hosting Linux as a guest OS.

 

A microscheduler is a closely related approach to that of a microkernel but while the scheduling portion itself runs in kernel mode or the highest privilege level of the system as is the case with a microkernel, at the same time guest operating systems are also allowed to run at this same extremely high privilege level.  What this means in practice is that the guest operating system must be well behaved both from a performance and a security perspective.  This partially eliminates one of the key strengths of virtualization; security.  Robustness is also compromised as a crash on the part of a privileged guest OS or application can still do extensive damage as it’s running “bare metal” and able to bypass protections that are available in a fully virtualized processing environment.

 

Another approach to creating a hypervisor, is to create a hardware abstraction layer or HAL, and add services such as time management, memory management, and interprocess communications to make a useful hypervisor.  “Nanokernel” is a term that I use with some fear and trepidation as it seems that the word was coined more to separate more modern and streamlined microkernel implementations from first-generation implementations such as “Mach.”  While the term may be imprecise, it will have to do until a more precise way of describing this approach comes along.  “HAL-Like” really doesn’t do it justice and, full disclosure, this is the approach that Trango subscribes to.  The key practical difference in this approach and that of typical microkernels is this; as the basis for the creation of the HAL is the underlying SOC, rather than an OS port that just happened to target that SOC, the hypervisor is typically thinner and lighter, and the hypervisor is less ‘picky’ about the specific details of a hosted OS.  In other words, as an approach it tends to be more OS agnostic and a better reflection of the underlying hardware.

 

The good news is that there are lots of good choices out there, and the technology has enormous capabilities.  It’s all a matter of looking at the CPU as one of many virtual devices rather than as unitary and fixed and of keeping an eye out for applications for embedded device programming’s newest tool.