Software Consolidation with the ARMv8-R Hypervisor

Having previously introduced the ARMv8-R architecture, it’s time to look more closely into its new technology and explain some of the benefits it will bring.  I’ll try to convey the key concepts simply but I have to assume my readers have some familiarity with ARM architecture and Cortex processors such as ARM Cortex^®-R5 processor.

The most important addition in the ARMv8-R architecture is the Hypervisor mode which provides an additional level of managed privilege within the processor hardware.  Privilege Level governs what the currently running software can and cannot do, with basic user tasks having the lowest level of privilege, i.e. Privilege Level zero or PL-0.  An Operating System (OS) typically runs with higher privilege at PL-1 and is allowed to supervise things, for example, programming the interrupt controller or configuring the attributes for regions of memory and peripheral address map to police which user tasks are allowed to do what.  Such policing is performed in a processor's hardware by a Memory Protection Unit, or MPU.

The ARMv8-R architecture specifies that an additional level of privilege, PL-2 shall be present, which is suitable for running a Hypervisor.  The Hypervisor can take over from an OS and then return to it later.  One use case example for this would be to run a real-time control task in Hypervisor mode for a safety-related application where it is necessary to be sure there is no undesirable interaction between that task and a larger OS running at PL-1.  Switching to the Hypervised real-time task would be done on interrupt and control would be passed back to the OS on completion of the control task.

However, of more significance is the use of a Hypervisor for virtualisation whereby an interrupt or event causes the context of an OS to be stored away and a different OS and high-level task set to be executed.  Each of these OSs is referred to as a guest of the Hypervisor and they each run in, what is called, a Virtual Machine, i.e. they each see their own view of the processing system as and when the Hypervisor allows them to.

In the past, virtualisation was used on campus computers where users would log in and each would think they had their own machine, i.e. a Virtual Machine.  However, the application for ARMv8-R virtualisation is somewhat different and a good example can be found in the automotive electronics sector.

If you looked under the hood and elsewhere around your car, you’ll find around 70 Electronic Control Units or ECUs, each of which is an embedded system computer running something like engine management, power steering, vehicle stability or operating electric seats and mirrors.  Software for these is usually written according to the AUTOSAR (Automotive Open System Architecture) standards laid down by a group of vehicle manufacturers, their Tier-1 suppliers and semiconductor and software providers.  This standard is intended to reduce costs in the industry by promoting software portability and re-use but it is challenged by ever-increasing complexity and the need to thoroughly test each software component and the complete system for faults which could lead to some kind of unsafe behaviour.

Vehicle manufacturers desire to make better utilisation of their ECUs and, if possible, reduce their numbers but consolidating software from different sources is problematic because of the risk of unexpected interactions between each software system (OS and task set).  You can see that virtualisation as we have it in ARMv8-R is helpful here because each software system can run in a virtual machine so long as the Hypervisor can sensibly share processing resources by time slicing or event triggering, which is frequently the case.  And just in case there is any misbehaving software around, ARMv8-R has another trick up its sleeve.

The Hypervisor has exclusive control over a second Memory Protection Unit which can only be configured when running at PL-2.  This allows the Hypervisor to isolate regions of program, data and peripheral addresses between each OS guest and task set such that the guests are ‘sandboxed’.

So, virtualisation and sandboxing are the enablers for ‘consolidation’; that is bringing together software programs from different sources, written without knowledge of each other, onto the same processor.  An example of this could be in the ECU in a power steering assembly produced by a Tier-1 supplier.  The Tier-1 would deliver the system with its software for controlling the power steering and it will be carefully tested as safe operation of a vehicle depends upon it.  More software could be added by a vehicle manufacturer, say to integrate chassis control over a Car Area Network (CAN) bus, but this must not compromise the power steering.  In a processor implementing the ARMv8-R architecture the two software systems could each run in their own Virtual Machine and strict isolation will prevent them from interfering with each other.  In this case the Hypervisor could prioritise real-time interrupts from the steering system and switch execution to it whenever necessary.

The operation of moving from one guest to another is called a context switch and it involves saving registers for the context being left and restoring registers for the context to be arrived at as shown here.

A context switch needs to happen quickly of course and the basic operation can be performed in a fraction of a microsecond, but there is another thing to be done; the MPU has to be reconfigured each time.  In order to get this done fast, the ARMv8-R architecture defines a new programming model for the MPU which allows for a simpler and more direct configuration method than was available in ARMv7-R.  This significantly reduces or even removes the need to perform any calculations that work out how to shuffle memory regions around to make best use of available memory whilst maintaining separation.  As a result, a context switch should never take more than a very few microseconds on a typical ARMv8-R processor implementation.

Moreover, ARMv8-R also accelerates the programming model for configuring and recognising interrupts with a tighter integration of the interrupt controller and processor than was done in ARMv7-R.  This means that a typical processor implementing ARMv8-R architecture should be able to respond to an interrupt in a tenth of a microsecond.  Note that a context switch is not always necessary to service an interrupt and the fastest response to an interrupt can come direct from the Hypervisor software.

Finally, there’s one last piece of 'magic' in ARMv8-R; the architecture supports both a real-time MPU as just described and it also supports a Memory Management Unit (MMU) so that guest OSs in a Virtual Machine can use virtual memory, e.g. full Linux can run.  Notice in the next diagram how each guest OS sees its own MPU or MMU as it would expect in a stand-alone situation, whilst the second-stage MPU provides for their strict isolation.  A typical memory system for Cortex-R processors will maintain determinism by using both a cached dynamic RAM for the virtual memory system (MMU) and a static RAM Tightly Coupled Memory (TCM) for the real-time protected memory system (MPU) and also the Hypervisor.

Virtualisation is controlled by the Hypervisor, so when an event occurs which requires a real-time response the Hypervisor can take over and deal with it itself, or in a real-time Virtual Machine, without being delayed by activity in the rich OS Virtual Machine such as an unpredictably long Page Table Walk if the MMU is looking up a memory page that an application has requested.  This mix of rich OS and real-time OS is new functionality thanks to the ARMv8-R technology and I believe it will lead to a whole new generation of microcontrollers running OSs like Linux but with the capability to also run an integrated real-time control and safety system, either in another Virtual Machine or in the Hypervisor itself.  MPCore configurations of this architecture are also possible with the Hypervisor scheduling workload amongst them.

Take note that ARM’s Hypervisor technology is what’s called Type-1 or ‘bare metal’ because it has specific support in the architecture and  can therefore run directly on the processor hardware in a real-time embedded system.  Other (older) Hypervisors are Type-2 (software) and these are created on top of another OS without specific hardware support.  They take much longer to switch context and do not offer such strict isolation.

I hope this has been useful and not too complicated an explanation of what’s inside ARMv8-R.  Next time, I’ll discuss some applications and you'll see why I’m excited by the prospect of our first ARMv8-R processors.

CBT