Download - Real-time virtualization – how hard can it be?

Title 44pt sentence case

Affiliations 24pt sentence case

20pt sentence case

© ARM 2017

Real-time virtualization – how hard can it be?

Felix Baum, Mentor Graphics

Embedded World

Jon Taylor, Embedded technology manager, ARM

16th March 2017

© ARM 2017 2


Bullets 24pt sentence case

bullets 20pt sentence case

Embedded virtualization

While there are many virtualization solutions available on the market, the majority were designed a while ago for single core, top-end processors and most of them were built for other markets, industries and goals:

§ Server market to move packets around

§ Desktop market to share IT infrastructure

§ Military/aerospace market to comply with standards

Mentor Embedded® Hypervisor was designed for modern multi-core SoCs for industrial and automotive devices with certification, real time and performance requirements.

© ARM 2017 3




Embedded virtualization use cases

The set of features and capabilities offered by Mentor Embedded Hypervisor is designed to address the various consolidation use cases facing device manufacturers

§ Automotive

§ Converged IVI systems and consolidated IVI and cluster architectures

§ Advanced driver assistance system (ADAS) platforms

§ Industrial

§ Integrated robotics systems

§ Payment processing platforms

© ARM 2017 4

Text 54pt sentence case Thanks for reading

For more information on real-time virtualisation visit arm.com

Sign-up for the latest news and information from ARM

© ARM 2017 5




Embedded virtualization as separation enforcement

Safety: Protecting the world from the device

Security: Protecting the device from the world

Mixed criticality: Protection of security or safety-critical parts of the device from other parts of the device

ISO26262-6 requires ‘freedom from interference’ - if two systems can interfere with each other, they must be certified to the highest ASIL level of the two.

Secure separation aims to eliminate such interference.

© ARM 2017 6




Embedded virtualization requirements

§ Type 1 (bare metal) hypervisor§ Sub 10K LOC code base§ Exploit hardware virtualization extensions for security and efficiency

§ Hypervisor with a security focus§ Strong isolation and containment of guests§ Secure-critical information & software

§ Multi-core and multi-guest enabled with flexible scheduling§ Dedicate guests to cores in a variety of configurations§ Core virtualization using priority-based, pre-emptive scheduler with round-robin time-slicing support§ Support AMP and SMP guests

§ Extensive device model – flexibility & performance§ Directly-assign devices for performance (NICs, I/O, etc.) and virtual device model (for sharing

between VMs)

© ARM 2017 7




Embedded virtualization on Cortex-R52

Unicore implementation§ Can easily support multiple unicore virtual machines (i.e. CPU virtualization)§ VMs can run RTOS and/or Bare Metal Environments (BME)

Cortex-R52 SoCCore 0 Peripherals / memory

Hypervisor

VM 2 – BME

VM 1 – RTOSEach VM has restricted

access to memory / peripherals via virtualization

extensions / HV MPU configuration

VMs scheduled on Core 0 by configured HV

scheduling policies

© ARM 2017 8




Embedded virtualization on Cortex-R52

Multicore implementation

Cortex-R52 SoC

Core 0 Peripherals / memory

Hypervisormaster

VM 2 – BMEVM 1 – RTOS

Each VM has restricted access to memory /

peripherals via virtualization extensions /

HV MPU configuration

Core 1

HypervisorSlave

MEMF MEMF

“Master” HV loads / starts all “Slave” HV

images

HV images communicate using IPC provided by

MEMF VM 3 – RTOS

VMs scheduled on any virtualized core by

configured HV scheduling policies

© ARM 2017 9




Embedded virtualization on ARMv8-A

Multicore implementation§ Traditional hypervisor can run SMP across all managed cores§ VMs can support SMP or UP guests§ VMs can support all OS types

Cortex-A SoC

Core 0 Peripherals / memory

Hypervisor

VM 2 – BME

VM 1 – SMP Linux

Each VM has restricted access to memory /

peripherals via virtualization extensions HV MPU configuration Core 1

VM 3 – RTOS

VMs scheduled on any virtualized core by

configured HV scheduling policies

© ARM 2017 10




Embedded virtualization: Device models

Driver model: Direct§ The guest owns the device§ Driver in the VM controls device§ Recommended model§ Fastest, native performance

Driver model: Shared§ One of the guests owns the device§ Driver in that VM controls device§ The rest of the VMs share the device§ Helps to keep hypervisor code small

Driver model: Virtualized§ Hypervisor owns the device§ Driver in hypervisor controls device§ Each VM owns a second level driver§ Hypervisor provides data assurance

© ARM 2017 11




