Isolation and Virtualization

for Real-Time Cores

Janna Garofolo, Global Automotive Applications Director
Marius Rotaru, Chief Software Architect and Fellow
George Ciusleanu, RTOS and Hypervisor Software Architect

18.04.2024

| Public | NXP and the NXP logo are trademarks of NXP B.V. All other product
or service names are the property of their respective owners. © 2024 NXP B.V.
 Agenda

Challenges with New Vehicle Architectures

Software-defined Vehicles & S32 CoreRide

S32Z/E Isolation and Virtualization

Overview

Isolation and Hardware Virtualization Mechanisms

Hypervisors Solutions for Real-time Cores

Partitioning Hypervisor (NXP EL2 Monitor)

Micro Hypervisor (L4Re Micro Hypervisor)

Demo and Conclusions

2 | NXP | Public 2 | NXP | Public

Trends Software-defined
vehicles

through software +
hardware integration Portable healthcare
and biotechnology
New levels of performance
Wearable Game streaming
across industries
technologies
Augmented
Computing Smart home virtual reality
devices
Smart phones AI and machine
Gaming consoles learning accelerators
Networking
equipment

3 | NXP | Public
Vehicle transformation underway

From hardware-oriented vehicle To

vehicle
Function

Function

Function
Function
Function

Function
Function
Function
Function
Function

Function
Function

Function

Functions tied to ECUs Functions can be anywhere in the vehicle

Static architecture Flexible architecture
Exponential increase in complexity Simplification of implementation

4 | NXP | Public
Integration

Separate integration efforts for every ECU

Automakers must
navigate mounting
ECU 1 ECU 2 ECU 3 ECU 4 ECU 5 … ECU X
software and hardware
SW SW SW SW SW SW

ECUs contain 10s to 100s of hardware HW HW HW HW HW HW

and software components
Discrete ECUs require separate
integration efforts of hardware
and software
Integration effort exponentially
Features and variants drive increases with more ECUs
complexity

5 | NXP | Public
Scalability

Multiple vehicle classes Flat Domain Clustered Full

and architectures
Domain Centralized

Multiple E/E architecture types

evolving with different configurations,
performance, and memory Flat Hybrid Full Zonal Distributed
requirements Zonal Zonal Zonal

Different vehicle classes drive many

combinations of features and ECUs
• ~25 ECUs in low end up to
~150 in high end classes

6 | NXP | Public
Introducing Tightly integrated software and hardware

Applications Focus on
differentiation

Middleware, OSes,
Leading Drivers
partners

S32 Discrete HW
Reduce complexity

platform CoreRide
platform
components Maximize system
performance

Open with Central Compute Scalable hardware

unprecedented
combination of scale Zones

and integration, Energy Networking S32K1 S32M2 S32K3 S32R S32Z/E S32G S32N
paving the way to a Management

S32 compute
new era of SDV
development CAN & LIN 10 Mb  → 10 Gb
Ethernet PHY & switch

Networking

System power management

7 | NXP | Announced by NXP March 28, 2024, 9 am CET |

Reduce development complexity and break through integration barriers

Traditional Development

OEMs & Tier-1s App (vehicle functions)

App App App App App

OEMs & Tier-1s

App software decoupling from base

Middleware
Software providers
& Tier-1s
OS Integrated base of
software and hardware

Middleware Software
ecosystem
OS & Tier-1s
Drivers Open Software
Ecosystem, Tier-1s, Drivers
Processing NXP S32 Processing
Semi makers and networking
Networking
System Power
Management
Power management

8 | NXP | Announced
Public by NXP March 28, 2024, 9 am CET
NXP S32 CoreRide Platform
Enables safe and secure ECU consolidation

with pin-to-core isolation

Consolidate ECUs and reduce integration efforts
Traditional architecture
One super
consolidated ECU

ECU 1 ECU 2 ECU 3 ECU 4 …

App 1 App 2 App 3 App 4 …
App 1 App 2 App 3 App 4 …

SW SW SW SW SW

HW HW HW HW HW Middleware Software
Open software OS
ecosystem
& Tier-1s
ecosystem, Tier-1s,
Drivers
NXP
Multiple ECUs and integration efforts S32 processing
and networking
System power
management

Mixed criticality: QM to ASIL-D Isolation execution environment

Multiple OSes across applications for freedom of interference
9 | NXP | Public
 Agenda

Introduction
Challenges with New Vehicle Architectures

