©2014 GlobalLogic Inc.

Xen Automotive HypervisorAutomotive Linux Summit

1-2 July, Tokyo

2

Vehicles are Changing

Vehicle became the “ultimate mobile device” and we, the people, are becoming “connected drivers”

3

“Connected Driver” Requirements

3rd Party Applications

Look and Feel customization

ConnectedCar Services

Quick development cycle

4

“Ultimate mobile device” requirements

Boot TimeStability & Reliability

Security

Virtualization

5

Why Xen?

• Type 1 Hypervisor

• Flexible Virtualization Mode

• Driver disaggregation

• ARM support

• Open Source, part of LF

• ~ 90k lines of code

• Mature since 2003 in general computing

6

Xen in Embedded

− TODO:

− RT scheduler improvments

− More PV drivers (QNX)

− Debug, fix, stabilize…

− With ARM support Xen is perfectly fit for embedded applications

− Experimental PV ARM support on Nvidia made by Samsung

− ARM HW virtualization support from Xen 4.3

− Added:− Interrupts mapping to DomU (for driver

domains)− IOMEM mapping to DomU (for driver

domains)− MMU SPT protection− PV drivers: HID, Audio, Framebuffer, etc.

− Better DT support

7

Peripherals sharing

Sharing of peripherals is implemented using PVHVM model (Paravirtualized devices on the host, running in HVM mode), zero-copy− Filesystem partitions

− Standard Xen PV driver− Network

− Standard Xen PV driver− USB

− Based on old Xen 3.4 PV USB driver with major fixes

− HID (touchscreen)− NEW: kernelspace frontend and userspace

backend, can be used for any type of events

− Audio

− NEW: kernelspace frontend and userspace backend, based on ALSA

− Framebuffer

− NEW: kernelspace frontend and userspace backend, deliver 60 FPS on J6

− GPU – in progress based on OpenGL/ES abstraction (HW independent)

− TODO:

− GPS, Sensors

8

− Xen Hypervisor – open source license

− Core PV Drivers – open source license

− PV Backend HW AL – private source license

Ownership unbundling

XenOpen Source Kernel space

User space

Android/QNX/Ubuntu/Tizen/Autosar

TI J6

PV BackEnd

PV FrontEnd

R-Car M2

PV BackEnd

PV FrontEnd

i.MX8

PV BackEnd

PV FrontEnd

`̀

Tegra K1

PV BackEnd

PV FrontEnd

A15/A50

PV BackEnd

PV FrontEnd

User space

Kernel space

Open Source Private Source SoC’s reference design

Kernel Space

DomU – Driver Domain

Kernel Space

DomU – Guest OS

HW drv PV Frontend

User Space User Space

PV Backend

Backend HW ALApps

Provided by SoC’s vendor OSes

9

GPU Virtualization

Driver DomainDomU2

OpenGL/GL ES library(PV GPU Frontend)

GPU pipeline #2

DomU1

OpenGL/GL ES library(PV GPU Frontend)

GPU pipeline #1

PV GPU Backend

GPU pipeline #1

OpenGL/GL ES library

GPU pipeline #2

GPU driver

OpenGL App #5

OpenGL App #6

OpenGL App #1

OpenGL App #2

OpenGL App #3

OpenGL App #4

* using ClusterGL or VirtualGL

10

GL MMU SPT Approach – upstreamed

GL MMU SPT Approach− For the peripherals that do not have

full SMMU protection but have own MMU it still possible to implement memory access protection and translation with SPT-like approach. Generic implementation is provided to Xen by GL and ready for some coprocessors like GPU, IPU, BB2D, etc.

PTBR

Kernel-maintained

MMU PT

Xen-maintained MMU SPT

Allocated pages

Xen intercepts MMU PTBR access for PT creation/removal

intermediate

physical

Xen intercepts PT access for pages creation/removal

kernel

11

Nautilus on TI J6 – xen support upstreamed

Xen Hypervisor

Dom0

HW Drivers

PV Backends

USB HID Disk Network

WiFi P2P/WFD Audio FrameBuffer

Control Application (Boot Animation, RVC)

IPU GPU

MMUs

DomU

PV FrontendsHW Drivers

SoC Android Components

MediaFW

gralloc PVR

Xen Android Components

Miracast MirrorLink ALSA HWC

Automotive Grade Android (Fast Boot)GLSDK Linux

Nautilus Qt Launcher

CAN

HW Drivers

CAMERA

DomU

QNX Neutrino

PV Frontends

Animation Application

12

− u-boot loads Xen device tree configuration and Dom0 kernel

− cold start to Xen start is less than 100ms

− domain configuration, memory map, IRQ map passed to Xen trough device tree

Boot Time

− Xen boot time on J6 is 300ms− all printouts are disabled

− RAM wipeout is disabled

− Dom0 kernel boots in 800ms

13 CONFIDENTIAL

Hypervisor vs. Monitor

Virtualization and TrustZoneTrustZone is also kind of virtualization

− Coexists with VMM but of higher priviledge

− Separated into 2 worlds only – Secure and non-Secure

Typical tasks for TrustZone SW:− System boot protection

− Application signature validation

− Firmware integrity check

− External peripherals whiltelist

− Secured peripherals drivers

− Closed crypto algorithms implementation (DRM)

Hypervisor integration notes− Boots before non-secure SW, i.e. before Xen

− Xen shall allow domains to perform SMC calls

− System control partitioning can be simplified with monitor mode (Power Management, etc.)

App App App App

Operating System Operating System

Hypervisor

TrustZone Monitor

Operating System

App App

Non-secure execution environment Secure execution environment

14 CONFIDENTIAL

Power Management

cpufreq: policy?cpuidle: policy?Multi-domain governance?ACPI? Not really.Thermal Management?

15

Future & Features

Xen SubProject – Embedded & Automotive PV Drivers – GL maintainers

− “Micro-kernel” approach – DOM0

− PV Drivers packages SoC’s specific reference • TI J6, Renesas R-Car M2, Freescale i.MX 8, A15/A50 SoCs

− ISO 26262 certification

− Guest OSs• Android, QNX, ArcCore (AUTOSAR), Tizen (GENIVI)

Alex Agizim

CTO of Embedded Systems in GlobalLogic Inc.

E-mail: alex.agizim@globallogic.com

Skype: alexa1968

Artem Mygaiev

Program Director in GlobalLogic-Ukraine

E-mail: artem.mygaiev@globallogic.com

Skype: rosenkrantzguildenstern

©2014 GlobalLogic Inc.

• Thank you• Alex Agizim• VP, CTO Embedded Systems• alex.agizim@globallogic.com

• Alex Mygaiev• AVP, Program Director• Artem.mygaiev@globallogic.com