The idea of using a hypervisor in a powerful computer is well known. It facilitates the simultaneous use of multiple operating systems and provides a virtualized environment in which unmodified legacy software can be deployed. Hypervisors also have their place in modern embedded systems. This article considers the characteristics of an embedded hypervisor, the functionality it can provide, and some typical applications.
Some technologies shouldn't really exist. However, they do so because they serve a specific need. Often such techniques stretch something to make it perform in ways that were not originally intended. A fax machine is an example. In a paper office environment, there is often a need to move documents from A to B. Initially, this resulted in the creation of mail. But faxing is a neat way to use phone lines to produce similar results. Faxes disappeared almost overnight after email became commonplace. Domestic broadband is another example – ancient copper wires are used to deliver digital connections at speeds that were considered downright impossible just a few years ago. Hypervisors are another "shouldn't exist" technology that has taken hold in the world.
What is a hypervisor?
Broadly speaking, a hypervisor is a software layer that enables multiple operating systems to run concurrently on a single hardware platform. They have been used for decades on mainframes and more recently on desktops, but are now starting to become very relevant to embedded developers.
Hypervisors aren't really new technology - the first recognizable products were introduced on mainframe computers about 50 years ago. The motivation then was to make the best use of expensive resources. Efficient use of expensive hardware is required to be fully economical, and downtime is expensive. Software investments need to be protected, so facilitating seamless execution on new hardware is attractive. Ironically, IBM's early virtualization software was distributed in source code (without support initially) and modified/enhanced by users. It was many years before the concept of open source was conceived.
In the context of modern embedded systems , remember what are the benefits of running multiple OSes on one piece of hardware? The most important answer is security. The hypervisor provides a very strong layer of isolation and protection between the guest operating systems, ensuring that one multi-threaded application cannot interfere with another. IP reuse is a secondary but still very important motivation for running multiple operating systems. Imagine you want to use some important Linux software IP in your design. However, your device is real-time, so an RTOS makes more sense. If multicore isn't an option (as that's another way to run multiple operating systems on one device), using a hypervisor is the way forward so you can run Linux and RTOS.
virtual
Types of Hypervisors There are essentially two types of hypervisors, imaginatively named Type 1 and Type 2. Type 2 requires an underlying host operating system. For embedded applications, Type 1 makes the most sense for most applications.
Multicore – SMP and AMP
Statements about a hypervisor enabling multiple OSes on a single hardware platform imply that means one processor. In fact, many products support the use of multiple CPUs and allocate resources through the hypervisor. Exploring this further requires a little consideration of multicore basics.
From a software perspective, there are essentially two types of multicore architectures: symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP). With SMP, it is possible to run a single operating system on all CPU cores, which must have the same architecture. Operating systems need to be specifically designed to run in SMP systems. In an AMP system, each CPU runs its own OS (or none at all). CPUs don't have to have the same architecture.
Hypervisors and Multicore
All embedded systems have finite resources that need to be managed. It can be said that this is the key to embedded software development. For the sake of discussion, we will consider a hypothetical example system with a single serial port. Depending on the configuration of the software and CPU hardware, this port can be managed in various ways.
On a single-core system, the operating system can manage access to the serial port and can arbitrate between multiple tasks that might want to use it. There are many ways to do this, and here's the easy way to do it.
If the system has multiple identical cores, it may be useful to configure it as an SMP (single OS instance running on all cores). SMP versions of many RTOS products are available (such as Nucleus), and Linux with SMP support is also an option. This method is ideal if the application benefits from the OS being able to allocate CPU power as needed. The operating system can manage access to serial ports in much the same way as on a single-core system.
On many systems, SMP is not attractive because more precise control is required, or the system has so many cores that performance may suffer. Elsewhere, SMP is out of the question since the cores are not identical. In these cases, it makes sense to have an AMP configuration with separate OS instances on each core. This presents a challenge: how do you manage a single serial port?
If all cores in the system are suitable for running a hypervisor, it can be run on all cores, and each core's operating system is considered a "guest". Access to the serial port can then be managed by a hypervisor.
If one or more cores cannot run a hypervisor (because they are lower performance processors), another option (for example, Mentor Embedded's Heterogeneous Multicore Framework HMF) can be used. This facilitates management of smaller cores by a hypervisor running elsewhere (on a more powerful CPU on the same chip). Thus, the hypervisor can manage access to serial ports by all cores in the system (whether running the hypervisor or HMF).
Embedded Hypervisor Applications Embedded Hypervisor can
Find your place in three application areas:
Automobile industry
industry
the medical
car
In this case, infotainment software, dashboard controls and telematics might all run on a single multi-core chip. Since there may be a need for a mix of operating systems such as RTOS for instrumentation and GPS and Linux for audio, a hypervisor makes perfect sense.
industry
For industrial applications (factories, mines, power plants, etc.), real-time control (RTOS) and complex networking (Linux) are often required. Also, in recent years there has been increased concern about cyber attacks or the introduction of malware into control systems. Hypervisors are an ideal way to separate systems and maintain security.
the medical
The healthcare system presents some new challenges. Often, there is a mix of real-time (patient monitoring and therapy control) and non-real-time (data storage, networking, and user interface) capabilities, so hypervisors initially look attractive. The confidentiality of patient data is paramount, so the security of management procedures becomes important. Finally, the ability to completely separate the parts of the system that require authentication (usually the real-time part) makes hypervisors attractive.
Embedded Internet of Things needs to learn a lot. Don't learn the wrong route and content, which will cause your salary to go up!
Share a data package with everyone, about 150 G. The learning content, face-to-face scriptures, and projects in it are relatively new and complete! (Click to find a small assistant to receive)
