Xen Automotive Hypervisor Automotive Linux Summit 1-2 July, Tokyo

Transcription

1 Xen Automotive Hypervisor Automotive Linux Summit 1-2 July, Tokyo 2014 GlobalLogic Inc.

2 Vehicles are Changing Vehicle became the ultimate mobile device and we, the people, are becoming connected drivers 2

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

4 Ultimate mobile device requirements Stability & Reliability Boot Time Security Virtualization 4

5 Why Xen? 5 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 With ARM support Xen is perfectly fit for embedded applications Experimental 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 drivers: HID, Audio, Framebuffer, etc. Better DT support TODO: RT scheduler improvments More drivers (QNX) Debug, fix, stabilize 6

7 Peripherals sharing Sharing of peripherals is implemented using HVM model (Paravirtualized devices on the host, running in HVM mode), zero-copy Filesystem partitions Standard Xen driver Network Standard Xen driver USB Based on old Xen 3.4 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 7

8 Ownership unbundling Android/QNX/Ubuntu/Tizen/Autosar User space Kernel space FrontEnd FrontEnd FrontEnd FrontEnd FrontEnd Backend Backend HW AL Apps `` Xen Open Source User space Kernel space BackEnd BackEnd BackEnd BackEnd BackEnd User Space Kernel Space User Space Kernel Space TI J6 R- Car M2 i.mx8 Tegra K1 A15/A50 HW drv Frontend Open Source Private Source SoC s reference design Provided by SoC s vendor OSes DomU Driver Domain DomU Guest OS Xen Hypervisor open source license Core Drivers open source license Backend HW AL private source license 8

9 GPU Virtualization DomU1 DomU2 Driver Domain OpenGL App #1 OpenGL App #3 OpenGL App #5 GPU Backend GPU pipeline #1 OpenGL App #2 OpenGL App #4 OpenGL App #6 GPU pipeline #2 OpenGL/GL ES library ( GPU Frontend) GPU pipeline #1 OpenGL/GL ES library ( GPU Frontend) GPU pipeline #2 OpenGL/GL ES library GPU driver * using ClusterGL or VirtualGL 9

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. kernel Xen intercepts MMU PTBR access for PT creation/removal Xen intercepts PT access for pages creation/removal PTBR Kernel- maintained MMU PT Xen- maintained MMU SPT intermediate physical Allocated pages 10

11 Nautilus on TI J6 xen support upstreamed Dom0 Control Application (Boot Animation, RVC) GLSDK Linux DomU Nautilus Qt Launcher Automotive Grade Android (Fast Boot) DomU Animation Application Backends HW Drivers HW Driv ers MediaF W SoC Android Components grall oc HW Drivers R Miracast Xen Android Components Mirro rlink ALSA Frontends HWC QNX Neutrino Frontends Xen Hypervisor USB HID Disk Network CAN MMUs WiFi P2P/WFD Audio FrameBuffer CAMERA IPU GPU 11

12 Boot Time Xen boot time on J6 is 300ms 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 all printouts are disabled RAM wipeout is disabled Dom0 kernel boots in 800ms 12

13 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.) Non- secure execution environment App App App App Operating System Operating System Hypervisor TrustZone Monitor Secure execution environment App App Operating System 13 CONFIDENTIAL

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

15 Future & Features Xen SubProject Embedded & Automotive Drivers GL maintainers Micro-kernel approach DOM0 Drivers packages SoC s specific reference TI J6, Renesas R-Car M2, Freescale i.mx 8, A15/A50 SoCs ISO certification Guest OSs Android, QNX, ArcCore (AUTOSAR), Tizen (GENIVI) 15

16 Alex Agizim Artem Mygaiev CTO of Embedded Systems in GlobalLogic Inc. Skype: alexa1968 Program Director in GlobalLogic-Ukraine Skype: rosenkrantzguildenstern

17 Thank you Alex Agizim VP, CTO Embedded Systems Alex Mygaiev AVP, Program Director 2014 GlobalLogic Inc.