One Size Does Not Fit All

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?

• 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

• 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

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

Trusted Services Cloud Untrusted Services

Networking: Firewall

Trusted Applications Untrusted Applications Automotive Stack Sandbox Access Control

Linux Kernel

„Traditional“ Model

Instrument Infotainment Cluster MCU MCU

Bus

... MCU

MCU MCU

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

HW Audio Automotive GENIVI Graphics Stack Input

Arbitration Network

Android

LSM Access Control Linux Kernel With Android Patches

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)

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

One Tux to run them all

• 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

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

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

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

• 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

• 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/......

• 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!

• 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 !!

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