Let me be clear, as an embedded software product manager for Mentor Graphics, I believe there are numerous use cases in which architecting a safe, secure, and reliable Type 1 embedded hypervisor is the best way to go. Not only that, but a hypervisor built on top of Trusted Execution Environment (TEE) and ARM TrustZone technology is by far, the safest route to take.

If your embedded design requires security and robustness or dual GPOS/RTOS performance, I would argue that virtualization might be in your best interest.

However, there are some cases where virtualization might not be necessary. These include situations where you aren’t using multiple operating systems; there are as many operating environments as there are cores in your design; or separation or security is a must, but you only have two cores and two contexts.

In the first case, there are plenty of devices that can meet design requirements with a single operating system running in a synchronous multiprocessing (SMP) configuration. With Linux (for example), you can rely on the Linux scheduler to properly manage the tasks and processes among the available cores. And running application code within the Linux user space would help to provide reliability and separation of the application code and the kernel.

In the next scenario, if, for example, you only have two cores and you need to run two bare-metal- or RTOS-based applications, deploying your design without a hypervisor will provide you with the best (native) performance. It would be even more beneficial if the operating environments running on separate cores were:

• Easy to configure – Since the memory map, peripherals, and resources need to be carefully split between payloads, the payloads need to allow for full customization. Having access to fully buildable source code is a big plus.
• Preventable from dynamic resource allocation – Some operating systems on the market today are almost impossible to prevent from dynamically enumerating the hardware resources.
• Not required to share resources – If any of the hardware resources need to be shared between operating environments, you only need to either modify one of the payloads to manage the hardware resource and provide services to the application running on the other core (which violates separation/safety/security guidelines) or go to the hypervisor-based architecture.

I’ve worked with customers who have tried to deploy Linux and bare metal side by side. Requirements for these devices called for deploying Linux that owned most of the peripherals – and one or two of the peripherals had to be mapped to the secondary core with NO sharing allowed! One solution is to partition a system using ARM TrustZone features of the dual-core ARM Cortex-A9 device. Linux is assigned to run in “normal world” on one core and the bare metal application (no OS needed) is assigned to run in “secure world” on the other core. Peripherals mapped to the secure world were invisible and protected from Linux. The figure below depicts the isolation between applications and hardware resources in the TEE-based configured system architecture.

Utilizing the ARM TrustZone technology through normal world and secure world partitioning.

The consideration of system architecture and whether to deploy a hypervisor is a complex one involving many factors. In addition to looking at the hardware features, you must also look for a reliable software vendor who doesn’t dictate how you should build your device and allows you to make choices by providing flexible and configurable source code with options to deploy operating systems natively.

There’s more information about when to use a Type 1 embedded hypervisor on the Mentor Embedded Hypervisor website. While development teams would like to have a seamless upgrade path from an RTOS-based device to one that incorporates Linux, they’re having a difficult time deploying without some type of virtualization. Today, many teams want to take advantage of the ARM TrustZone features and leverage the Linux ecosystem while preserving their legacy investment in real time where one core runs, for example, on Nucleus RTOS. The other core might run a GPOS such as Mentor Embedded Linux, which allows for integration of a broad set of third-party IP developed by the OSS community. In many designs, both OSs need to communicate and share resources while relying on TEE environment for secure boot, encryption, digital rights management (DRM), and other secure and sensitive applications.

Felix Baum is a Virtualization Solutions Product Manager of the Mentor Embedded Systems Division at Mentor Graphics.