1 Virtualization: Hypervisors for Embedded and Safe Systems Hanspeter Vogel Triadem Solutions AG
2 Agenda Use cases for virtualization Terminology Hypervisor Solutions Realtime System Hypervisor Features QNX Hypervisor Features Live Demo with RTS Hypervisor (Win7 and Linux or QNX)
3 Key/Common Use Cases for Virtualization Consolidation & Migration Reduce hardware components, power consumption Move existing legacy software assets to new hardware with minimal porting effort Preserve existing software investment Eg.: Move from old MPC8572 to new P4080 and use one core; 7 other cores (and devices) available for new functionality Safety Separation & Isolation Separation of safety-critical (IEC 61508, ISO 26262) from general-purpose apps Upgrade general purpose apps without recertifying safety component Performance Increase Multiple instances of AMP OS on a multi-core CPU Each AMP instance operates on a subset of data
Terminology 4 Type 1 Virtualization Small shim layer that runs directly on hardware Creates operating environments in which guest operating systems can execute Isolation and assignment of devices,. Minimal performance implications A requirement for embedded products Type 2 Virtualization A complete operating system instrumented with the ability to host another complete OS within a host process Has performance implications: pure software solution Acceptable for desktop virtualization (VMware ) Para-virtualized OS An operating system that has had privileged system calls replaced with hypervisor APIs Not required on hardware that offers hardware assists for virtualization (unmodified guest) Hardware-assist / virtualization extensions Support within the CPU to allow for unmodified guests to run in a virtualized environment, without the need to paravirtualize the guest Syscallsare trapped by the hardware, invoking the hypervisor. FSL QorIQ(e500mc) Cortex A15 Intel VT (Atom, Core i3/5/7, Xeon)
5 Hypervisor Solutions IT Hypervisors VMware (Type2) VMware ESX (Type1) Linux KVM (Type2) Xen (Linux) (Type2) Microsoft Hyper-v (T1/T2) Embedded Hypervisors Real-Time Systems rth (Type1) Acontis VxWin, RTOSWin (Type1.5) QNX Hypervisor(Type1) Green Hills INTEGRITY MultiVisor (Type2) Wind River Hypervisor (Type1) Mentor
RealtimeSystems Hypervisor 6 Virtual Machine Virtual Machine Type 1 bare metal realtimehypervisor x86 (Intel-VT) platforms Simultaneously run Multiple Operating Systems independently on a single Intel x86 currently supporting: RTS Hypervisor 4.x Hardware Windows XP, 7,8,10 (32/64bit) QNX Neutrino Wind River VxWorks RTEMS Linux Proprietary RTOS MeeGo Microware OS-9 On Time RTOS-32 Embedded CE T-Kernel / Itron PreEmptive Linux Android others upon request
History Experience -Success 7 1996 First PC-Based KUKA Robot with Windows Extension VxWin 2002 Start of Profit Center actively selling Windows Extensions worldwide 2005/2006 Spin-Out from KUKA Old Technology remains with KUKA 2006 Real-Time Systems completely Independent from KUKA 2008 RTS Hypervisor Version 1.5 released Celebrating May 2015: 9 YearsReal-Time Systems GmbH July 2015: 7 YearsRTS Hypervisor
8 Virtual Ethernet Windows, Linux Realtime OS Virtual Ethernet drivers supplied for all supported OS Leverage existing real drivers, unmodified Bridging, NAT, routing on Widows / Linux Native Ethernet driver Bridging Routing Virtual Ethernet driver Virtual Ethernet driver High-speed shared memory for transport RTSHypervisor Ethernet PHY Shared Memory
Howdo Systems communicate? 9 Shared Memory The RTS Hypervisor allows for one or multiple shared memory areas to be configured. The size of the shared memory is only limited by the amount of memory available in the system. A simple API provides access to the shared memory from within each Operating System providing for Lock mechanisms and simple communication. Event System The RTS Hypervisor provides an Event System where a user can wait in an operating system for a named event. Events are signaled using IPIs (Inter Processor Interrupts) so they can be used for real-time applications.
10 RTS Hypervisor Highlights Neutral Solution. Hypervisor not tiedto anyoperating System (No Vendor Lock-in) Simple Installation and Configurationalso for Non-Experts Best possible Real-Time Performance (Support for Privileged Mode) No hardware specificadaptationor configurationrequired Support for all Intel x86 CPUs Strongly Supported bymicrosoft (Embedded Gold Partner) Proven Solution (in Production atcustomers)
Some RTS Hypervisor Customers 11
QNX Hypervisor 12 Virtual Machine Virtual Machine Type 1 bare metal realtimehypervisor Supports QNX and Linux/Android guests ARMv7 and x86 (Intel-VT) platforms Leverages QNX patent-pending graphics sharing technology QNX Hypervisor Hardware Compliant to safety certifications: ISO 26262 IEC 62304 IEC 61508
13 Virtual Ethernet QNX SDP 6.5/6.6 QNX / Android Virtual Ethernet drivers supplied for QNX and Linux Leverage existing real drivers, unmodified Bridging, NAT, routing on QNX SDP 6.5/6.6 Native Ethernet driver Bridging Routing Virtual Ethernet driver Virtual Ethernet driver High-speed shared memory for transport QNX Hypervisor Ethernet PHY Shared Memory
14 Shared Devices QNX QNX Qnet allows devices from one OS to be directly accessible from another OS Use native drivers Trusted, field-proven, vendorsupplied drivers Native driver Native driver Qnet Native driver Native driver Native driver Reduce the amount of virtual, untested drivers in platform QNX Hypervisor Currently only supported on QNX OS guests (considering porting Qnet)
15 Shared graphics -glcast Operating System 1 Operating System 2 A QNX patent-pending technology for marshaling OpenGL ES and EGL commands from one OS guest to another Allows one OS to leverage a remote GPU on another OS (not a virtualized GPU) Tested on Mac, Windows, Linux, QNX Apps OpenGL EGL Display Driver GLcast viewer Network send() Display Driver Apps OpenGL EGL Many-to-one GLcast driver is a full implementation of OpenGL and EGL commands No image compression QNX Hypervisor Hardware layer Not lossy, does not consume cpu GPU
Android support in QNX 16 Android execution is native Consists of port from Linux to QNX of Dalvik Virtual Machine Is not emulated or virtualized Performs exceptionally well same (or better) than raw Android on same hardware Android is a container Isolates Android apps from rest of system Protects built-in HMI from downloaded content Doesn t force entire system to be implemented with Android
17 QNX implementation of Android fully sandboxed * Android sandbox has restricted permissions Sandbox contains all cooperating processes necessary for Android implementation Android processes run with user privileges, not as root Applications requiring special access need appropriate OS capabilities Sandbox is isolated from remainder of system Data sharing with native applications is possible in restricted fashion(photo, music, video, etc) Independent versions of SQLite, WebKit, FreeType ensure Android app compatibility Container approach makes our implementation of Android more secure and robust than others
18 QNX Android Architecture App1 App2 App3 App4 App5 App6 App7 App8 Application framework Activity mgr Package mgr Window mgr Resource mgr View system Location mgr Notification mgr Libraries Java runtime WebKit SSL Surface mgr FreeType OpenGL ES SQLite SGL Media fwk Core libraries Dalvik Virtual Machine libbionic QNX kernel
19 Contact Triadem Solutions AG Güterstrasse 13 CH-2502 Biel Sales and Marketing hanspeter.vogel@triadem.ch Phone: +41 (0)32 327 36 32 Fax:+41 (0)32 327 36 37