Embedded virtualization: Beyond toolchain

Debug support – JTAG and agents need to be supportedSoftware tracing and analysis via agents with synchronized data support

© ARM 2017 12




Hard real-time requirements

Will the system meet its deadlines?

What happens if an error occurs?

How much does worst case performance vary?

Determinism

© ARM 2017 13




Cortex-A and hard real time

Cortex-A - system and software designers have to consider carefully:

§ MMU page table walks can take 1000s of cycles

§ Cache warmth can affect determinism

§ Memory mapped access to GIC§ Can depend on other bus traffic

§ Peripherals share memory bus

Cortex-R52 - hardware provides more features for hard real-time:

§ MPU always takes single cycle to check permissions

§ TCMs can be used to guarantee single cycle memory access

§ System register access to GIC§ Guaranteed single cycle access

§ Low latency peripheral port

© ARM 2017 14




Hard real-time and virtualization

§ Cortex-R52 is the first ARMv8-R processor, bringing together hard real-time and virtualization

Complete OSs and tasks can be virtualized

Cortex-R52

Safe task A

Task D

Task C

Safe task B

Monitor / hypervisor

RTOS RTOS

© ARM 2017 15




14x faster MPU reconfiguration for spatial separation

§ Real-time software separation at OS level is feasible with faster context switching

§ Cortex-R52 can switch a whole OS as fast as Cortex-R5 can switch a task

§ OS switch similar to task switch but with more state to save/restore

§ New ARMv8-R programming model supports flexible size and alignment of MPU regions

MOV r0,#0

MCR RGNR,r0ISBMRC r1,DRACRMRC r2,DRBARMRC r3,DRSRSTM r4!,{r1-r3}ADD r0,r0,#1CMP r0,#16BNE loop

x16

1

6

8

6

6

6

3

1

1

08

601 cycles

MRC r1,PRBAR0MRC r2,PRLAR0MRCMRC

r3,PRBAR1

STM r5!,{r1-r4}

MRC r1,MAIR0MRC r2,MAIR1STM r5!,{r1,r2}

x8

1

1

0

3

1

1

2

44 cycles

r4,PRLAR1

0

ARMv7-R (Cortex-R5) ARMv8-R (Cortex-R52)

© ARM 2017 16




Timing separation adds to freedom from interference

RTOS A

Timer (t0)

Timer (t1)

Interrupt taken to Hyp

RTOS B

Timer (t2)

Slack

Timing not to scale

OS switch

System Event

OS switch

≈ ≈ ≈

RTOS tick handler

RTOS task switch

Overrun due to system event in previous tick

© ARM 2017 17




RTOS A

Timer (t0)

Timer (t1)

Interrupt taken to Hyp

RTOS B

Timer (t2)

Slack

Timing not to scale

OS switch

System Event

OS switch OS switch

RTOS A

Regular RTOS context switch

And resumption of task

≈ ≈ ≈

Overrun now resumed

Timing separation adds to freedom from interference

© ARM 2017 18




Interrupts in multi-core Cortex-R52 systems

SoC

L2GIC Distributor

CPU Core 1

GIC CPU Interface

CPU Core 0

Hypervisor

IRQ

Guest OS

Interrupt routing

AX

I (mem

mapped)

Control registers

Hardware Interrupts

FIQ

GIC virtual CPU Interface

GIC CPU Interface

Hypervisor Guest OS

Interrupt routing

FIQ vFIQ

GIC virtual CPU Interface

IRQ

Guest OS

vIRQ vFIQ

Gp 0 Gp 1Gp 0 Gp 1

© ARM 2017 19




Building a complete system

ASIL BASIL D

Cortex-R52

Memory Peripherals

Hyp Hyp

RTOS RTOSBME

Task Task

TaskTask Task

Task

Peripherals

Software

Hardware

© ARM 2017 20




Conclusions

§ Virtualization is a key tool for managing growing complexity of embedded systems§ Consolidation of software from multiple sources onto a single processing platform§ Maintaining separation and therefore freedom from interference§ Fulfilling key requirements in safety-related and/or security applications

§ Hard real-time deadlines impose additional requirements§ Type-1 (bare metal) virtualization is required§ Hypervisors will be written to make best use of the hardware platform

§ ARM Cortex-R52 processor provides new capabilities to enable hard real-time virtualization

The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners.Copyright © 2017 ARM Limited

© ARM 2017

Meet the experts – Felix and Jon will be answering questions on the ARM stand (Hall 3, stand 342) at 2pm today

Download - Real-time virtualization – how hard can it be?

Top Related