Software-defined Vehicles & S32 CoreRide

Overview

Isolation and Hardware Virtualization Mechanisms

Hypervisors Solutions for Real-time Cores

Partitioning Hypervisor (NXP EL2 Monitor)

Type1 Hypervisor (L4Re Micro Hypervisor)

Demo and Conclusions

10 | NXP | Public 10 | NXP | Public

NXP S32 CoreRide Platform for Zones

NXP Extends S32 Automotive Platform with its

S32Z/E Real-Time Processors for New Vehicle
S32Z/E Architectures

• S32Z/E Real-Time high-performance processors

accelerate and consolidate real-time
applications for safety, domain and zonal
architectures

• Creates new class of processors offering real-

time behavior of microcontrollers with
unparalleled gigahertz performance and
integration

• Offers scalable, 16nm S32Z and S32E families with

roadmap to S32N5 (5nm solutions)

11 | NXP | Public
S32Z/E - Key System Design Principles

• Minimise para-virtualisation
Architecture supports • Integrate partitioning with safety and security features
partitioning/virtualisation • Optimise QoS when allocating partitions
from processor core-to-
• Provide virtualization-awareness and dedicate modules
pin
to partitions

• Gather co-operating hardware modules in autonomous

Optimise the architecture blocks
for best performance in
• Provide multiple copies of commonly used modules
16 nm technology
• Optimise QoS for “general purpose” features

12 | NXP | Public
13 | NXP | Public
= Features added from the S32Z2
S32Z/E Virtualization and
Isolation Capabilities

14 | NXP | Public
Cortex®-R52 Core

The Cortex®-R52 is a member of ARM®’s Cortex®-R real-time profile

architecture, and supports:
➢ Three exception (privilege) levels
• EL0 for tasks and untrusted software
• EL1 for OS kernels and trusted software
• EL2 for hypervisor and virtualization software
Source:
https://developer.arm.com/Processors
➢ Two MPUs, each with 20 regions and 64 bit granularity to protect
memory accesses when in EL0, EL and EL2.

➢ Functions and controls only available to software running at EL2.

• This includes control of the MPUs, configuration of the interrupts and
control of the Virtual Machine Identifier (VMID)

➢ Interrupt Virtualization Support

• Integrated Generic Interrupt Controller (GIC) with the ability to signal
both physical and virtual interrupts.
15 | NXP | Public
Arm, Cortex are trademarks or registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets.
All rights reserved.
 S32Z/E - Partitioning and Virtualisation Support Features

Co-processor sharing VMID/EVMID

Multiple-access points EL2-controlled MPU
Internal isolation Virtualised interrupts
Shared resource configurability DMA channel spoofing
QoS on LPDDR GTM cluster identifier
Peripherals CPU and Bus
and Memory Masters

Interconnect
Hardware firewall
Configurable access control policies
Shared access
Independent safety response
16 | NXP | Public + Fault awareness of partition
S32Z/E - Physical Architecture Optimised for Performance

Cores and clusters are

Cluster Core
Cluster grouped with memory and Core
Watchdo
base peripherals
Watchdo
g Watchdog
Timer General purpose peripherals g Watchdog
Timer
Timer
Fault unit
Fault unit
are grouped with DMAs Timer
Fault unit
other Fault unit
other
RAM other RAM
RAM RAM
other

DMA
DMA DMA
DMA

LIN LIN
LIN LIN
Timer Timer
Timer Timer
Zipwire Zipwire
Zipwire Zipwire
CAN-XL CAN-XL
CAN-XL FlexRay
GPIO GPIO
GPIO GPIO
17 | NXP | Public
S32Z/E - Virtual Architecture Optimised for Functionality

Memories and peripherals are logically

Watchdog
Core in Watchdog partitioned according to application Core in
Timer
Cluster Timer
need. Cluster
Fault unit Fault unit
other Partition provides protection, fault RAM other
RAM
LIN handling and bandwidth DMA
DMA
DMA FlexRay
DMA Zipwire Resource Grouped by
CPU Virtual machine (VMID)
Memory Regions configured by size and
VM in Watchdog access policy (16 for every VM in Watchdog
Timer block) Timer
Cluster Cluster
Fault unit Simple peripherals Whole peripheral Fault unit
other (LIN/SPI/Timers etc) other
RAM RAM
DMA Individual channel
Timer Timer
GPIO Individual pin
CAN-XL CAN-XL
DMA
DMA Ethernet 8 independent ports DMA
DMA
DMA GPIO DMA GPIO
CAN Whole module or offload to
FlexLLCE
GTM Individual cluster
18 | NXP | Public
LPDDR Individual access slot
 S32Z/E - Secure Resource Isolation using XDRC

