Embed Size (px)
Citation preview
©2014 GlobalLogic Inc.
Xen Automotive Hypervisor Automotive 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
Connected Car Services
Quick development cycle
4
“Ultimate mobile device” requirements
Boot Time
Stability & 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 spaceKernel 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 TrustZone • TrustZone 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: [email protected] Skype: alexa1968
Artem Mygaiev
Program Director in GlobalLogic-Ukraine E-mail: [email protected] Skype: rosenkrantzguildenstern
©2014 GlobalLogic Inc.
• Thank you • Alex Agizim • VP, CTO Embedded Systems • [email protected]
• Alex Mygaiev • AVP, Program Director • [email protected]
