Virtualizaton: One Size Does Not Fit All Nedeljko Miljevic Product Manager, Automotive Solutions MontaVista Software Agenda • Linux and Automotive • Challenges • Solution: Virtualization • Linux Containers • Best Fit? © 2010 MontaVista Software - Confidential 2 Linux and Automotive Linux in Automotive • A number of ECUs are deployed in a car • Traditionally running RTOSes • Linux has gained traction in the automotive industry • Transforming the OS landscape • SoCs offer increasing performance • Modern multicore SoCs offer a lot of power • More functionality can be implemented on a single SoC • With growing computing power the demands are also growing • Cars becoming more „intelligent“ • Consolidating functions • On a multicore system © 2012 MontaVista Software 4 Linux and Automotive (cont.) • Linux deployment • Instrument Clusters • Telematics • IVI Systems • Driven by • Availability of Linux on SoCs from silicone vendors • Drivers for HW usually available from Day 1 • Increased demand for connectivity • Wireless connectivity (to cloud) • Follows increasing bandwidth and lowering prices • Consumer devices (local) • Innovation rate in OSS • Abundance of SW projects © 2012 MontaVista Software 5 Challenges: A Linux Perspective Challenge 1: Solving Different Lifecycle Cadences Example: Android Co-Existence Consumer - OEM driven Cadence cadence T1/OEM ~monthly Custom Apps Android Apps GENIVI Google Compliant Cadence - Cadence of Android ~6-9 months ~6-12 months Stack MV Linux Kernel - 1-3 year cadence - Multiple hardware HW - SoC - Low, medium and high end © 2012 MontaVista Software Challenge 2: Connected Car – Downloaded Apps Trusted Services Cloud Untrusted Services Networking: Firewall Trusted Applications Untrusted Applications Automotive Stack Sandbox Access Control Linux Kernel © 2012 MontaVista Software Challenge 3: Interoperability „Traditional“ Model Instrument Infotainment Cluster MCU MCU Bus ... MCU MCU MCU © 2012 MontaVista Software Challenge 3: Interoperability (cont.) Multicore Model Muticore System Instrument MCU Cluster SW Infotainment „Bus“ Bus Control Functions MCU © 2012 MontaVista Software Solution: Virtualization Demands on Virtualization in Automotive • Depend on Use Cases • Use Cases: • Automotive Domain shares the resources with guest domain (e.g. Driver seat) • Automotive and guest domains run each on dedicated resources (e.g. Passenger seats vs driver seat) • Tecnological Demands: • Isolation and Security • Different domains should not affect each others‘ functioning • Interoperability • Domains need to communicate and interact with each other © 2012 MontaVista Software 12 Use Case: Shared HW HW Audio Automotive GENIVI Graphics Stack Input Arbitration Network Android LSM Access Control Linux Kernel With Android Patches © 2012 MontaVista Software 13 Use Case: Dedicated HW HW Audio Graphics Automotive GENIVI Input Stack • Less Issues Network Android HW LSM Audio Linux Kernel Graphics Input © 2012 MontaVista Software 14 Resource Control • Audio Management • Priorities, handling of interrupt sources • Graphics Management • What, when, where to display • Inputs • Input distribution and focus • Networking • Outside world • CE Connectivity • IPC • Interoperability (when desired) © 2012 MontaVista Software 15 Tradeoffs Flexibility (different Oses) Full Virtualization Penalty Performance Paravirtualization Interconnectivity OS Level Virtualization Isolation © 2012 MontaVista Software 16 Full Virtualization • Host OS runs unmodified instances of guest OS(es) • Maximal Domain Isolation • Heavyweight, needs to emulate the HW visible by guest OS completely • Access to real HW resources controlled by the hosting OS • Linux/OSS world: KVM, proprietary implementations • Intercommunication usually only on networking level • Specific Automotive Demands: • Audio – needs an audio management implementation in both domains, hosting and guest • Graphics, Inputs, networking handled automagically • CE Connectivity may need more thorough planning • IPC: mainly using networking © 2012 MontaVista Software 17 Paravirtualization • Thin HW abstraction layer running various OSes (hypervisor) • Good Domain Isolation • Guest OSes need to be patched • Repetitive work when changing the OS version • May not be supported on all OSes • Lightweight • Runs a separate instance for every guest kernel in the system • Specific Automotive Demands: • Audio Management, Graphics, Inputs, Networking – hypervisor may need to control some of the functionality, depends on use case • IPC – hypervisor specific means © 2012 MontaVista Software 18 OS Level Virtualization • Multiple OS instances running on same kernel • Domain isolation not so good (shared kernel) • But tunable! • Single kernel • Need to maintain just one kernel • Reduced Memory Footprint compared to other solutions • Multiple userlands or applications • Very little performance impact • Use standard kernel features (no patching) • Specific Automotive Demands: • Audio Management, Graphics, Inputs, Networking, IPC – handled by the same kernel © 2012 MontaVista Software 19 Linux Containers What‘s different? One Tux to run them all © 2012 MontaVista Software 21 What are Containers? • Lightweight, OS level virtualization • Strictly speaking, not really virtualization • Means of isolating process groups from each other • Standard Linux kernel functionality • cgroups • namespaces • Configurable access to system resources • Devices, CPU, memory usage specified at start time • Configuration is persistent • Can be a single application or a complete userland • ANY userland that runs on top of the same kernel • „Guest“ root FS is a part of the host root FS © 2012 MontaVista Software 22 lxc • OSS project • http://lxc.sourceforge.net • Project in active development • Some cool features not implemented yet • Checkpoint / resume • Comes with a set of command line utilities • lxc-create, lxc-destroy • lxc-start/lxc-stop • lxc-freeze/lxc-unfreeze • lxc-console, lxc-attach • ...... © 2012 MontaVista Software 23 Containers and system resources • Through cgroups / cpusets • Resource management • CPU time • CPU affinity Can be exclusive • Memory usage • Through namespaces • Resource isolation • File system • Networking • IPC • Through configuration • Resource Isolation • Devices and access (r/w) • Mount points © 2012 MontaVista Software 24 Isolation Host system IPC Container 1 Container n Root FS /... = / /... = / ...... /dev /dev ≤ /dev /dev ≤ /dev PID = xy PID 1 IPC PID 1 IPC Linux kernel © 2012 MontaVista Software 25 File System • Container‘s / is in the hosts‘s directory tree • Individual files or directories can be shared between containers and/or with host (e.g. /etc/hosts, /bin, ...) • All specified in configuration files • Some interesting consequences on IPC mechanisms • Named pipes, sockets will work © 2012 MontaVista Software 26 Single Kernel • All kernel services available to host and container • Can be restricted through MAC • So ... • Anything that can be mmap‘ed can be used to communicate data between containers and/or host ... (zero-copy) Host system Container 1 ... Container n Host app /dev/...... © 2012 MontaVista Software 27 Distorted Perception of reality? • Using mmap‘ed buffers? • E.g. For video buffer? • What if .... • There is a mmap capable device with an allocated buffer and mmap() implementation • Seen as /dev/fb0 on guest platform? • Seen as /dev/mydriver on host platofrm? • Complicated? • It‘s YOUR call - as much as YOU make it! • Moral: • Finding a right tradeoff between isolation and performance is not something that the outside factors can decide for you. • Solutions can be combined too! © 2012 MontaVista Software 28 Containers – special case • A special case of container can ... • be bound to a single core • be exempted from scheduler • have all but a small number of interrupts vectored off its core (if/when needed) • Result: • Performance close to „bare metal“ – „container on steroids“ (BME) • > 99 % of CPU time dedicated to the foreground task • ~16 times the performance of the „normal“ Linux system on same HW • All Linux kernel services still available • Can communicate with host or other containers as any „ordinary“ container • Standard Linux programming !! © 2010 MontaVista Software - Confidential 29 Best fit? The answer is … • Depends on what you want to achieve • Want to process CAN? • Use a dedicated MCU, some form of serial connection to the host system • Use one of cores on a multicore chip? • Host a non-Linux based system? • (para)virtualize • Or process CAN in BME • Host a Linux userland? (e.g. Android?) • Sandbox a single application? • Containers are a natural choice © 2010 MontaVista Software - Confidential 31 Thank you! .