• Extended Resource Domain Controller manages access control, system memory

protection and peripheral isolation.

• Applications co-exist on the

same silicon with an absolute
firewall between them.

• Enforces absolute freedom

from interference by permitting
software to sandbox resources
within robust processing
domain.

19 | NXP | Public
S32Z/E – Peripherals with HW-Assisted Virtualization Support
(Examples)

App. Core / App. Core /

VM VM

HIF DRV HIF DRV

App. Core / App. Core /
VM VM

HIF DRV HIF DRV

H/IF H/IF H/IF
Security
Fuses RAM ROM
Eth Ctrl Eth Ctrl Eth Ctrl Eth Ctrl Monitor
Job Ring I/F

DMA
Core Job Queue
Ethernet Switch Controller
(TSN & TC11)
Descriptor

RTIC
NETC Controllers
Ethernet Ports
(PK)

RNG4 MDHA AESA DESA

Ethernet
frame TX HSE

Ethernet Accelerator Automotive Comms Engine Hardware Security Engine

20 | NXP | Public
 Agenda

Introduction
Challenges with New Vehicle Architectures

Software-defined Vehicles & S32 CoreRide

S32Z/E Isolation and Virtualization

Overview

Isolation and Hardware Virtualization Mechanisms

Partitioning Hypervisor (NXP EL2 Monitor)

Type1 Hypervisor (L4Re Micro Hypervisor)

Demo and Conclusions

21 | NXP | Public 21 | NXP | Public

Virtual Machines and
Hypervisors

22 | NXP | Public
 Hypervisors Overview

A Hypervisor (also known as Virtual Machine Monitor) is a software

system that allows a CPU to run more than one guest (also known as
Virtual Machine)

A Hypervisor typically provides the following primary features:

• Scheduler to switch between active guests
• Management of guest state
• Isolation of guests
• Various privilege requests from guests – normally called “Hypercalls”
• Virtualization of interrupts
• Inter-guest communications (a guest can be an OS such as AUTOSAR OS or FreeRTOS)

For a Hypervisor to operate effectively in a system, it requires:

• A Core which provides support for virtualization
• A SoC which provides support and protection across multiple cores and other bus masters
23 | NXP | Public
Peripheral Virtualization Options

Usage recommendation:
• Direct assignment whenever the devices are not required to be shared among VMs
• HW-assisted virtualization when available. Minimum performance degradation vs direct assignment
or native setup
• Para-virtualization for sharing devices whenever direct assignment or HW-assisted virtualization
cannot be used.
• Full emulation when the above techniques cannot be used or when the HV ecosystem already
supports it.
24 | NXP | Public
Why Do We Need a Hypervisor for real-time cores?

Reduce System Cost

Consolidates functions and drastically reduce the
number of ECUs, the number of wiring harnesses

Optimize resource utilization

Optimizes the usage the computational power of the cores,
allowing an efficient consolidated of various application
during the time

Provide Safe and Secure Isolation

Integrates Mixed-criticality applications from different
supplier, ensuring intellectual property protection between
development partners.

Reduce homologation effort

Isolates the part of the software that must remain unchanged

Ensure future-proof development

Safe update of an application, safe addition of new applications
25 | NXP | Public during the time, without impacting the existing ones
S32Z/E Partitioning
Hypervisor (EL2 Monitor)

26 | NXP | Public
 S32Z/E - Hypervisor Solutions

VM1 VM2 VM3 VM4

• Partitioning Hypervisor (EL2 Monitor)
Task Task Task Task o To provide partitioning and isolation at R52
core level but not full core virtualization
OS1 OS2 OS3 OS4 features.
o To manage core shared peripherals (e.g. GIC
vGIC vGIC vGIC vGIC

EL2 Mon. EL2 Mon. EL2 Mon.

EL2 Mon.
R52-1
R52-0
R52-2
R52-0
R52-3 distributor)
R52-0

• Type1 Hypervisor
o To maximize flexibility in using compute
power by sharing applications across cores
and cores across applications
o To implement the concept of virtual CPUs in
addition to virtual machines.

27 | NXP | Public
 S32Z/E – Partitioning Hypervisor / EL2Monitor
