BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY IN SYSTEMS

Hypervisors and Virtualization

What Software Strategy Makes Best Use of Multicore Processors

With the rise in availability of multicore embedded processors, especially those offering virtualization support, it is likely that the embedded world will follow the enterprise world and embrace the use of virtualization.

BY ROBERT DAY, LYNX SOFTWARE TECHNOLOGIES

  • Page 1 of 1
    Bookmark and Share

Article Media

It’s becoming more and more difficult to buy a single core 32-or 64-bit processor, and given that most embedded systems have traditionally run on single core processors, what happens when it’s time for a hardware refresh ? This really comes down to a software decision and typically a decision on what sort of platform software should be used to make the best of the new multicore hardware.

The first option to consider is using a real-time operating system that supports multicore processors. This RTOS would seamlessly run the application code over the different processors using a symmetric multi-processing (SMP) scheme. The scheduling and management of the multiple cores is left to the RTOS and the developer often has very little to do to enable the extra processing power now given to him.  The issue really becomes the ease of portability of legacy software applications, and how easy it will be to bring these applications over to a new SMP RTOS running on a multicore processor (Figure 1). Coding in high level languages helps a little, but even more so does using an open standards RTOS API like POSIX, and now there are even OS conversion programs that help move applications written for one RTOS API to another. But the porting of the code is just the start. Because embedded systems often have quite stringent and precise system characteristics much of the porting time is spent testing and verifying that the system still operates as required.

Figure 1
SMP RTOS controls CPUs, Memory and Devices

So, is there an alternative to moving to an SMP RTOS ? A possible alternative is to use an embedded virtualization solution, such as an embedded hypervisor, to help maximize the multiple cores and often other new features of the new generation of multicore processors (such as 64-bit addressing). There are a number of interesting benefits to using virtualization in an embedded system, and the advent of multicore processors really brings some of them to the forefront, especially when compared to using an SMP RTOS.

Virtualization effectively allows users to run multiple operating systems on a single hardware platform, and has been widely used in the enterprise market to run multiple and often different operating systems and their applications on a powerful server platform. This allows the use of legacy operating systems running in virtualized environments on modern hardware platforms that they wouldn’t normally be able to run on. On desktop systems virtualization allows users to run multiple different OSes on a single hardware platform, for example running both Windows and MacOS on a Mac.

In the embedded world this same approach can be taken, both to run legacy operating systems, and also to run multiple different operating systems on a single platform. The use of both approaches can lead to some very interesting time and cost savings for embedded developers as they build the next generation of embedded systems using modern multicore processors. First, the virtualization of legacy operating systems can really help the migration of embedded software systems to modern hardware platforms, by providing a ‘virtual’ motherboard with processor, memory and devices presented to the legacy software as if it were a real embedded system.

This approach greatly simplifies a couple of often costly and time consuming tasks in the migration of legacy software. First, an RTOS will usually need to be migrated to a new hardware platform, needing a newer version of the RTOS and usually a new board support package (BSP) to go with it. This can often take significant time and money, and then the applications will need to be moved to and tested on the new version of the RTOS—again a time consuming task. Using virtualization the old version of the RTOS and the applications can be picked up and dropped into the virtual environment, often using virtualized devices to even allow the re-use of the existing BSP, and thus moving straight into more of a testing and verification phase. If we combine this approach with the other virtualization technique of running multiple operating systems on multiple virtual motherboards on a single hardware platform, we can start to unleash the power of multicore processors.

Many embedded system refreshes are done to accommodate feature requirements in the embedded system, maybe more or different connectivity options or a change in GUI. This requires new software to be written and added to the legacy software. This can become quite a challenge if the legacy RTOS has limited connectivity options or dated GUI functionality, and bringing it up to modern standards can be costly. Using virtualization, the legacy software can be left relatively untouched, and housed in its own virtual environment while new functionality can be added in another virtual environment, maybe with a more modern operating system. This can also ensure that the best OS is being used for the different functions in the system, for example using the legacy RTOS for the real-time part of the system and using a more full-featured OS for the networking and GUI aspects. There would need to be a communication mechanism between the operating systems, but this could be relatively simple and is usually well handled by the virtualization software. Each virtual environment could have a dedicated processor core, and in the case of the full featured OS, maybe have more than one physical core dedicated to it to help the processor load of GUI or networking. As there is no processor core sharing between the OSes, the real-time performance of the RTOS won’t be compromised by the full featured OS as it churns through its graphics, network or storage functions.

