The accompanying demo (slide 15) can be found at https://vimeo.com/90534015 The presentation will cover Xen vs Xen Automotive gaps and analysis. We will elaborate technical solutions for the identified gaps: * ARM architecture - support HW virtualization extensions for embedded systems * Stability requirements * RT Scheduler * Rich virtualized peripheral support (WiFi, Gfx, MM, USB, etc.) * Performance benchmarking * Security The audience is anyone interesting in building OSS based IVI systems. Attendees can expect the OSS stack detailed architecture, current status of the project, the challenges seen, road map and much more.

1. ©2014 GlobalLogic Inc.
Xen Automotive

2. 2
Next Big Thing is coming …

3. 3
Vehicles are Changing
• Car still bring us from point A to
point B, but looks different inside
• Ford Sync software today contains
10,000,000+ lines of code
• Evolving industry
• Short time to market
• “Cloud” car
• 3rd party applications
• Cost reduction

4. 4
Next Steps
• Combine different function on
single computer
• Modern SoCs are powerful to
perform different functions
• Cluster Display
• Central Console Display
• GPU
• HW MM accelerators
• Security – ARM Trust Zone

5. 5
Requirements
3rd Party
Applications
Look and Feel
customization
Connected
Car Services
Quick
development
cycle

6. 6
Open Source for Automotive – Gaps
Boot TimeStability &
Reliability
Security
Virtualization

7. 7
Why Xen?
• Type 1 Hypervisor
• Flexible Virtualization Mode
• Driver disaggregation
• ARM support
• Open Source
• ~ 90k lines of code
• Mature since 2003 in general
computing

8. 8
Xen in Embedded
− TODO:
− RT scheduler
− More PV drivers
− 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
− Better DT support

9. 9
Peripherals sharing
Sharing of peripherals is implemented using PVHVM
model (Paravirtualized devices on the host, running in
HVM mode), Zero-buffers 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 tinyALSA
− Framebuffer
− NEW: kernelspace frontend and userspace
backend, deliver 30 FPS on J6, WIP on 60
FPS
− TO DO:
− GPS
− GPU

10. 10
− Xen Hypervisor – open source license
− Core PV Drivers – open source license
− PV Backend HW AL – private source license
Ownership unbundling
Xen
Open 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 AL
Apps
Provided by SoC’s vendor OSes

11. 11
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

12. 12
GL MMU SPT Approach
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

13. 13
Nautilus on TI J6 – Sample Layout
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
Mirro
rLink
ALSA HWC
Automotive Grade Android (Fast Boot)
GLSDK Linux
Nautilus Qt Launcher
CAN
HW
Driv
ers
CAMERA

14. 14
Automotive VMs Layout
Xen Hypervisor
DomU – Driver Domain
HW Drivers
PV Backends
IPU
MMU
DomU – Android HMI
PV FrontendsHW Drivers
SoC Android
Components
MediaFW
Xen Android Components
Miracast
Mirror
Link
ALSA HWC
Automotive Grade Android(Fast Boot)
GLSDK Linux kernel
Nautilus Qt Launcher
CANUSB HID Disk Network
WiFi P2P/WFD Audio FrameBuffer
DomU – Automotive
Control Application
(Boot Animation, RVC)
PV FrontendsHW Drivers
QNX/AUTOSAR
Dom0 – System
Control
Xen tools
Xen Linux Kernel
Watchdog service
Camera
GPU
Instrumental
Cluster
OpenGL

15. 15 CONFIDENTIAL

16. 16
− 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

17. 17 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 whitelist
– 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

18. 18 CONFIDENTIAL
Power Management
• cpufreq: policy?
• cpuidle: policy?
• Multi-domain governance?
• ACPI? Not really.
• Thermal Management?

19. 19
Future & Features
Xen branch for Automotive
− “Micro-kernel” approach – DOM0
− PV Drivers packages SoC’s specific
reference
• TI J6, Renesas R-Car M2, Freescale i.MX 8,
A15/A50 SoCs
− Guest OSs
• Android, QNX, Autosar, Ubuntu, Genivi Linux,
Tizen, Yocto

20. 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

21. ©2014 GlobalLogic Inc.
• Thank you
• Alex Agizim
• VP, CTO Embedded Systems
• alex.agizim@globallogic.com
• Alex Mygaiev
• AVP, Program Director
• Artem.mygaiev@globallogic.com