(R52 Cluster in Split Lock mode)
RTU Cluster RTU Cluster

EL0 Apps Apps Apps Apps EL0 Apps Apps Apps Apps

EL1 RTOS_0 RTOS_1 RTOS_2 RTOS_3 EL1 RTOS_0 RTOS_1 RTOS_2 RTOS_3

EL2 EL2

R52_0 R52_1 R52_2 R52_3 R52_0 R52_1 R52_2 R52_3

GIC GIC GIC GIC GIC GIC GIC GIC

CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF

Hw GIC Hw GIC Hw GIC Hw GIC

distributor distributor distributor distributor

R52 partition
Hw GIC distributor
EENV

RTU_0 What the HW provides What the SW needs

28 | NXP | Public
 S32Z/E - Partitioning Hypervisor / EL2 Monitor
(R52 cluster in Split Lock mode with EL2 Monitor)
RTU Cluster RTU Cluster

EL0 Apps Apps Apps Apps EL0 Apps Apps Apps Apps

EL1 RTOS_0 RTOS_1 RTOS_2 RTOS_3 EL1 RTOS_0 RTOS_1 RTOS_2 RTOS_3

EL2 EL2 EL2 EL2

EL2 monitor monitor
EL2 monitor monitor

R52_0 R52_1 R52_2 R52_3 R52_0 R52_1 R52_2 R52_3

GIC GIC GIC GIC GIC GIC GIC GIC

CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF CPU IF

Virtual Virtual Virtual Virtual

GIC D. GIC D. GIC D. GIC D.

R52 partition Hw GIC distributor Hw GIC distributor

EENV
What the HW provides What the EL2Monitor offers
RTU_0
29 | NXP | Public
S32Z/E - Partitioning Hypervisor / EL2 Monitor
(Timing Diagrams)

EL0
Task Task …
Access to
GIC distributor
registers
EL1
RTOS RTOS ISR
All ISRs handled the usual way
Jump to EL1
code Exception Return from without EL2monitor intervention
exception

EL2
Boot EL2M EL2M
Bootloader EL2Monitor GIC distributor
Initialization register emulation

30 | NXP | Public
3
S32Z/E - Partitioning Hypervisor / EL2 Monitor
Overview

• R52 partitions
o creates independent “R52 partitions” by doing
GIC emulation and EL2 MPU programming.
• GIC emulation
o GIC distributor is programmed by EL2 monitor to
statically allocate interrupts to different cores.

• EL2 MPU usage to enhance safety and security.

o Protects the shared GIC Distributor and the Guest OS-es
• No virtualization of CPUs, no VM scheduler, always 1:1 guest to host allocation.
• No virtualization of peripherals/devices, always pass through.

31 | NXP | Public
S32Z/E: Micro Hypervisor

32 | NXP | Public
S32Z/E - Micro Hypervisor
(Full core Virtualization Example with multiple VMs per core)
RTU Cluster

EL0 Apps
… Apps Apps
… Apps Apps
… Apps Apps
… Apps

RTOS_1 RTOS_N
EL1 RTOS_1
…
RTOS_N RTOS_1
…
RTOS_N RTOS_1
…
RTOS_N
…

vCPU
… vCPU vCPU
… vCPU vCPU
… vCPU
vCPU
… vCPU

vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist
vGIC dist vGIC dist

EL2 Hypervisor Hypervisor Hypervisor Hypervisor

R52_0 R52_1 R52_2 R52_3

GIC CPU interface GIC CPU interface GIC CPU interface GIC CPU interface

VM
EENV 4x Single core Hypervisor
Full virtualization
RTU_0 GIC distributor CPU virtualization 1:N allocation
Sync between Hypervisors 1 physical core - N virtual cores
33 | NXP | Public Multiple single core VMs
S32Z/E Micro Hypervisor
(Full core Virtualization Example with multiple VMs per core)
RTU Cluster

EL0 Apps
… Apps Apps Apps Apps
… Apps

EL1 RTOS_1 RTOS_N RTOS_1

…
RTOS_1

vCPU
… vCPU vCPU vCPU vCPU vCPU vCPU vCPU

vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist vGIC dist

EL2 Hypervisor

R52_0 R52_1 R52_2 R52_3

GIC CPU interface GIC CPU interface GIC CPU interface GIC CPU interface