Another interesting spin-off from this virtualization strategy also helps with the migration from 32-bit to 64-bit, as the embedded applications start to crave the memory and performance that we associate with our modern computers and phones. Running a legacy 32-bit operating system won’t be able to take advantage of the increased memory addressing of a 64-bit processor, even when virtualized. However, running multiple 32-bit OSes on a 64-bit processor will be make it possible to allocate the extra addressing in 32-bit chunks, and effectively allow more memory spread over the different virtual machines. This could be a very cost effective way of adding extra functionality and memory usage without having to move to a brand new 64-bit OS.

This is a particularly interesting strategy as we look at certain key embedded processor architectures. The ARM architecture (and specifically the Cortex-A family) has largely been a single-core, 32-bit architecture without hardware virtualization functionality. So, typically one would run 32-bit, non-SMP RTOSes, or variants of Linux and Android, if GPOS functionality is required. Some of the latest processors based on members of the Cortex-A family are now moving to multicore (Cortex A9 for example), or introducing multicore with virtualization support (32-bit Cortex A15 and A7, and 64-bit Cortex A53, A57 and A72). The former case requires a strategy for SMP RTOS, or potentially the use of a hypervisor in the latter case.

Porting the legacy RTOS code to these new multicore Cortex A9 processors could be a tricky undertaking if the legacy RTOS has not introduced a multicore scheduler. This might propel developers to look at using an ARM-based processor that has virtualization support to run the existing 32-bit RTOS in a virtual machine, and add new functionality by adding other operating systems and code in separate virtual machines. This helps preserve the legacy functionality, and allows new features to be added without dramatically affecting the legacy code. It also allows a relatively painless migration from a 32-bit world to a 64-bit world without having to dramatically invest in new RTOSs or new code. In the connected embedded or IoT world this is also often an easy way to add new connectivity, by having a VM that specifically looks after the network(s), and the other VM that focuses on the embedded tasks. This not only allows for new network connectivity to be added relatively easily, but also brings in another key factor, the separation of devices.

As discussed earlier, virtualization can provide a number of virtual motherboards, each running their own OS and applications. The devices that are provided in each virtual motherboard can differ from one another and can contain a mixture of virtual or physical devices. As a Memory Management Unit (MMU) on a processor divides up memory and protects the different memory regions for the different applications, an IOMMU does the same for IO devices for different virtual machines. If, for example, you want to have the network device only accessible to the network VM, then you program the IOMMU to restrict network device access to that network VM. The other VMs on the system cannot see or reach the network device, and it doesn’t appear on their virtual motherboard. This provides the separation between VMs, and in the world of IoT where the network is the attack vector for cyber threats, the embedded code and data can be protected and separated from those threat points. If, however, you want to have the network shared between different VMs, then you can use the hypervisor to set up virtual devices. The hypervisor controls the physical network interface, and then provides multiple virtual network interfaces to be available on the virtual motherboards as required. Virtualization can therefore provide a very flexible way to split up an embedded system from processor cores, memory and devices and then present them to the ‘guest’ operating systems that are running in the virtual machines.

Figure 2 shows an example where a four-core processor is split into three virtual motherboards. The first virtual motherboard runs an RTOS to run the legacy real-time applications. The second is running a general purpose OS (GPOS), in this case Linux to deal with the networking and storage aspects of the system, and uses the IOMMU to dedicate the networking and storage devices to this GPOS.

Figure 2
SMP RTOS controls CPUs, Memory and Devices

The increasing use of multicore embedded processors, especially those offering virtualization support is spurring the embedded world to embrace the use of virtualization. This can provide a very efficient use of the processor cores and devices, help maintain legacy code, and also to help introduce better security into our connected embedded world.

Lynx Software Technologies
San Jose, CA
(408) 979-3900
www.lynx.com