VM
Multicore Hypervisor
Full virtualization
EENV GIC distributor CPU virtualization 1:N allocation
RTU_0 1 physical core - N virtual cores
34 | NXP | Public Multiple Single core and Multicore VMs
L4Re Hypervisor Family –
Flexible Hardware Abstraction Layer

Deployment
Service

Hardware-Independent

RTOS

RTOS
RTOS

Workloads
Mirror
Control ECU

L4Re Hypervisor & L4Re Micro Hypervisor Abstraction Layer

Multi-Core System with MMU Multi-Core CPU with MPU Specific Hardware
For example: Arm Cortex-A For example: Arm Cortex-R Configuration

35 | NXP | Public
  Strong isolation for security and safety
 Mandatory capability-based access control

 Security by design – uniform APIs

 Tiny native applications, next to VMs

L4Re Hypervisor
Family  Tiny trusted computing base

 All common architectures (Arm, x86, RISC-V)

 Scalable and flexible

 Static & Dynamic

36 | NXP | Public
 Agenda

Introduction
Challenges with New Vehicle Architectures

Software-defined Vehicles & S32 CoreRide

S32Z/E Isolation and Virtualization

Overview

Isolation and Hardware Virtualization Mechanisms

Hypervisors Solutions for Real-time Cores

Partitioning Hypervisor (NXP EL2 Monitor)

Type1 Hypervisor (L4Re Micro Hypervisor)

37 | NXP | Public 37 | NXP | Public

 Demo

38 | NXP | Public
S32Z/E - Processors Vehicle Integration Platform (GreenVIP)
Consolidation of in-vehicle software applications from multiple vendors

Enables Integration of 3rd

party applications from Model Based Design / Example Application

AS A SERVICE
SOFTWARE
S32 Design Studio & with Integrated Tools

(SaaS)
GTM GTM FW

different vendors with NXP SW

Application supplier 1 Application supplier 2 Application supplier 3 Application supplier n

Virtual ECU 3 Virtual ECU 1 Virtual ECU 2 Virtual ECU n

on S32Z/E
Example Classic AUTOSAR Example Zephyr
Comms Comms
engine Gateway Safety Accelerat
OTA Framework or Drivers
AUTOSAR RTE

Demonstrated S32Z/E Security/B

AMMCL

AS A SERVICE
HSE

PLATFORM
oot FW TCP/IP

(PaaS)
capability to run multiple Libraries &
AUTOSAR
BSP
RTOS Safety
Framework
applications in HW enforced
Math CoPro Managem RTOS
ent FW

SW defined isolated execution

RTOS MCAL MCAL Bootloader
MCAL
Safety and
SMU System FW

environments

INFRASTRUCTURE
Type-1 Hypervisor / Partitioning

AS A SERVICE
Inter VM comms

(IaaS)
Physical cores

Develop/Analysis Example of vendor’s 3rd Party &

NXP
Abstraction of HW
XRDC & Interrupt
Tool applications Open Source
& Clock & Safety
& I/O

complexity to enable fast configuration

tool

Time-To-Market

39 | NXP | Public
40 | NXP | Public
 Conclusions

41 | NXP | Public
NXP’s Approach to Manage the Complexity
(Heterogenous SoCs with Hardware-Assisted Virtualization support)

System Execution Execution Execution Execution Environment

Management Environment Environment (vECU) Execution Environment
Environment
(vECU) (vECU) (vECU) (vECU)

System Manager
Security Manager

Safety Manager
Virt

Bare-Metal
Software
RTOS 1 RTOS 2
Rich-OS 1 RICH-OS 2

RTOS
Micro Hypervisor Type1 Hypervisor

Multi-core REAL-TIME Compute Multi-core APPLICATION Compute

Master Core
(Arm® Cortex® R) (Arm® Cortex® A)

MPU MPU MMU

HW Separation Layer (XRDC) Hardware

Virtualization-aware HW Accelerators / Peripherals / Memory

Programmable Programmable
HW Accelerators HW Accelerators

ECU consolidation with Mixed-Criticality Applications

42 | NXP | Public
Arm, Cortex are trademarks or registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved.
NXP’s Virtualization and Isolation Approach

NXP is providing a production-ready partitioning hypervisor (EL2 Monitor)

NXP is enabling an open-source hypervisor, based on L4Re technology.

NXP is working with ecosystem partners to enable various hypervisor

technologies.

43 | NXP | Public
 nxp.com

| Public | NXP and the NXP logo are trademarks of NXP B.V. All other product
or service names are the property of their respective owners. © 2024 NXP B.V.