SlideShare ist ein Scribd-Unternehmen logo
1 von 93
Downloaden Sie, um offline zu lesen
Embedded Virtualization for
      Mobile Devices



Jim Huang ( 黃敬群 ) <jserv@0xlab.org>
Developer, 0xlab
              March 29, 2012 / 中國科學技術大學軟件學院 ( 蘇州 )
Rights to copy
                                                               © Copyright 2012 0xlab
                                                                      http://0xlab.org/
                                                                      contact@0xlab.org
Attribution – ShareAlike 3.0
You are free                                          Corrections, suggestions, contributions and
                                                                        translations are welcome!
✔  to copy, distribute, display, and perform the work
✔  to make derivative works                                           Latest update: Mar 29, 2012
✔  to make commercial use of the work
Under the following conditions
      Attribution. You must give the original author credit.
      Share Alike. If you alter, transform, or build upon this work, you may distribute the
      resulting work only under a license identical to this one.
●  For any reuse or distribution, you must make clear to others the license terms of this
   work.
●  Any of these conditions can be waived if you get permission from the copyright holder.
Your fair use and other rights are in no way affected by the above.
License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode
Goals of This Presentation

• Give you an overview about
  – virtualization in general
  – device virtualization on ARM
  – doing virtualization in several approaches
• We will not discuss
  – language runtimes
  – how to use VMware/Xen/KVM/...
Agenda   (1) Motivations
         (2) Hypervisor Design
         (3) Embedded Hypervisors for
             ARM
Motivations
of enabling virtualization for
    embedded devices
Definition

"virtualization is "a technique for hiding the physical
characteristics of computing resources from the way in
which other systems, applications, or end users
interact with those resources. "
– Wikipedia
Future Computing Trends
 Changes in
 Computing




                                                                                                                                       Open
  Closed                Keyboard/Mouse            Multitouch                      Augmented Reality  Gesture Interactive 3D UI
                                                                                                                                    Distributed
                        Voice Call, SMS           Video Call, MMS                 Eye-Tracking Manytouch  Realtime Web
Centralized                                                                                                                        Correct+Timely
Correct Info.            Centeralized/Concentrated                                  Distributed/Scattered
                                                                                                                                        Info.
                         Known Comm. Entities                                       Unknown/Utrusted Comm. Entities
 Stationary                                                                                                                            Mobile
                                                            Collaboration                                                              Sensor
            Keyboard/                                                                                                                 Network
             Mouse                                                                                    Every Node
                                                                                                       as Both of
                                               Multitouch                                            Client/Server
                        Local
                                    Personal                                        Cloud
                        Store
                                   Computer

 Embedded                             Single-core                                           Multi-core                           Many-core

    IT            Single-core                           Multi-core                                                   Many-core
              UC Berkeley                     [2009]                                        [2012]                      [2017]
              Sensornet Chip                    Tiger 1GHz Single-Core                       ARM 2GHz 4-                ARM 3GHz 8-core
             (TI MSP430 8MHz                    Dunnington 3GHz 6-                             core                      Intel 6GHz 128-core
             core, 10KB RAM)                      core                                        Intel 4GHz 32-             SensorNet Chip
                                                                                                core                     (128MHz core, 160KB RAM)



                                Privacy                                                                   Realtime
Source: Xen ARM Virtualization, Xen Summit Asia 2011
           by Dr. Sang-bum Suh, Samsung
Server Virtualization::Benefits

• Workload consolidation
  – Increase server utilization
  – Reduce capital, hardware, power, space, heat costs
• Legacy OS support
  – Especially with large 3rd-party software products
• Instant provisioning
  – Easily create new virtual machines
  – Easily reallocate resources (memory, processor, IO)
    between running virtual machines
• Migration
  – Predicted hardware downtime
  – Workload balancing
Embedded Virtualization::Benefits

•   Workload consolidation
•   Flexible resource provisioning
•   License barrier
•   Legacy software support
    – Especially important with dozens or hundreds of embedded
      operating systems, commercial and even home-brew
• Reliability
• Security
• (1) Hardware Consolidation
             – Application Processor and Baseband Processor can                                                                                                 Why?
                share multicore ARM CPU SoC to run both Linux and
              - RTOS efficiently.                                                         • (2) OS Isolation
                                                                                             – important call services can be effectively separated
                                                                                               from downloaded third party applications by virtualized
                                                                                               ARM combined with access control.
                                                                                 1                                                 2                                      3


                                                     를




                                                                                                                                                                               Nu




                                                                                                                                        Secure Kernel
                                                                                                                                                                     Android
  General Purpose OS                                          RTOS
             Virtualization SW                   ( Realtime Hypervisor)




                                                                                                                                                        Linux
  V - Core   V - Core   V - Core   V - Core   V - Core   V - Core   V - Core   V - Core




                                                                                                          Linux 1        Linux 2
             Memory                Multi-core            Peripherals
                                                                                              Important         Hypervisor                              Hypervisor
                                                                                              services            H/W
                                                                                                                                                        Hardware
                                                                                                          Secure Smartphone
AP SoC + BP SoC → Consolidated Multicore SoC                                                                                           Rich Applications from Multiple OS
                                                                                               • (3) Rich User Experience
                                  – multiple OS domains can run
                                     concurrently on a single smartphone.
Source: Xen ARM Virtualization, Xen Summit Asia 2011
           by Dr. Sang-bum Suh, Samsung
Use Case: Low-cost 3G Handset

• Mobile Handsets
   – Major applications runs on Linux
    – 3G Modem software stack runs on
      RTOS domain

• Virtualization in multimedia Devices
   – Reduces BOM (bill of materials)
    – Enables the Reusability of legacy
      code/applications
                                            Hypervisor
    – Reduces the system development time

• Instrumentation, Automation
   – Run RTOS for Measurement and
      analysis
    – Run a GPOS for Graphical Interface
• Real cases: Motorola Evoke QA4
original mobile phone:               with Virtualization: single chip
           two CPUs required




•   Evoke’s UI functionalities including the
    touch screen is owned by the Linux
    apps while video rendering uses a
    rendering engine running on BREW.
•   When a user requests a BREW app,
    Linux communciates with BREW in the
    other VM to start up the app. The
    BREW obtains access to the screen by
    using a frame buffer from a shared-
    memory mapping.
Example: Ubuntu for Android
Mobile and Desktop Virtualization in One Device
                    by VMware and Canonical
                     http://www.ubuntu.com/devices/android
Use Case: Nirvana:
                      The Convergence of Mobile and Desktop
                                  Virtualization in One Device
                                            by OKLabs + Citrix


                            Branch              Access
     Receiver              Repeater             Gateway         XenDesktop
                                                                  XenApp
                                                                 XenServer
                                                                 NetScaler




                                                                           Data                       Cloud

                                                                           Center           
SSL 001000111010101 SSL 001000111010101 SSL 001000111010101 SSL 001000111010101 SSL 001000111010101
                                                                                                      Services
Nirvana phone = Smartphone
+ Full-sized display
                                             Nirvana Phone
+ Keyboard & mouse
+ Virtual desktop
+ OKL4 mobile virtualization   Mobile Device
                               Device’s Native Screen
                                                         Native
                                OKL4                     Device
                                Display                  Applications
      External Monitor
                                Drivers                  Receiver
                                                         Start
                                                         Native OS
                                OKL4 BT                  Device
                                Mouse &                  Drivers
                                Keyboard
                                Driver        Citrix     Native
                                              Receiver   Device OS
                                                                        De-privileged
                                                                        Privileged
                                          OKL4 Microvisor




                Demo video:
http://www.youtube.com/user/OpenKernelLabs
Embedded Virtualization Use Case

•   Workload consolidation
•   Legacy software
•   Multicore enablement
•   Improve reliability
•   Secure monitoring
Use Case: Workload Consolidation

   Consolidate legacy systems




                                 legacy legacy legacy
         legacy SW                 SW     SW     SW

                                      host kernel
         legacy HW
                                       new HW
Use Case: Legacy Software
   Run legacy software on new core/chip/board with full
    virtualization
                                            legacy new
                      legacy                  SW      SW
                        SW
                                              host kernel
                    legacy HW
                                               new HW
   Consolidate legacy software
                                               visualization
             visualization                         app
    RT app
                 app                 RT app
                                                proprietary
    Linux     proprietary                         kernel
    core        kernel                   Linux/KVM
                 core                 core       core
Use Case: Multicore Enablement

    Legacy uniprocessor applications
                         legacy app      app      app      app
     legacy app
                        legacy kernel       multicore kernel
    legacy kernel
                                          host kernel
     legacy app
                                core     core    core      core
        core


   Flexible resource management
                               data

                     control             data    data
                      plane              plane   plane
                               control

                                  host kernel
                      core       core    core     core
Use Case: Improved Reliability

    Hot standby without additional hardware


                                              app   backup
       app                                           app
                                              HW
                                                     HW
       HW

                             backup
                       app
                              app

                       host kernel
                       HW
Use Case: Secure Monitoring

   Protect monitoring software

                                  network
    network                                  app
               app                                 monitor
                                            kernel
              kernel
                                             host kernel
               HW
                                                 HW
Hypervisor Design
"All problems in computer science
can be solved by another level of
            indirection."

      -- David Wheeler --
Virtual Machine

       • Gerald Popek and Robert Goldberg defined it as
         “efficient, isolated duplicate of a real machine”

           – Add Virtualizing Software to a Host platform and support
             Guest process or system on a Virtual Machine (VM)




The software that provides this illusion is the Virtual Machine Monitor
         (VMM, mostly used synonymous with Hypervisor)
Virtual Machine for Portability
                               (in the past)
PowerPC          x86             x86-32                HP –PA
programs         programs        programs              programs



       Rosetta           FX!32               IA-32            Aries
       (Apple)           (DEC)               (Intel)          (HP)


x86-32           DEC             IA-64                 IA-64
or x86-64        Alpha           (Itanium)             (Itanium)
Virtual Machine for Portability
        NOTE: we won't discuss such topic in this presentation
                             x86
                             programs




             C               LLVM IR     Bytecode




DEC              IA-64         PowerPC   SUN
Alpha            (Itanium)               Sparc         ARM
System Virtual Machine
• Provide a system environment
• Constructed at ISA level
• Allow multiple OS environments,
  or support time sharing.
• virtualizing software that
  implements system VM is called
  as VMM (virtual machine monitor)
• Examples:
    – IBM VM/360, VMware, VLX,
      WindRiver Hypervisor, ENEA
      Hypervisor
    – Xtratum, Lguest, BhyVe (BSD
      Hypervisor)
    – Xen, KVM, OKL4, Xvisor,                         Virtual network communication
      Codezero

NOTE: We only focus on system virtual machine here.
Therefore, this presentation ignores Linux vserver, FreeBSD jail, etc.
Virtualization is Common Technique

• Example: In the past, Linux is far from being real-
  time, but RTLinux/RTAI/Xenomai/Xtratum attempted
  to "improve" Linux by introducing new virtualization
  layer.
• real-time capable virtualization
• Dual kernel approach

                          Bare metal (RT) Hypervisor




                                                       Hardware
                                             RTOS
                             Linux
Example: Xenomai (Linux Realtime Extension)
Linux application            VxWorks application        POSIX application

      glibc                    glibc    Xenomai          glibc        Xenomai
                                        libvxworks                   libpthread_rt
              System calls

          VFS          Network            Xenomai RTOS                       Pieces added
                                            (nucleus)                         by Xenomai
        Memory               ...
                                                Linux kernel space
                                                                                Xenomai
                             Adeos I-Pipe                                        skins

                                              • From Adeos point of view, guest OSes
                                                are prioritized domains.
                                              • For each event (interrupts, exceptions,
                                                syscalls, etc...), the various domains may
                                                handle the event or pass it down the
                                                pipeline.


                                       Source: Real-time in embedded
                                       Linux systems, Free Electrons (2011)
Windows Apps          Linux Apps

  • Type I
                                MS-                        Linux
  • Bare metal system VM      Windows

                                  VMM or Hypervisor
                                    Physical Machine
  General Classification
             of
Virtualization technologies
                                 Windows Apps         Linux Apps
   • Type 2                                 MS-
                                          Windows
   • Hosted System VM
                                              VM
                                              Linux

                                        Physical Machine
Source: Operating Systems Design – Lecture 21 Virtualization,
Roy Campbell (Fall 2010)
Myth of Type I and Type II Hypervisor
source: http://gala4th.blogspot.com/2011/10/myth-of-type-i-and-type-ii-hypervisors.html

   • Myth: Type-2 is "lesser" than a true "type-1"
     hypervisor.
   • Virtualization theory really started with a paper from
     Gerald Popek and Robert Goldberg called Formal
     Requirements for Virtualizable Third Generation
     Architectures. (1974)
      – Sensitive Instructions
      – Privileged Instructions
   • The terms "type-1" and "type-2" originate from a
     paper by John Robin called Analyzing the Intel
     Pentium's Capability to Support a Secure Virtual
     Machine Monitor. (USENIX 2000)
      ● Popek/Goldberg proof does not eliminate the

        possibility of using dynamic translation
Virtualizable
                  is a property of the Instruction Set Architecture (ISA)
• A sensitive instruction            • A privileged instruction
  – changes the                        – must be executed with
    configuration or mode of             sufficient privilege
    the processor,                     – causes a trap in user
  or                                     mode
   – depends in its behavior
     on the processor’s state

      If all sensitive instructions are privileged, a VMM can be written.
System Virtualization Implementations
     Full             Para        Hardware Assisted
Virtualization   Virtualization     Virtualization
Full Virtualization

●
    Everything is virtualized
●
    Full hardware emulation
●
    Emulation = latency
Recall the definitions
• Sensitive Instructions as defined by "Formal Requirements for
  Virtualizable Third Generation Architectures” (1974):
  – Mode Referencing Instructions
  – Sensitive Register/Memory Access Instructions
  – Storage Protection System Referencing Instructions
  – All I/O Instructions
• Theorem about strict virtualizability by "Analyzing the Intel
  Pentium's Capability to Support a Secure Virtual Machine
  Monitor" (2000):
  – For any conventional third generation computer, a virtual
    machine monitor may be constructed if the set of sensitive
    instructions for that computer is a subset of the set of
    privileged instructions.
Privileged Instructions
●   Privileged instructions: OS kernel and device
    driver access to system hardware
●   Trapped and Emulated by VMM
    –   execute guest in separate address space in
        unprivileged mode
    –   emulate all instructions that cause traps
0x1C                    FIQ
                                                        0x18                    IRQ
                                                        0x14                (Reserved)
                                                        0x10                Data Abort
    Current Visible Registers                           0x0C              Prefetch Abort
                r0                                      0x08              Software Interrupt
Undef Mode
 Abort Mode
SVC Mode
IRQ Mode
FIQ Mode
User Mode
                r1
                                                        0x04            Undefined Instruction
                r2
                r3                                     0x00         Reset
                                                  Banked out Registers
                r4
                                                                Vector Table
                r5
                r6              User     FIQ         IRQ        SVC           Undef       Abort
                r7
                r8               r8      r8
                r9               r9      r9                     Banked out Registers
                r10             r10      r10
                r11             r11      r11
                r12             r12      r12
              r13 (sp)      r13 (sp)   r13 (sp)    r13 (sp)    r13 (sp)      r13 (sp)     r13 (sp)
              r14 (lr)      r14 (lr)   r14 (lr)    r14 (lr)    r14 (lr)      r14 (lr)     r14 (lr)
              r15 (pc)

               cpsr
               spsr                     spsr        spsr         spsr          spsr            spsr
r0                  r8
                r1                  r9           31              0
                r2                 r10
                r3                 r11                    CPSR
                r4                 r12
                r5                 r13
                                                  NZCV
                r6                 r14
                r7              r15 (PC)
                                                 Link register
         unbanked registers   banked registers


Every arithmetic, logical, or shifting operation may set CPSR
(current program statues register) bits:
 ●
   N (negative), Z (zero), C (carry), V (overflow).
Examples:
 ●
   -1 + 1 = 0:    NZCV = 0110.
 ●
   231-1+1 = -231: NZCV = 0101.
ARM Architecture (armv4)

• 6 basic operating modes (1 user, 5 privileged)
• 37 registers, all 32 bits wide
   – 1 program counter
   – 5 dedicated saved program status registers
   – 1 Current program status register (PSR)
   – 30 general purpose registers
• Special usage
   – r13 (stack pointer)
   – r14 (link register)
   – r15 (program counter, PC)

                                                   40
Typical ARM instructions (armv4)
•   branch and branch with Link (B, BL)
•   data processing instructions (AND, TST, MOV, …)
•   shifts: logical (LSR), arithmetic (ASR), rotate (ROR)
•   test (TEQ, TST, CMP, CMN)
•   processor status register transfer (MSR, MRS)
•   memory load/store words (LDR, STR)
•   push/pop Stack Operations (STM, LDM)
•   software Interrupt (SWI; operating mode switch)
•   co-processor (CDP, LDC, STC, MRC, MCR)




                                                            41
Problematic Instructions             (1)


    • Type 1
      Instructions which executed in user mode will cause
      undefined instruction exception
    • Example
      MCR p15, 0, r0, c2, c0, 0
      Move r0 to c2 and c0 in coprocessor specified by p15
      (co-processor) for operation according to option 0
      and 0
       – MRC: from coproc to register
       – MCR: from register to coproc
    • Problem:
      – Operand-dependent operation

Source: 前瞻資訊科技 – 虛擬化 , 薛智文 , 台大資訊所 (2011)
Problematic Instructions                                  (2)


 • Type 2
   Instructions which executed in user mode will have
   no effect
 • Example
   MSR cpsr_c, #0xD3
   Switch to privileged mode and disable interrupt

31                          Program Status Register (PSR)                        0

 N Z C V Q   --   J   --      GE[3:0]           --          E A I F T   M[4:0]


Execution                                                   Exception Execution
  Flags                                                       Mask      Mode
Problematic Instructions             (3)


• Type 3
  Instructions which executed in user mode will cause
  unpredictable behaviors.
• Example
  MOVS       PC, LR
  The return instruction
  changes the program counter and switches to user
  mode.
• This instruction causes unpredictable behavior when
  executed in user mode.
ARM Sensitive Instructions
• Coprocessor Access Instructions
   MRC / MCR / CDP / LDC / STC
• SIMD/VFP System Register Access Instructions
    VMRS / VMSR
• TrustZone Secure State Entry Instructions
    SMC
• Memory-Mapped I/O Access Instructions
   Load/Store instructions from/into memory-mapped I/O locations
• Direct (Explicit/Implicit) CPSR Access Instructions
    MRS / MSR / CPS / SRS / RFE / LDM (conditional execution) / DPSPC
• Indirect CPSR Access Instructions
    LDRT / STRT – Load/Store Unprivileged (“As User”)
• Banked Register Access Instructions
    LDM/STM (User mode registers)
Solutions to Problematic Instructions
                 [ Hardware Techniques ]
• Privileged Instruction Semantics dictated/translated
  by instruction set architecture
• MMU-enforced traps
   – Example: page fault
• Tracing/debug support
   – Example: bkpt (breakpoint)
• Hardware-assisted Virtualization
  – Example: extra privileged mode, HYP, in ARM
    Cortex-A15
Solutions to Problematic Instructions
                           [ Software Techniques ]
                                 Binary
          Complexity                              Hypercall
                              translation
            Design                High               Low
        Implementation          Medium               High
           Runtime                High             Medium
          Mapped to
         programming         Virtual function   Normal function
          languages




Method: trap and emulate
Dynamic Binary Translation

Translation Basic Block
                                                  BL    TLB_FLUSH_DENTRY_NEW
                                                                …
                                             TLB_FLUSH_DENTRY:
     BL    TLB_FLUSH_DENTRY                      MCR    p15, 0, R0, C8, C6, 1
                   …                             MOV    PC, LR
 TLB_FLUSH_DENTRY:                                              …
     MCR    p15, 0, R0, C8, C6, 1            TLB_FLUSH_DENTRY_NEW:
     MOV    PC, LR                               MOV    R1, R0
                   …                             MOV    R0, #CMD_FLUSH_DENTRY
                                                 SWI    #HYPER_CALL_TLB


• ARM has a fixed instruction size
   – 32-bit in ARM mode and 16-bit in Thumb mode
• Perform binary translation
   – Follow control-flow
   – Translate basic block (if not already translated) at the current PC
   – Ensure interposition at end of translated sequence
   – All writes (but not reads) to PC now become problematic instructions
   – Replace problematic instructions 1-1 with hypercalls to trap and
     emulate → self-modifying code
Virtualization APIs – hypercalls
                                                         /* In Hypervisor */

           /* In Guest OS */
                                                            SWI Handler
      BL     TLB_FLUSH_DENTRY
                     …
  TLB_FLUSH_DENTRY:                                     Hypercall Handler
      MOV    R1, R0
                                                                 ……
      MOV    R0, #CMD_FLUSH_DENTRY
      SWI    #HYPER_CALL_TLB
                     …                            LDR R1, [SP, #4]
                                                  MCR p15, 0, R1, C8, C6, 1




                                                      Restore User Context & PC


• Use trap instruction to issue hypercall
• Encode hypercall type and original instruction bits in hypercall hint
• Upon trapping into the VMM, decode the hypercall type and the original
  instruction bits, and emulate instruction semantics
      mrs Rd, R <cpsr/spsr>


    mrs r8, cpsr                   swi 0x088000
Hypercall

 Guest OS

                    Hypercalls




                                        Software Interrupt
                      No
              Yes
                       Reschedule ?
context switch
 Hypervisor
                    Hyper Call
                     Handler


                    SWI Handler
Hypercall in xen-i386

                                                                         System Call    int 0x80
                                                       01   // linux/include/asm/unistd.h
                                                       02
                                                       03   #define   __NR_restart_syscall          0
 Guest OS                    Hypervisor                04   #define   __NR_exit                     1
                                                       05   #define   __NR_fork                     2
                                                       06   #define   __NR_read                     3
                                                       07   …
HYPERVOSIR_sched_op




                int 82h           hypercall


                               Hypercall_table   do_sched_op

                      iret                                               Hyper Call     int 0x82
                                                      01    // xen/include/public/xen.h
            resume Guest OS
                                                      02
                                                      03    #define   __HYPERVISOR_set_trap_table   0
                                                      04    #define   __HYPERVISOR_mmu_update       1
                                                      05    #define   __HYPERVISOR_set_gdt          2
                                                      06    #define   __HYPERVISOR_stack_switch     3
                                                      07    …
Case study: Xvisor-ARM
                               https://github.com/xvisor

• File: arch/arm/cpu/arm32/elf2cpatch.py
   – Script to generate cpatch script from guest OS ELF
• Functionality before generating the final ELF image
   – Each sensitive non-priviledged ARM instruction is
     converted to a hypercall.
   – Hypercall in ARM instruction set is SVC <imm24>
     instruction.
   – Encode sensitive non-priviledged instructions in <imm24>
     operand of SVC instruction. (software interrupt)
   – Each encoded instruction will have its own unique inst_id.
   – The inst_field for each encoded sensitive non-priviledged
     instruction will be diffrent.
How does Xvisor handle problematic
             instructions like MSR?
  • Type 2
    Instructions which executed in user mode will have
    no effect
  • Example
    MSR cpsr_c, #0xD3
    Switch to privileged mode and disable interrupt

 31                         Program Status Register (PSR)                        0

  N Z C V Q   --   J   --     GE[3:0]           --          E A I F T   M[4:0]


 Execution                                                  Exception Execution
   Flags                                                      Mask      Mode
First, cpatch (ELF patching tool) looks
                   up the instructions...
 MSR cpsr_c, #0xD3
 Switch to privileged mode and disable interrupt


# MSR (immediate)
#       Syntax:
#               msr<c> <spec_reg>, #<const>
#       Fields:
#               cond = bits[31:28]
#               R = bits[22:22]
#               mask = bits[19:16]
#               imm12 = bits[11:0]
#       Hypercall Fields:
#               inst_cond[31:28] = cond
#               inst_op[27:24] = 0xf
#               inst_id[23:20] = 0
#               inst_subid[19:17] = 2
#               inst_fields[16:13] = mask
#               inst_fields[12:1] = imm12
#               inst_fields[0:0] = R
# MSR (immediate)
                                      #       Syntax:
                                      #               msr<c> <spec_reg>, #<const>
                                      #       Fields:
                                      #               cond = bits[31:28]
                                      #               R = bits[22:22]
                                      #               mask = bits[19:16]
                                      #               imm12 = bits[11:0]
                                      #       Hypercall Fields:
                                      #               inst_cond[31:28] = cond
                                      #               inst_op[27:24] = 0xf
                                      #               inst_id[23:20] = 0
def convert_msr_i_inst(hxstr):        #               inst_subid[19:17] = 2
                                      #               inst_fields[16:13] = mask
        hx = int(hxstr, 16)           #               inst_fields[12:1] = imm12
        inst_id = 0                   #               inst_fields[0:0] = R
        inst_subid = 2
        cond = (hx >> 28) & 0xF      Xvisor utilizes cpatch to convert
        R = (hx >> 22) & 0x1
        mask = (hx >> 16) & 0xF
                                     all problematic instructions for OS
        imm12 = (hx >> 0) & 0xFFF    image files (ELF format).
        rethx = 0x0F000000
        rethx = rethx | (cond << 28)
        rethx = rethx | (inst_id << 20)
        rethx = rethx | (inst_subid << 17)
        rethx = rethx | (mask << 13)
        rethx = rethx | (imm12 << 1)
        rethx = rethx | (R << 0)
        return rethx
Requirements of real Hypervisor

• VMM at higher privilege level than VMs
  – CPU Virtualization
  – Memory Virtualization
  – Device & I/O Virtualization

• User and System modes
• Privileged instructions only available in system mode
   – Trap to system if executed in user mode
• All physical resources only accessible using
  privileged instructions
  – Including page tables, interrupt controls, I/O
    registers
Memory Virtualization

• Deal with allocation of Physical memory among
  Guest OS
• RAM space shares among Guest OS
• Processors with memory virtualization support is
  expecting in 2nd generation processors (Intel VT and
  ARM Cortex-A15)
Device and I/O Virtualization

• Deal with routing of I/O requests between virtual
  devices and the shared physical hardware
• Similar to the single I/O device shared concurrently
  among different applications.
• Hypervisor virtualizes the physical hardware and
  present each virtual machine with a standard set of
  virtual devices
Paravirtualization

• OS or system devices are virtualization aware
• Requirements:
  – OS level – translated/modified kernel
  – Device level – paravirtualized or “enlightened”
    device drivers
Paravirtualization

• Why all the trouble? Just “port” a guest operating
  system to the interface of your choice.
• Paravirtualization can
   – provide better performance
   – simplify VMM
• but at a maintainance cost and you need the source
  code
   – Compromise: Use paravirtualized drivers for I/O
     performance (KVM virtio, VMware).
• Examples: MkLinux, L4Linux, Xen, . . .
Paravirtualization

• Paravirtualization can also be semi-automated:
   – Sensitive instructions are automatically identified
     (in compiler output).
   – Sensitive memory access needs to manually
     identified.
   – Leave markers in binary.
   – On VM load-time, VMM replaces instructions with
     emulation code.
   – In-Place VMM translates to hypervisor calls.
• Benefits:
   – less effort than plain paravirtualization
   – comparable speed
Hardware-assisted Virtualization

●   Hardware is virtualization aware
●   Hypervisor and VMM load at
    Ring -1
●   Remove CPU emulation bottleneck
●   Provides address bus isolation
Hardware-assisted Virtualization

●   VMM coordinates direct hardware
    access
●   Memory virtualization solved in
    2nd generation hardware assisted
    platforms
●   Passthrough I/O has limited use
    cases without IOV (I/O Virtualization)
    http://www.pcisig.com/specifications/iov/
Hardware-assisted Virtualization in x86
• VT technology enables new execution mode (VMX-Root Mode in
  x86 by Intel) in the processors to support virtualization
• Hypervisor runs in a root mode below Ring0
• OS requests trap VMM without binary translation or PV
• Specialized Hardware support is required
• A special CPU privileged mode is to be selected to support
Hardware-assisted Virtualization in ARM

•   Enable new execution mode Hypervisor (HYP)
•   Hypervisor runs in a Hypervisor (HYP) mode
•   Guest OS Runs in Supervisory Control (SVC) mode
•   Applications runs in User (USR) mode
Virtualization: Third Privilege
       •   Guest OS same kernel/user privilege structure
       •   HYP mode higher privilege than OS kernel level
       •   VMM controls wide range of OS accesses
       •   Hardware maintains TZ security (4th privilege)

                   Non-secure State           User Mode                   Secure State
                                              (Non-privileged)        1
App1        App2         App1         App2                                  Secure
                                                                             Apps




                                                                                                      Exception Returns
                                             Supervisor Mode                Secure
   Guest OS #1               Guest OS #2     (Privileged)             2




                                                                                         Exceptions
                                                                             OS



                                             Hyp Mode                 3
   Virtual Machine Monitor / Hypervisor      (More Privileged)


TrustZone Secure Monitor                        (Highest Privilege)
Virtualization Extensions: The Basics
• New Non-secure level of privilege to hold Hypervisor
   – Hyp mode

• New mechanisms avoid the need Hypervisor intervention for:
   – Guest OS Interrupt masking bits
   – Guest OS page table management
   – Guest OS Device Drivers due to Hypervisor memory relocation
   – Guest OS communication with the interrupt controller (GIC)

• New traps into Hyp mode for:
   – ID register accesses and idling (WFI/WFE)
   – Miscellaneous “difficult” System Control Register cases

• New mechanisms to improve:
   – Guest OS Load/Store emulation by the Hypervisor
   – Emulation of trapped instructions through syndromes
Memory – the Classic Resource
• Before virtualization: the OS owns the memory
   – Allocates areas of memory to the different
     applications
   – Virtual Memory commonly used in “rich”
     operating systems
           Virtual address map of




                                     Translations




                                                    Physical Address Map
                                    from
           each application




                                    translation
                                    table (owned
                                    by the OS)
Virtual Memory in Two Stages
   Stage 1 translation owned
  by each Guest OS
                                   Stage 2 translation owned by the VMM




                                                                       Hardware has 2-stage memory
                                                                      translation

                                                                       Tables from Guest OS translate
                                                                      VA to IPA

                                                                       Second set of tables from VMM
                                                                      translate IPA to PA

                                                                       Allows aborts to be routed to
                                                                      appropriate software layer




                                                                 Physical Address (PA) Map
Virtual address (VA) map of    “Intermediate Physical” address
each App on each Guest OS      map of each Guest OS (IPA)
Classic Issue: Interrupts
   • An Interrupt might need to be routed to one of
      – Current or different Guest OS
       – Hypervisor
       – OS/RTOS running in the secure TrustZone environment
   • Basic model of the ARM virtualization extensions
      – Physical interrupts are taken initially in the Hypervisor
      – If the Interrupt should go to a Guest OS, Hypervisor maps a
        “virtual” interrupt for that Guest OS
                                                   App1
                                                  App1     App2
                                                          App2            App1
                                                                         App1     App2
                                                                                 App2
                                       Virtual
    App1
   App1          App2
                App2                  Interrupt
                                                  Guest OS 11
                                                   Guest OS          Guest OS 22
                                                                      Guest OS

   Operating System
  Operating System                                      VMM
                                                       VMM
                         Physical         Physical
                        Interrupt        Interrupt
System without virtualization               System with virtualization
Virtual interrupt example
     • External IRQ (configured as virtual by the hypervisor) arrives at the
       GIC
     • GIC Distributor signals a Physical IRQ to the CPU
     • CPU takes HYP trap, and Hypervisor reads the interrupt status
       from the Physical CPU Interface
     • Hypervisor makes an entry in register list in the GIC
     • GIC Distributor signals a Virtual IRQ to the CPU
     • CPU takes an IRQ exception, and Guest OS running on the virtual
       machine reads the interrupt status from the Virtual CPU Interface
                           Virtual
                                       Virtual IRQ
External
                            CPU                       Guest OS
Interrupt
 source                   Interface
            Distributor
                           Physical                     CPU
                             CPU                      Hypervisor
                                       Physical IRQ
                           Interface
Spanning Hypervisor Framework
    ARM Non-Secure Execution Environment                        ARM Secure Execution Environment
                                                                                               Platform Resources

                                                                                 SoC                    NoC
  User                A         A       A            A        Secured             SoC
                                                                             Management                  sMMU
  Exception Level     P         P       P            P        Services        Management
                                                                               Domains
  (Application        P         P       P            P        Domain         Domain (ST/TEI)            Coherence
 Layer)              API                               API                       Resource API



 Kernel/Supervisor                                                  RTOS/uKernel
                       Open OS         Open OS
 Exception Level                                                  Para-virtualization
                       & Drivers        (Linux)
                                                              with platform service API’s           Secured
                        Driver
                     (OpenMP RT)            Resource Driver                   Virtualized TZ Call   hardware timer
                                       Virtualized TZ Call                                          (tick)
  HYP(ervisor)
  Exception Level
                       Open Platform Hypervisor
                         Full Virtualization (KVM)
Accelerators            Virtualized
                      Heterogeneous
(DSP / GPU)

  TZ Monitor
  Exception Level                           TrustZone Monitor



Source: Hardware accelerated Virtualization in the
ARM Cortex™ Processors, John Goodacre, ARM Ltd. (2011)
What does Hypervisor looks like
                              • Thin layer of software running on the hardware
                              • Supports creation of partitions
                                   • Each partition is a virtual machine
                                   • Each partition has one or more virtual processors
                                   • Partitions can own or share hardware resources
                                   • Software running in partition is called a guest
                              • Enforces memory access rules
                              • Enforces policy for CPU usage
                                   • Virtual processors are scheduled on real processors
                              • Enforces ownership of other devices
                              • Provides simple inter-partition messaging
Parent Partition                   • Messages appear as interrupts
                              • Exposes simple programmatic interface called
(Minimum Footprint              “hypercalls”
Operating System)


                                        Hypervisor

                   Ethernet
  Hard Disk                           CPU       RAM
                     NIC
Monolithic vs. Microkernel
Monolithic hypervisor                 Microkernel based
●    Simpler than a modern            hypervisor
     kernel, but still complex        ●     Simple partitioning
●    Contains its own drivers               functionality
     model                            ●     Increase reliability and
                                            minimize TCB
                                      ●     No third-party code
                                      ●     Drivers run within guests
       VM 1                                  VM 1
                  VM 2       VM 3         (“Parent”)
    (“Admin”)
                                            Virtual-     VM 2         VM 3
                                            ization    (“Child”)    (“Child”)
                                             Stack
                                           Drivers
                                            Drivers    Drivers
                                                        Drivers     Drivers
                                                                     Drivers
                Hypervisor                   Drivers     Drivers      Drivers

                 Drivers
                  Drivers
                   Drivers                             Hypervisor

                Hardware                               Hardware
Virtualization Stack
                                      • Collection of user-mode and kernel-mode components
        WMI                                • Runs within a partition on top of a (minimal) OS
      Provider                             • Contains all VM support not in the hypervisor
                     VM Worker
                      VM Worker       • Interacts with hypervisor
    VM Service         VM Worker
                      Process
                        Process            • Calls the hypervisor to perform certain actions
                        Process
                                           • Responds to messages from the hypervisor or from
                                             other partitions
                                      • Creates and manages a group of “child partitions”
                                           • Manages memory for child partitions
                                           • Virtualizes devices for child partitions
    Virtualization                    • Exposes a management interface
    Infrastructure        VMBus
        Driver           Bus Driver


 Parent     Hypervisor API &
Partition   Message Library                Child Partition 1          Child Partition 2

                                       Hypervisor
Device Virtualization

• Standard VSP (Virtualization service providers)
   – Storage: support difference drive chains
  – Network: provide virtualized network mechanism
  – Video: 2D/3D graphics w/ or w/o HW acceleration
  – USB: allow a USB device to be assigned to a
    partition
  – Input: keyboard, mouse, touchscreen
  – Time: virtualization for RTC hardware
Device Virtualization
                                      • Physical devices
                                            • Managed by traditional driver stacks
                                      • Virtualization service providers
                                            • Virtualize a specific class of device
                                            • Expose an abstract device interface
            Storage
            Storage
             VSP                            • Run within the partition that owns the
              VSP
                                              corresponding physical device
                                      • Virtualization service clients
    Storage
    Storage              Storage
                         Storage            • Consume virtualized hardware service
     Stack
     Stack                Stack
                          Stack       • VMBus
                                            • Software “bus” (enumeration, hot plug, etc.)
                          Storage
                          Storage           • Enables VSPs and VSCs to communicate
        Port
        Port               VSC
                            VSC               efficiently
       Driver
       Driver
                                            • Uses memory sharing and hypervisor IPC
 Parent
                 VMBus
                 VMBus       VMBus
                             VMBus            messages
Partition

                               Hypervisor
                               Hypervisor

        Disk
        Disk
Embedded Virtualization Issues

• Memory footprint
• Security
   – Increases size of Trusted Computing Base
•   Direct IO Access
•   Emulate IO
•   Virtual IO
•   Real-time support
Direct I/O Access
• Guest can directly access physical IO without host
  involvement
   – Native speed
• IOMMU provides isolation and physical address translation
  (DMA)
   – Translation could be done with guest modifications
• Issues:
   – IOMMU required for DMA isolation
   – Limited by number of physical IO devices
   – Guests must have device drivers
   – What about legacy guests on new hardware?
   – Breaks migration
   – IRQ delivery and routing
Emulated I/O

• Host software emulates guest IO accesses
• Issues:
   – Must write software to (perfectly?) emulate
     hardware
  – Dramatic increase in IO latency
  – Host OS must have physical device drivers
     • Device driver availability, licensing concerns
Virtual I/O

• No hardware at all, just inter-guest data transfer
• New guest device drivers co-operate with host
• Issues:
   – Requires guest modification (at least new
     device drivers)
   – Host OS still needs physical IO drivers
Embedded Hypervisors for ARM
Embedded Hypervisors for ARM
                                              (open source part)
• Xen
   – Xen-arm, contributed by Samsung
     ARM9, ARM11, ARM Cortex-A9 MP
   – Xen-arm-cortext-a15, contributed by Citrix -
     https://lkml.org/lkml/2011/11/29/265
     ARM Cortex-A15
• OKL4 (from open to close source), OKLabs
• L4Linux, TU Desden
• KVM ARM porting
   – Columbia University
   – NTHU, Taiwan
• Xvisor: supports ARMv5, ARMv7, ARMv7+VE
• Codezero
Xen-ARM (Samsung)
  Goals
Lightweight virtualization for secure 3G/4G mobile devices
     High performance hypervisor based on ARM processor
    Fine-grained access control fitted to mobile devices

  Architecture of Xen ARM
                              VM 0                                            VM n

                       Application          Lightweight Xen-                Application
                      Application                Tools                     Application

       Guest                     Backend Drivers                         Frontend Drivers
      Domain
                                  Native Drivers

                                     VM Interface                         VM Interface
     Secure
    Xen ARM                 Domain                  Resource                 Access
    Hypervisor              Manager                 Allocator                Control


    Hardware                Peripheral          CPU             System          UART
                             Devices                            Memory
Overview
                                                     Xen-ARM (Samsung)
                                                                                 Logical
                                                                                  mode
 CPU virtualization                                                              split
 Virtualization requires 3 privilege CPU levels, but ARM supports 2 levels
                                                                                   Xen ARM mode
   Xen ARM mode: supervisor mode ( most privileged level)
                                                                                virtual kernel mode
   Virtual kernel mode: User mode ( least privileged level)                     virtual user mode
   Virtual user mode: User mode ( least privileged level)

                                                                                    VM 2             Xen ARM
 Memory virtualization                           VM 0    VM 1    VM 2
                                                 Address Address Address            VM 1
 VM’s local memory should be                    Spaces Spaces Spaces                                 Kernel
                                                                                     VM 0
 protected from other VMs                                                                         User Process
                                                                                                         Process
                                                                                                   User Process
                                                                                                   User Process
                                                                                                    User
                                                                                   Xen ARM
 Xen ARM switches VM’s virtual address space              MMU
                                                                                  Physical        Virtual
   using MMU                                             Xen ARM               Address Space Address Space
   VM is not allowed to manipulate MMU directly
                                                                    VM0 (Linux)       VM1 (Linux )

 I/O virtualization                                              Application
                                                                  Application
                                                                  Application              Application
                                                                                           Application
                                                                                           Application
 Split driver model of Xen ARM                                  Native Back-end             Front-end
   Client & Server architecture for shared I/O devices          driver driver                 driver
     Client: frontend driver
                                                                    Interrupt        I/O event
     Server: native/backend driver                                             Xen ARM
                                                                 Device
• Xen without assisted hardware VM
• Xen with assisted hardware VM
Micro-hypervisor

     • Microvisor – OKL4 4.0
     • Research projects such as NOVA, Coyotos, and
       seL4
• Microhypervisor                • VMM
  – “the kernel part”               – “the userland part”
  – provides isolation              – CPU emulation
  – mechanisms, no policies         – device emulation
  – enables safe access to
  – virtualization features to
    userspace
Embedded Virtualization for Mobile Devices
Source: VIRTUALIZATION, Julian Stecklina, TU Dresden
Advantage of NOA architecture:
               Reduce TCB of each VM
• Micro-hypervisor provides low-level protection
  domains
   – address spaces
  – virtual machines
• VM exits are relayed to VMM as IPC with selective
  guest state
• one VMM per guest in (root mode) userspace:
   – possibly specialized VMMs to reduce attack
     surface
  – only one generic VMM implemented
Reference

• 前瞻資訊科技–虛擬化 , 薛智文 , 台大資訊所 (2011)
• ARM Virtualization: CPU & MMU Issues, Prashanth Bungale,
  vmware
• Hardware accelerated Virtualization in the
  ARM Cortex™ Processors, John Goodacre, ARM
  Ltd. (2011)
• Hypervisors and the Power Architecture
  http://www.techdesignforums.com/embedded/embedded-topics/embedded-development-
  platforms/hypervisors-and-the-power-architecture/
• Philippe Gerum, State of Real-Time Linux: Don't Stop Until
  History Follows, ELC Europe 2009
http://0xlab.org

Weitere ähnliche Inhalte

Was ist angesagt?

Arm device tree and linux device drivers
Arm device tree and linux device driversArm device tree and linux device drivers
Arm device tree and linux device driversHoucheng Lin
 
Computing Performance: On the Horizon (2021)
Computing Performance: On the Horizon (2021)Computing Performance: On the Horizon (2021)
Computing Performance: On the Horizon (2021)Brendan Gregg
 
import rdma: zero-copy networking with RDMA and Python
import rdma: zero-copy networking with RDMA and Pythonimport rdma: zero-copy networking with RDMA and Python
import rdma: zero-copy networking with RDMA and Pythongroveronline
 
How shit works: the CPU
How shit works: the CPUHow shit works: the CPU
How shit works: the CPUTomer Gabel
 
High Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many CoreHigh Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many Coreslankdev
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向Naoya Horiguchi
 
为啥别读HotSpot VM的源码(2012-03-03)
为啥别读HotSpot VM的源码(2012-03-03)为啥别读HotSpot VM的源码(2012-03-03)
为啥别读HotSpot VM的源码(2012-03-03)Kris Mok
 
JVM @ Taobao - QCon Hangzhou 2011
JVM @ Taobao - QCon Hangzhou 2011JVM @ Taobao - QCon Hangzhou 2011
JVM @ Taobao - QCon Hangzhou 2011Kris Mok
 
Linux Profiling at Netflix
Linux Profiling at NetflixLinux Profiling at Netflix
Linux Profiling at NetflixBrendan Gregg
 
Part 02 Linux Kernel Module Programming
Part 02 Linux Kernel Module ProgrammingPart 02 Linux Kernel Module Programming
Part 02 Linux Kernel Module ProgrammingTushar B Kute
 
Linux boot process – explained
Linux boot process – explainedLinux boot process – explained
Linux boot process – explainedLinuxConcept
 
Introduction To Linux Kernel Modules
Introduction To Linux Kernel ModulesIntroduction To Linux Kernel Modules
Introduction To Linux Kernel Modulesdibyajyotig
 
Ceph and RocksDB
Ceph and RocksDBCeph and RocksDB
Ceph and RocksDBSage Weil
 
Linux kernel tracing
Linux kernel tracingLinux kernel tracing
Linux kernel tracingViller Hsiao
 
Achieving the ultimate performance with KVM
Achieving the ultimate performance with KVM Achieving the ultimate performance with KVM
Achieving the ultimate performance with KVM ShapeBlue
 
Linux Performance Analysis: New Tools and Old Secrets
Linux Performance Analysis: New Tools and Old SecretsLinux Performance Analysis: New Tools and Old Secrets
Linux Performance Analysis: New Tools and Old SecretsBrendan Gregg
 
TiDBのトランザクション
TiDBのトランザクションTiDBのトランザクション
TiDBのトランザクションAkio Mitobe
 
Ethernetの受信処理
Ethernetの受信処理Ethernetの受信処理
Ethernetの受信処理Takuya ASADA
 
OSC2011 Tokyo/Fall 濃いバナ(virtio)
OSC2011 Tokyo/Fall 濃いバナ(virtio)OSC2011 Tokyo/Fall 濃いバナ(virtio)
OSC2011 Tokyo/Fall 濃いバナ(virtio)Takeshi HASEGAWA
 

Was ist angesagt? (20)

Arm device tree and linux device drivers
Arm device tree and linux device driversArm device tree and linux device drivers
Arm device tree and linux device drivers
 
Computing Performance: On the Horizon (2021)
Computing Performance: On the Horizon (2021)Computing Performance: On the Horizon (2021)
Computing Performance: On the Horizon (2021)
 
Xvisor: embedded and lightweight hypervisor
Xvisor: embedded and lightweight hypervisorXvisor: embedded and lightweight hypervisor
Xvisor: embedded and lightweight hypervisor
 
import rdma: zero-copy networking with RDMA and Python
import rdma: zero-copy networking with RDMA and Pythonimport rdma: zero-copy networking with RDMA and Python
import rdma: zero-copy networking with RDMA and Python
 
How shit works: the CPU
How shit works: the CPUHow shit works: the CPU
How shit works: the CPU
 
High Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many CoreHigh Performance Networking with DPDK & Multi/Many Core
High Performance Networking with DPDK & Multi/Many Core
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向
 
为啥别读HotSpot VM的源码(2012-03-03)
为啥别读HotSpot VM的源码(2012-03-03)为啥别读HotSpot VM的源码(2012-03-03)
为啥别读HotSpot VM的源码(2012-03-03)
 
JVM @ Taobao - QCon Hangzhou 2011
JVM @ Taobao - QCon Hangzhou 2011JVM @ Taobao - QCon Hangzhou 2011
JVM @ Taobao - QCon Hangzhou 2011
 
Linux Profiling at Netflix
Linux Profiling at NetflixLinux Profiling at Netflix
Linux Profiling at Netflix
 
Part 02 Linux Kernel Module Programming
Part 02 Linux Kernel Module ProgrammingPart 02 Linux Kernel Module Programming
Part 02 Linux Kernel Module Programming
 
Linux boot process – explained
Linux boot process – explainedLinux boot process – explained
Linux boot process – explained
 
Introduction To Linux Kernel Modules
Introduction To Linux Kernel ModulesIntroduction To Linux Kernel Modules
Introduction To Linux Kernel Modules
 
Ceph and RocksDB
Ceph and RocksDBCeph and RocksDB
Ceph and RocksDB
 
Linux kernel tracing
Linux kernel tracingLinux kernel tracing
Linux kernel tracing
 
Achieving the ultimate performance with KVM
Achieving the ultimate performance with KVM Achieving the ultimate performance with KVM
Achieving the ultimate performance with KVM
 
Linux Performance Analysis: New Tools and Old Secrets
Linux Performance Analysis: New Tools and Old SecretsLinux Performance Analysis: New Tools and Old Secrets
Linux Performance Analysis: New Tools and Old Secrets
 
TiDBのトランザクション
TiDBのトランザクションTiDBのトランザクション
TiDBのトランザクション
 
Ethernetの受信処理
Ethernetの受信処理Ethernetの受信処理
Ethernetの受信処理
 
OSC2011 Tokyo/Fall 濃いバナ(virtio)
OSC2011 Tokyo/Fall 濃いバナ(virtio)OSC2011 Tokyo/Fall 濃いバナ(virtio)
OSC2011 Tokyo/Fall 濃いバナ(virtio)
 

Andere mochten auch

Using hypervisor and container technology to increase datacenter security pos...
Using hypervisor and container technology to increase datacenter security pos...Using hypervisor and container technology to increase datacenter security pos...
Using hypervisor and container technology to increase datacenter security pos...Tim Mackey
 
Developing Automotive Linux
Developing Automotive LinuxDeveloping Automotive Linux
Developing Automotive LinuxAlison Chaiken
 
Lightweight Virtualization with Linux Containers and Docker | YaC 2013
Lightweight Virtualization with Linux Containers and Docker | YaC 2013Lightweight Virtualization with Linux Containers and Docker | YaC 2013
Lightweight Virtualization with Linux Containers and Docker | YaC 2013dotCloud
 
Study on Android Emulator
Study on Android EmulatorStudy on Android Emulator
Study on Android EmulatorSamael Wang
 
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System mentoresd
 
Sierraware ARM hypervisor
Sierraware ARM hypervisor Sierraware ARM hypervisor
Sierraware ARM hypervisor Sierraware
 
The Importance of IVI, GENIVI and Open Source
The Importance of IVI, GENIVI and Open SourceThe Importance of IVI, GENIVI and Open Source
The Importance of IVI, GENIVI and Open Sourcegenivialliance
 
LAS16-507: LXC support in LAVA
LAS16-507: LXC support in LAVALAS16-507: LXC support in LAVA
LAS16-507: LXC support in LAVALinaro
 
Developing the Next Generation Embedded HMIs
Developing the Next Generation Embedded HMIs Developing the Next Generation Embedded HMIs
Developing the Next Generation Embedded HMIs mentoresd
 
QEMU - Binary Translation
QEMU - Binary Translation QEMU - Binary Translation
QEMU - Binary Translation Jiann-Fuh Liaw
 
Linaro connect : Introduction to Xen on ARM
Linaro connect : Introduction to Xen on ARMLinaro connect : Introduction to Xen on ARM
Linaro connect : Introduction to Xen on ARMThe Linux Foundation
 
virtualization and hypervisors
virtualization and hypervisorsvirtualization and hypervisors
virtualization and hypervisorsGaurav Suri
 
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARMXPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARMThe Linux Foundation
 

Andere mochten auch (17)

Using hypervisor and container technology to increase datacenter security pos...
Using hypervisor and container technology to increase datacenter security pos...Using hypervisor and container technology to increase datacenter security pos...
Using hypervisor and container technology to increase datacenter security pos...
 
Developing Automotive Linux
Developing Automotive LinuxDeveloping Automotive Linux
Developing Automotive Linux
 
Lightweight Virtualization with Linux Containers and Docker | YaC 2013
Lightweight Virtualization with Linux Containers and Docker | YaC 2013Lightweight Virtualization with Linux Containers and Docker | YaC 2013
Lightweight Virtualization with Linux Containers and Docker | YaC 2013
 
LXC
LXCLXC
LXC
 
Study on Android Emulator
Study on Android EmulatorStudy on Android Emulator
Study on Android Emulator
 
Hypervisor and Nova
Hypervisor and NovaHypervisor and Nova
Hypervisor and Nova
 
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
 
Sierraware ARM hypervisor
Sierraware ARM hypervisor Sierraware ARM hypervisor
Sierraware ARM hypervisor
 
Xen Hypervisor
Xen HypervisorXen Hypervisor
Xen Hypervisor
 
The Importance of IVI, GENIVI and Open Source
The Importance of IVI, GENIVI and Open SourceThe Importance of IVI, GENIVI and Open Source
The Importance of IVI, GENIVI and Open Source
 
LAS16-507: LXC support in LAVA
LAS16-507: LXC support in LAVALAS16-507: LXC support in LAVA
LAS16-507: LXC support in LAVA
 
Developing the Next Generation Embedded HMIs
Developing the Next Generation Embedded HMIs Developing the Next Generation Embedded HMIs
Developing the Next Generation Embedded HMIs
 
QEMU - Binary Translation
QEMU - Binary Translation QEMU - Binary Translation
QEMU - Binary Translation
 
Linaro connect : Introduction to Xen on ARM
Linaro connect : Introduction to Xen on ARMLinaro connect : Introduction to Xen on ARM
Linaro connect : Introduction to Xen on ARM
 
Android Virtualization: Opportunity and Organization
Android Virtualization: Opportunity and OrganizationAndroid Virtualization: Opportunity and Organization
Android Virtualization: Opportunity and Organization
 
virtualization and hypervisors
virtualization and hypervisorsvirtualization and hypervisors
virtualization and hypervisors
 
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARMXPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM
XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM
 

Ähnlich wie Embedded Virtualization for Mobile Devices

Keynote Speech: Xen ARM Virtualization
Keynote Speech: Xen ARM VirtualizationKeynote Speech: Xen ARM Virtualization
Keynote Speech: Xen ARM VirtualizationThe Linux Foundation
 
Mobile Showcase Moblin2
Mobile Showcase Moblin2Mobile Showcase Moblin2
Mobile Showcase Moblin2Tomas Bennich
 
Mikehall FutureWorld 2010 - enabling connectivity
Mikehall FutureWorld 2010 - enabling connectivityMikehall FutureWorld 2010 - enabling connectivity
Mikehall FutureWorld 2010 - enabling connectivityMicrosoft Windows Embedded
 
OMG Data-Distribution Service (DDS) Tutorial - 2009
OMG Data-Distribution Service (DDS) Tutorial - 2009OMG Data-Distribution Service (DDS) Tutorial - 2009
OMG Data-Distribution Service (DDS) Tutorial - 2009Gerardo Pardo-Castellote
 
System Center webinar
System Center webinarSystem Center webinar
System Center webinarSentri
 
SystemCenter webinar 12 6 12
SystemCenter webinar 12 6 12SystemCenter webinar 12 6 12
SystemCenter webinar 12 6 12Sentri
 
2012 06-15-jazoon12-sub138-eranea-large-apps-migration
2012 06-15-jazoon12-sub138-eranea-large-apps-migration2012 06-15-jazoon12-sub138-eranea-large-apps-migration
2012 06-15-jazoon12-sub138-eranea-large-apps-migrationDidier Durand
 
Telecom trends 261112
Telecom trends 261112Telecom trends 261112
Telecom trends 261112Sharon Rozov
 
Presentación Novedades vSphere 5.1
Presentación Novedades vSphere 5.1Presentación Novedades vSphere 5.1
Presentación Novedades vSphere 5.1Omega Peripherals
 
KAIST 전산학과 iDBLab 소개 20130319-발표용
KAIST 전산학과 iDBLab 소개 20130319-발표용KAIST 전산학과 iDBLab 소개 20130319-발표용
KAIST 전산학과 iDBLab 소개 20130319-발표용Taehun Kim, Ph.D
 
Engineering Interoperable and Reliable Systems
Engineering Interoperable and Reliable SystemsEngineering Interoperable and Reliable Systems
Engineering Interoperable and Reliable SystemsRick Warren
 
Integration Platform For JMPS Using DDS
Integration Platform For JMPS Using DDSIntegration Platform For JMPS Using DDS
Integration Platform For JMPS Using DDSSupreet Oberoi
 
An Introduction to Cloud Computing: Evolution or Revolution?
An Introduction to Cloud Computing: Evolution or Revolution?An Introduction to Cloud Computing: Evolution or Revolution?
An Introduction to Cloud Computing: Evolution or Revolution?IBM Sverige
 
Windows7/8 Migration Strategies
Windows7/8 Migration StrategiesWindows7/8 Migration Strategies
Windows7/8 Migration StrategiesJoe Honan
 
Cloud white paper v3.0
Cloud white paper v3.0Cloud white paper v3.0
Cloud white paper v3.0CK Toh
 
Micro Server Design - Open Compute Project
Micro Server Design - Open Compute ProjectMicro Server Design - Open Compute Project
Micro Server Design - Open Compute ProjectHitesh Jani
 
Comparing SOAs for the Internet of Things
Comparing SOAs for the Internet of ThingsComparing SOAs for the Internet of Things
Comparing SOAs for the Internet of ThingsDominique Guinard
 

Ähnlich wie Embedded Virtualization for Mobile Devices (20)

Embedded Virtualization applied in Mobile Devices
Embedded Virtualization applied in Mobile DevicesEmbedded Virtualization applied in Mobile Devices
Embedded Virtualization applied in Mobile Devices
 
Keynote Speech: Xen ARM Virtualization
Keynote Speech: Xen ARM VirtualizationKeynote Speech: Xen ARM Virtualization
Keynote Speech: Xen ARM Virtualization
 
Mobile Showcase Moblin2
Mobile Showcase Moblin2Mobile Showcase Moblin2
Mobile Showcase Moblin2
 
Mikehall FutureWorld 2010 - enabling connectivity
Mikehall FutureWorld 2010 - enabling connectivityMikehall FutureWorld 2010 - enabling connectivity
Mikehall FutureWorld 2010 - enabling connectivity
 
Ethos Dms Consultancy
Ethos Dms ConsultancyEthos Dms Consultancy
Ethos Dms Consultancy
 
OMG Data-Distribution Service (DDS) Tutorial - 2009
OMG Data-Distribution Service (DDS) Tutorial - 2009OMG Data-Distribution Service (DDS) Tutorial - 2009
OMG Data-Distribution Service (DDS) Tutorial - 2009
 
System Center webinar
System Center webinarSystem Center webinar
System Center webinar
 
SystemCenter webinar 12 6 12
SystemCenter webinar 12 6 12SystemCenter webinar 12 6 12
SystemCenter webinar 12 6 12
 
2012 06-15-jazoon12-sub138-eranea-large-apps-migration
2012 06-15-jazoon12-sub138-eranea-large-apps-migration2012 06-15-jazoon12-sub138-eranea-large-apps-migration
2012 06-15-jazoon12-sub138-eranea-large-apps-migration
 
Telecom trends 261112
Telecom trends 261112Telecom trends 261112
Telecom trends 261112
 
Presentación Novedades vSphere 5.1
Presentación Novedades vSphere 5.1Presentación Novedades vSphere 5.1
Presentación Novedades vSphere 5.1
 
KAIST 전산학과 iDBLab 소개 20130319-발표용
KAIST 전산학과 iDBLab 소개 20130319-발표용KAIST 전산학과 iDBLab 소개 20130319-발표용
KAIST 전산학과 iDBLab 소개 20130319-발표용
 
Engineering Interoperable and Reliable Systems
Engineering Interoperable and Reliable SystemsEngineering Interoperable and Reliable Systems
Engineering Interoperable and Reliable Systems
 
Integration Platform For JMPS Using DDS
Integration Platform For JMPS Using DDSIntegration Platform For JMPS Using DDS
Integration Platform For JMPS Using DDS
 
An Introduction to Cloud Computing: Evolution or Revolution?
An Introduction to Cloud Computing: Evolution or Revolution?An Introduction to Cloud Computing: Evolution or Revolution?
An Introduction to Cloud Computing: Evolution or Revolution?
 
Windows7/8 Migration Strategies
Windows7/8 Migration StrategiesWindows7/8 Migration Strategies
Windows7/8 Migration Strategies
 
Cloud white paper v3.0
Cloud white paper v3.0Cloud white paper v3.0
Cloud white paper v3.0
 
Micro Server Design - Open Compute Project
Micro Server Design - Open Compute ProjectMicro Server Design - Open Compute Project
Micro Server Design - Open Compute Project
 
Comparing SOAs for the Internet of Things
Comparing SOAs for the Internet of ThingsComparing SOAs for the Internet of Things
Comparing SOAs for the Internet of Things
 
Wk6a
Wk6aWk6a
Wk6a
 

Mehr von National Cheng Kung University

PyPy's approach to construct domain-specific language runtime
PyPy's approach to construct domain-specific language runtimePyPy's approach to construct domain-specific language runtime
PyPy's approach to construct domain-specific language runtimeNational Cheng Kung University
 
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明National Cheng Kung University
 
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明National Cheng Kung University
 
Develop Your Own Operating Systems using Cheap ARM Boards
Develop Your Own Operating Systems using Cheap ARM BoardsDevelop Your Own Operating Systems using Cheap ARM Boards
Develop Your Own Operating Systems using Cheap ARM BoardsNational Cheng Kung University
 
Lecture notice about Embedded Operating System Design and Implementation
Lecture notice about Embedded Operating System Design and ImplementationLecture notice about Embedded Operating System Design and Implementation
Lecture notice about Embedded Operating System Design and ImplementationNational Cheng Kung University
 
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學National Cheng Kung University
 
F9: A Secure and Efficient Microkernel Built for Deeply Embedded Systems
F9: A Secure and Efficient Microkernel Built for Deeply Embedded SystemsF9: A Secure and Efficient Microkernel Built for Deeply Embedded Systems
F9: A Secure and Efficient Microkernel Built for Deeply Embedded SystemsNational Cheng Kung University
 

Mehr von National Cheng Kung University (20)

PyPy's approach to construct domain-specific language runtime
PyPy's approach to construct domain-specific language runtimePyPy's approach to construct domain-specific language runtime
PyPy's approach to construct domain-specific language runtime
 
Making Linux do Hard Real-time
Making Linux do Hard Real-timeMaking Linux do Hard Real-time
Making Linux do Hard Real-time
 
2016 年春季嵌入式作業系統課程說明
2016 年春季嵌入式作業系統課程說明2016 年春季嵌入式作業系統課程說明
2016 年春季嵌入式作業系統課程說明
 
Interpreter, Compiler, JIT from scratch
Interpreter, Compiler, JIT from scratchInterpreter, Compiler, JIT from scratch
Interpreter, Compiler, JIT from scratch
 
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明
進階嵌入式作業系統設計與實做 (2015 年秋季 ) 課程說明
 
Construct an Efficient and Secure Microkernel for IoT
Construct an Efficient and Secure Microkernel for IoTConstruct an Efficient and Secure Microkernel for IoT
Construct an Efficient and Secure Microkernel for IoT
 
The Internals of "Hello World" Program
The Internals of "Hello World" ProgramThe Internals of "Hello World" Program
The Internals of "Hello World" Program
 
How A Compiler Works: GNU Toolchain
How A Compiler Works: GNU ToolchainHow A Compiler Works: GNU Toolchain
How A Compiler Works: GNU Toolchain
 
Virtual Machine Constructions for Dummies
Virtual Machine Constructions for DummiesVirtual Machine Constructions for Dummies
Virtual Machine Constructions for Dummies
 
從線上售票看作業系統設計議題
從線上售票看作業系統設計議題從線上售票看作業系統設計議題
從線上售票看作業系統設計議題
 
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明
進階嵌入式系統開發與實做 (2014 年秋季 ) 課程說明
 
Making Linux do Hard Real-time
Making Linux do Hard Real-timeMaking Linux do Hard Real-time
Making Linux do Hard Real-time
 
Implement Runtime Environments for HSA using LLVM
Implement Runtime Environments for HSA using LLVMImplement Runtime Environments for HSA using LLVM
Implement Runtime Environments for HSA using LLVM
 
Priority Inversion on Mars
Priority Inversion on MarsPriority Inversion on Mars
Priority Inversion on Mars
 
Develop Your Own Operating Systems using Cheap ARM Boards
Develop Your Own Operating Systems using Cheap ARM BoardsDevelop Your Own Operating Systems using Cheap ARM Boards
Develop Your Own Operating Systems using Cheap ARM Boards
 
Lecture notice about Embedded Operating System Design and Implementation
Lecture notice about Embedded Operating System Design and ImplementationLecture notice about Embedded Operating System Design and Implementation
Lecture notice about Embedded Operating System Design and Implementation
 
Explore Android Internals
Explore Android InternalsExplore Android Internals
Explore Android Internals
 
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學
中輟生談教育: 完全用開放原始碼軟體進行 嵌入式系統教學
 
F9: A Secure and Efficient Microkernel Built for Deeply Embedded Systems
F9: A Secure and Efficient Microkernel Built for Deeply Embedded SystemsF9: A Secure and Efficient Microkernel Built for Deeply Embedded Systems
F9: A Secure and Efficient Microkernel Built for Deeply Embedded Systems
 
Open Source from Legend, Business, to Ecosystem
Open Source from Legend, Business, to EcosystemOpen Source from Legend, Business, to Ecosystem
Open Source from Legend, Business, to Ecosystem
 

Kürzlich hochgeladen

Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 

Kürzlich hochgeladen (20)

20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 

Embedded Virtualization for Mobile Devices

  • 1. Embedded Virtualization for Mobile Devices Jim Huang ( 黃敬群 ) <jserv@0xlab.org> Developer, 0xlab March 29, 2012 / 中國科學技術大學軟件學院 ( 蘇州 )
  • 2. Rights to copy © Copyright 2012 0xlab http://0xlab.org/ contact@0xlab.org Attribution – ShareAlike 3.0 You are free Corrections, suggestions, contributions and translations are welcome! ✔ to copy, distribute, display, and perform the work ✔ to make derivative works Latest update: Mar 29, 2012 ✔ to make commercial use of the work Under the following conditions Attribution. You must give the original author credit. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. ● For any reuse or distribution, you must make clear to others the license terms of this work. ● Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode
  • 3. Goals of This Presentation • Give you an overview about – virtualization in general – device virtualization on ARM – doing virtualization in several approaches • We will not discuss – language runtimes – how to use VMware/Xen/KVM/...
  • 4. Agenda (1) Motivations (2) Hypervisor Design (3) Embedded Hypervisors for ARM
  • 6. Definition "virtualization is "a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources. " – Wikipedia
  • 7. Future Computing Trends Changes in Computing Open Closed  Keyboard/Mouse  Multitouch  Augmented Reality  Gesture Interactive 3D UI Distributed  Voice Call, SMS  Video Call, MMS  Eye-Tracking Manytouch  Realtime Web Centralized Correct+Timely Correct Info.  Centeralized/Concentrated  Distributed/Scattered Info.  Known Comm. Entities  Unknown/Utrusted Comm. Entities Stationary Mobile Collaboration Sensor Keyboard/ Network Mouse Every Node as Both of Multitouch Client/Server Local Personal Cloud Store Computer Embedded Single-core Multi-core Many-core IT Single-core Multi-core Many-core  UC Berkeley [2009] [2012] [2017] Sensornet Chip  Tiger 1GHz Single-Core  ARM 2GHz 4-  ARM 3GHz 8-core (TI MSP430 8MHz  Dunnington 3GHz 6- core  Intel 6GHz 128-core core, 10KB RAM) core  Intel 4GHz 32-  SensorNet Chip core (128MHz core, 160KB RAM) Privacy Realtime Source: Xen ARM Virtualization, Xen Summit Asia 2011 by Dr. Sang-bum Suh, Samsung
  • 8. Server Virtualization::Benefits • Workload consolidation – Increase server utilization – Reduce capital, hardware, power, space, heat costs • Legacy OS support – Especially with large 3rd-party software products • Instant provisioning – Easily create new virtual machines – Easily reallocate resources (memory, processor, IO) between running virtual machines • Migration – Predicted hardware downtime – Workload balancing
  • 9. Embedded Virtualization::Benefits • Workload consolidation • Flexible resource provisioning • License barrier • Legacy software support – Especially important with dozens or hundreds of embedded operating systems, commercial and even home-brew • Reliability • Security
  • 10. • (1) Hardware Consolidation – Application Processor and Baseband Processor can Why? share multicore ARM CPU SoC to run both Linux and - RTOS efficiently. • (2) OS Isolation – important call services can be effectively separated from downloaded third party applications by virtualized ARM combined with access control. 1 2 3 를 Nu Secure Kernel Android General Purpose OS RTOS Virtualization SW ( Realtime Hypervisor) Linux V - Core V - Core V - Core V - Core V - Core V - Core V - Core V - Core Linux 1 Linux 2 Memory Multi-core Peripherals Important Hypervisor Hypervisor services H/W Hardware Secure Smartphone AP SoC + BP SoC → Consolidated Multicore SoC Rich Applications from Multiple OS • (3) Rich User Experience – multiple OS domains can run concurrently on a single smartphone. Source: Xen ARM Virtualization, Xen Summit Asia 2011 by Dr. Sang-bum Suh, Samsung
  • 11. Use Case: Low-cost 3G Handset • Mobile Handsets – Major applications runs on Linux – 3G Modem software stack runs on RTOS domain • Virtualization in multimedia Devices – Reduces BOM (bill of materials) – Enables the Reusability of legacy code/applications Hypervisor – Reduces the system development time • Instrumentation, Automation – Run RTOS for Measurement and analysis – Run a GPOS for Graphical Interface • Real cases: Motorola Evoke QA4
  • 12. original mobile phone: with Virtualization: single chip two CPUs required • Evoke’s UI functionalities including the touch screen is owned by the Linux apps while video rendering uses a rendering engine running on BREW. • When a user requests a BREW app, Linux communciates with BREW in the other VM to start up the app. The BREW obtains access to the screen by using a frame buffer from a shared- memory mapping.
  • 13. Example: Ubuntu for Android Mobile and Desktop Virtualization in One Device by VMware and Canonical http://www.ubuntu.com/devices/android
  • 14. Use Case: Nirvana: The Convergence of Mobile and Desktop Virtualization in One Device by OKLabs + Citrix Branch Access Receiver Repeater Gateway XenDesktop XenApp XenServer NetScaler Data  Cloud Center  SSL 001000111010101 SSL 001000111010101 SSL 001000111010101 SSL 001000111010101 SSL 001000111010101 Services
  • 15. Nirvana phone = Smartphone + Full-sized display Nirvana Phone + Keyboard & mouse + Virtual desktop + OKL4 mobile virtualization Mobile Device Device’s Native Screen Native OKL4 Device Display Applications External Monitor Drivers Receiver Start Native OS OKL4 BT Device Mouse & Drivers Keyboard Driver Citrix Native Receiver Device OS De-privileged Privileged OKL4 Microvisor Demo video: http://www.youtube.com/user/OpenKernelLabs
  • 16. Embedded Virtualization Use Case • Workload consolidation • Legacy software • Multicore enablement • Improve reliability • Secure monitoring
  • 17. Use Case: Workload Consolidation  Consolidate legacy systems legacy legacy legacy legacy SW SW SW SW host kernel legacy HW new HW
  • 18. Use Case: Legacy Software  Run legacy software on new core/chip/board with full virtualization legacy new legacy SW SW SW host kernel legacy HW new HW  Consolidate legacy software visualization visualization app RT app app RT app proprietary Linux proprietary kernel core kernel Linux/KVM core core core
  • 19. Use Case: Multicore Enablement  Legacy uniprocessor applications legacy app app app app legacy app legacy kernel multicore kernel legacy kernel host kernel legacy app core core core core core  Flexible resource management data control data data plane plane plane control host kernel core core core core
  • 20. Use Case: Improved Reliability  Hot standby without additional hardware app backup app app HW HW HW backup app app host kernel HW
  • 21. Use Case: Secure Monitoring  Protect monitoring software network network app app monitor kernel kernel host kernel HW HW
  • 23. "All problems in computer science can be solved by another level of indirection." -- David Wheeler --
  • 24. Virtual Machine • Gerald Popek and Robert Goldberg defined it as “efficient, isolated duplicate of a real machine” – Add Virtualizing Software to a Host platform and support Guest process or system on a Virtual Machine (VM) The software that provides this illusion is the Virtual Machine Monitor (VMM, mostly used synonymous with Hypervisor)
  • 25. Virtual Machine for Portability (in the past) PowerPC x86 x86-32 HP –PA programs programs programs programs Rosetta FX!32 IA-32 Aries (Apple) (DEC) (Intel) (HP) x86-32 DEC IA-64 IA-64 or x86-64 Alpha (Itanium) (Itanium)
  • 26. Virtual Machine for Portability NOTE: we won't discuss such topic in this presentation x86 programs C LLVM IR Bytecode DEC IA-64 PowerPC SUN Alpha (Itanium) Sparc ARM
  • 27. System Virtual Machine • Provide a system environment • Constructed at ISA level • Allow multiple OS environments, or support time sharing. • virtualizing software that implements system VM is called as VMM (virtual machine monitor) • Examples: – IBM VM/360, VMware, VLX, WindRiver Hypervisor, ENEA Hypervisor – Xtratum, Lguest, BhyVe (BSD Hypervisor) – Xen, KVM, OKL4, Xvisor, Virtual network communication Codezero NOTE: We only focus on system virtual machine here. Therefore, this presentation ignores Linux vserver, FreeBSD jail, etc.
  • 28. Virtualization is Common Technique • Example: In the past, Linux is far from being real- time, but RTLinux/RTAI/Xenomai/Xtratum attempted to "improve" Linux by introducing new virtualization layer. • real-time capable virtualization • Dual kernel approach Bare metal (RT) Hypervisor Hardware RTOS Linux
  • 29. Example: Xenomai (Linux Realtime Extension) Linux application VxWorks application POSIX application glibc glibc Xenomai glibc Xenomai libvxworks libpthread_rt System calls VFS Network Xenomai RTOS Pieces added (nucleus) by Xenomai Memory ... Linux kernel space Xenomai Adeos I-Pipe skins • From Adeos point of view, guest OSes are prioritized domains. • For each event (interrupts, exceptions, syscalls, etc...), the various domains may handle the event or pass it down the pipeline. Source: Real-time in embedded Linux systems, Free Electrons (2011)
  • 30. Windows Apps Linux Apps • Type I MS- Linux • Bare metal system VM Windows VMM or Hypervisor Physical Machine General Classification of Virtualization technologies Windows Apps Linux Apps • Type 2 MS- Windows • Hosted System VM VM Linux Physical Machine
  • 31. Source: Operating Systems Design – Lecture 21 Virtualization, Roy Campbell (Fall 2010)
  • 32. Myth of Type I and Type II Hypervisor source: http://gala4th.blogspot.com/2011/10/myth-of-type-i-and-type-ii-hypervisors.html • Myth: Type-2 is "lesser" than a true "type-1" hypervisor. • Virtualization theory really started with a paper from Gerald Popek and Robert Goldberg called Formal Requirements for Virtualizable Third Generation Architectures. (1974) – Sensitive Instructions – Privileged Instructions • The terms "type-1" and "type-2" originate from a paper by John Robin called Analyzing the Intel Pentium's Capability to Support a Secure Virtual Machine Monitor. (USENIX 2000) ● Popek/Goldberg proof does not eliminate the possibility of using dynamic translation
  • 33. Virtualizable is a property of the Instruction Set Architecture (ISA) • A sensitive instruction • A privileged instruction – changes the – must be executed with configuration or mode of sufficient privilege the processor, – causes a trap in user or mode – depends in its behavior on the processor’s state If all sensitive instructions are privileged, a VMM can be written.
  • 34. System Virtualization Implementations Full Para Hardware Assisted Virtualization Virtualization Virtualization
  • 35. Full Virtualization ● Everything is virtualized ● Full hardware emulation ● Emulation = latency
  • 36. Recall the definitions • Sensitive Instructions as defined by "Formal Requirements for Virtualizable Third Generation Architectures” (1974): – Mode Referencing Instructions – Sensitive Register/Memory Access Instructions – Storage Protection System Referencing Instructions – All I/O Instructions • Theorem about strict virtualizability by "Analyzing the Intel Pentium's Capability to Support a Secure Virtual Machine Monitor" (2000): – For any conventional third generation computer, a virtual machine monitor may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions.
  • 37. Privileged Instructions ● Privileged instructions: OS kernel and device driver access to system hardware ● Trapped and Emulated by VMM – execute guest in separate address space in unprivileged mode – emulate all instructions that cause traps
  • 38. 0x1C FIQ 0x18 IRQ 0x14 (Reserved) 0x10 Data Abort Current Visible Registers 0x0C Prefetch Abort r0 0x08 Software Interrupt Undef Mode Abort Mode SVC Mode IRQ Mode FIQ Mode User Mode r1 0x04 Undefined Instruction r2 r3 0x00 Reset Banked out Registers r4 Vector Table r5 r6 User FIQ IRQ SVC Undef Abort r7 r8 r8 r8 r9 r9 r9 Banked out Registers r10 r10 r10 r11 r11 r11 r12 r12 r12 r13 (sp) r13 (sp) r13 (sp) r13 (sp) r13 (sp) r13 (sp) r13 (sp) r14 (lr) r14 (lr) r14 (lr) r14 (lr) r14 (lr) r14 (lr) r14 (lr) r15 (pc) cpsr spsr spsr spsr spsr spsr spsr
  • 39. r0 r8 r1 r9 31 0 r2 r10 r3 r11 CPSR r4 r12 r5 r13 NZCV r6 r14 r7 r15 (PC) Link register unbanked registers banked registers Every arithmetic, logical, or shifting operation may set CPSR (current program statues register) bits: ● N (negative), Z (zero), C (carry), V (overflow). Examples: ● -1 + 1 = 0: NZCV = 0110. ● 231-1+1 = -231: NZCV = 0101.
  • 40. ARM Architecture (armv4) • 6 basic operating modes (1 user, 5 privileged) • 37 registers, all 32 bits wide – 1 program counter – 5 dedicated saved program status registers – 1 Current program status register (PSR) – 30 general purpose registers • Special usage – r13 (stack pointer) – r14 (link register) – r15 (program counter, PC) 40
  • 41. Typical ARM instructions (armv4) • branch and branch with Link (B, BL) • data processing instructions (AND, TST, MOV, …) • shifts: logical (LSR), arithmetic (ASR), rotate (ROR) • test (TEQ, TST, CMP, CMN) • processor status register transfer (MSR, MRS) • memory load/store words (LDR, STR) • push/pop Stack Operations (STM, LDM) • software Interrupt (SWI; operating mode switch) • co-processor (CDP, LDC, STC, MRC, MCR) 41
  • 42. Problematic Instructions (1) • Type 1 Instructions which executed in user mode will cause undefined instruction exception • Example MCR p15, 0, r0, c2, c0, 0 Move r0 to c2 and c0 in coprocessor specified by p15 (co-processor) for operation according to option 0 and 0 – MRC: from coproc to register – MCR: from register to coproc • Problem: – Operand-dependent operation Source: 前瞻資訊科技 – 虛擬化 , 薛智文 , 台大資訊所 (2011)
  • 43. Problematic Instructions (2) • Type 2 Instructions which executed in user mode will have no effect • Example MSR cpsr_c, #0xD3 Switch to privileged mode and disable interrupt 31 Program Status Register (PSR) 0 N Z C V Q -- J -- GE[3:0] -- E A I F T M[4:0] Execution Exception Execution Flags Mask Mode
  • 44. Problematic Instructions (3) • Type 3 Instructions which executed in user mode will cause unpredictable behaviors. • Example MOVS PC, LR The return instruction changes the program counter and switches to user mode. • This instruction causes unpredictable behavior when executed in user mode.
  • 45. ARM Sensitive Instructions • Coprocessor Access Instructions MRC / MCR / CDP / LDC / STC • SIMD/VFP System Register Access Instructions VMRS / VMSR • TrustZone Secure State Entry Instructions SMC • Memory-Mapped I/O Access Instructions Load/Store instructions from/into memory-mapped I/O locations • Direct (Explicit/Implicit) CPSR Access Instructions MRS / MSR / CPS / SRS / RFE / LDM (conditional execution) / DPSPC • Indirect CPSR Access Instructions LDRT / STRT – Load/Store Unprivileged (“As User”) • Banked Register Access Instructions LDM/STM (User mode registers)
  • 46. Solutions to Problematic Instructions [ Hardware Techniques ] • Privileged Instruction Semantics dictated/translated by instruction set architecture • MMU-enforced traps – Example: page fault • Tracing/debug support – Example: bkpt (breakpoint) • Hardware-assisted Virtualization – Example: extra privileged mode, HYP, in ARM Cortex-A15
  • 47. Solutions to Problematic Instructions [ Software Techniques ] Binary Complexity Hypercall translation Design High Low Implementation Medium High Runtime High Medium Mapped to programming Virtual function Normal function languages Method: trap and emulate
  • 48. Dynamic Binary Translation Translation Basic Block BL TLB_FLUSH_DENTRY_NEW … TLB_FLUSH_DENTRY: BL TLB_FLUSH_DENTRY MCR p15, 0, R0, C8, C6, 1 … MOV PC, LR TLB_FLUSH_DENTRY: … MCR p15, 0, R0, C8, C6, 1 TLB_FLUSH_DENTRY_NEW: MOV PC, LR MOV R1, R0 … MOV R0, #CMD_FLUSH_DENTRY SWI #HYPER_CALL_TLB • ARM has a fixed instruction size – 32-bit in ARM mode and 16-bit in Thumb mode • Perform binary translation – Follow control-flow – Translate basic block (if not already translated) at the current PC – Ensure interposition at end of translated sequence – All writes (but not reads) to PC now become problematic instructions – Replace problematic instructions 1-1 with hypercalls to trap and emulate → self-modifying code
  • 49. Virtualization APIs – hypercalls /* In Hypervisor */ /* In Guest OS */ SWI Handler BL TLB_FLUSH_DENTRY … TLB_FLUSH_DENTRY: Hypercall Handler MOV R1, R0 …… MOV R0, #CMD_FLUSH_DENTRY SWI #HYPER_CALL_TLB … LDR R1, [SP, #4] MCR p15, 0, R1, C8, C6, 1 Restore User Context & PC • Use trap instruction to issue hypercall • Encode hypercall type and original instruction bits in hypercall hint • Upon trapping into the VMM, decode the hypercall type and the original instruction bits, and emulate instruction semantics mrs Rd, R <cpsr/spsr> mrs r8, cpsr swi 0x088000
  • 50. Hypercall Guest OS Hypercalls Software Interrupt No Yes Reschedule ? context switch Hypervisor Hyper Call Handler SWI Handler
  • 51. Hypercall in xen-i386 System Call int 0x80 01 // linux/include/asm/unistd.h 02 03 #define __NR_restart_syscall 0 Guest OS Hypervisor 04 #define __NR_exit 1 05 #define __NR_fork 2 06 #define __NR_read 3 07 … HYPERVOSIR_sched_op int 82h hypercall Hypercall_table do_sched_op iret Hyper Call int 0x82 01 // xen/include/public/xen.h resume Guest OS 02 03 #define __HYPERVISOR_set_trap_table 0 04 #define __HYPERVISOR_mmu_update 1 05 #define __HYPERVISOR_set_gdt 2 06 #define __HYPERVISOR_stack_switch 3 07 …
  • 52. Case study: Xvisor-ARM https://github.com/xvisor • File: arch/arm/cpu/arm32/elf2cpatch.py – Script to generate cpatch script from guest OS ELF • Functionality before generating the final ELF image – Each sensitive non-priviledged ARM instruction is converted to a hypercall. – Hypercall in ARM instruction set is SVC <imm24> instruction. – Encode sensitive non-priviledged instructions in <imm24> operand of SVC instruction. (software interrupt) – Each encoded instruction will have its own unique inst_id. – The inst_field for each encoded sensitive non-priviledged instruction will be diffrent.
  • 53. How does Xvisor handle problematic instructions like MSR? • Type 2 Instructions which executed in user mode will have no effect • Example MSR cpsr_c, #0xD3 Switch to privileged mode and disable interrupt 31 Program Status Register (PSR) 0 N Z C V Q -- J -- GE[3:0] -- E A I F T M[4:0] Execution Exception Execution Flags Mask Mode
  • 54. First, cpatch (ELF patching tool) looks up the instructions... MSR cpsr_c, #0xD3 Switch to privileged mode and disable interrupt # MSR (immediate) # Syntax: # msr<c> <spec_reg>, #<const> # Fields: # cond = bits[31:28] # R = bits[22:22] # mask = bits[19:16] # imm12 = bits[11:0] # Hypercall Fields: # inst_cond[31:28] = cond # inst_op[27:24] = 0xf # inst_id[23:20] = 0 # inst_subid[19:17] = 2 # inst_fields[16:13] = mask # inst_fields[12:1] = imm12 # inst_fields[0:0] = R
  • 55. # MSR (immediate) # Syntax: # msr<c> <spec_reg>, #<const> # Fields: # cond = bits[31:28] # R = bits[22:22] # mask = bits[19:16] # imm12 = bits[11:0] # Hypercall Fields: # inst_cond[31:28] = cond # inst_op[27:24] = 0xf # inst_id[23:20] = 0 def convert_msr_i_inst(hxstr): # inst_subid[19:17] = 2 # inst_fields[16:13] = mask hx = int(hxstr, 16) # inst_fields[12:1] = imm12 inst_id = 0 # inst_fields[0:0] = R inst_subid = 2 cond = (hx >> 28) & 0xF Xvisor utilizes cpatch to convert R = (hx >> 22) & 0x1 mask = (hx >> 16) & 0xF all problematic instructions for OS imm12 = (hx >> 0) & 0xFFF image files (ELF format). rethx = 0x0F000000 rethx = rethx | (cond << 28) rethx = rethx | (inst_id << 20) rethx = rethx | (inst_subid << 17) rethx = rethx | (mask << 13) rethx = rethx | (imm12 << 1) rethx = rethx | (R << 0) return rethx
  • 56. Requirements of real Hypervisor • VMM at higher privilege level than VMs – CPU Virtualization – Memory Virtualization – Device & I/O Virtualization • User and System modes • Privileged instructions only available in system mode – Trap to system if executed in user mode • All physical resources only accessible using privileged instructions – Including page tables, interrupt controls, I/O registers
  • 57. Memory Virtualization • Deal with allocation of Physical memory among Guest OS • RAM space shares among Guest OS • Processors with memory virtualization support is expecting in 2nd generation processors (Intel VT and ARM Cortex-A15)
  • 58. Device and I/O Virtualization • Deal with routing of I/O requests between virtual devices and the shared physical hardware • Similar to the single I/O device shared concurrently among different applications. • Hypervisor virtualizes the physical hardware and present each virtual machine with a standard set of virtual devices
  • 59. Paravirtualization • OS or system devices are virtualization aware • Requirements: – OS level – translated/modified kernel – Device level – paravirtualized or “enlightened” device drivers
  • 60. Paravirtualization • Why all the trouble? Just “port” a guest operating system to the interface of your choice. • Paravirtualization can – provide better performance – simplify VMM • but at a maintainance cost and you need the source code – Compromise: Use paravirtualized drivers for I/O performance (KVM virtio, VMware). • Examples: MkLinux, L4Linux, Xen, . . .
  • 61. Paravirtualization • Paravirtualization can also be semi-automated: – Sensitive instructions are automatically identified (in compiler output). – Sensitive memory access needs to manually identified. – Leave markers in binary. – On VM load-time, VMM replaces instructions with emulation code. – In-Place VMM translates to hypervisor calls. • Benefits: – less effort than plain paravirtualization – comparable speed
  • 62. Hardware-assisted Virtualization ● Hardware is virtualization aware ● Hypervisor and VMM load at Ring -1 ● Remove CPU emulation bottleneck ● Provides address bus isolation
  • 63. Hardware-assisted Virtualization ● VMM coordinates direct hardware access ● Memory virtualization solved in 2nd generation hardware assisted platforms ● Passthrough I/O has limited use cases without IOV (I/O Virtualization) http://www.pcisig.com/specifications/iov/
  • 64. Hardware-assisted Virtualization in x86 • VT technology enables new execution mode (VMX-Root Mode in x86 by Intel) in the processors to support virtualization • Hypervisor runs in a root mode below Ring0 • OS requests trap VMM without binary translation or PV • Specialized Hardware support is required • A special CPU privileged mode is to be selected to support
  • 65. Hardware-assisted Virtualization in ARM • Enable new execution mode Hypervisor (HYP) • Hypervisor runs in a Hypervisor (HYP) mode • Guest OS Runs in Supervisory Control (SVC) mode • Applications runs in User (USR) mode
  • 66. Virtualization: Third Privilege • Guest OS same kernel/user privilege structure • HYP mode higher privilege than OS kernel level • VMM controls wide range of OS accesses • Hardware maintains TZ security (4th privilege) Non-secure State User Mode Secure State (Non-privileged) 1 App1 App2 App1 App2 Secure Apps Exception Returns Supervisor Mode Secure Guest OS #1 Guest OS #2 (Privileged) 2 Exceptions OS Hyp Mode 3 Virtual Machine Monitor / Hypervisor (More Privileged) TrustZone Secure Monitor (Highest Privilege)
  • 67. Virtualization Extensions: The Basics • New Non-secure level of privilege to hold Hypervisor – Hyp mode • New mechanisms avoid the need Hypervisor intervention for: – Guest OS Interrupt masking bits – Guest OS page table management – Guest OS Device Drivers due to Hypervisor memory relocation – Guest OS communication with the interrupt controller (GIC) • New traps into Hyp mode for: – ID register accesses and idling (WFI/WFE) – Miscellaneous “difficult” System Control Register cases • New mechanisms to improve: – Guest OS Load/Store emulation by the Hypervisor – Emulation of trapped instructions through syndromes
  • 68. Memory – the Classic Resource • Before virtualization: the OS owns the memory – Allocates areas of memory to the different applications – Virtual Memory commonly used in “rich” operating systems Virtual address map of Translations Physical Address Map from each application translation table (owned by the OS)
  • 69. Virtual Memory in Two Stages Stage 1 translation owned by each Guest OS Stage 2 translation owned by the VMM Hardware has 2-stage memory translation Tables from Guest OS translate VA to IPA Second set of tables from VMM translate IPA to PA Allows aborts to be routed to appropriate software layer Physical Address (PA) Map Virtual address (VA) map of “Intermediate Physical” address each App on each Guest OS map of each Guest OS (IPA)
  • 70. Classic Issue: Interrupts • An Interrupt might need to be routed to one of – Current or different Guest OS – Hypervisor – OS/RTOS running in the secure TrustZone environment • Basic model of the ARM virtualization extensions – Physical interrupts are taken initially in the Hypervisor – If the Interrupt should go to a Guest OS, Hypervisor maps a “virtual” interrupt for that Guest OS App1 App1 App2 App2 App1 App1 App2 App2 Virtual App1 App1 App2 App2 Interrupt Guest OS 11 Guest OS Guest OS 22 Guest OS Operating System Operating System VMM VMM Physical Physical Interrupt Interrupt System without virtualization System with virtualization
  • 71. Virtual interrupt example • External IRQ (configured as virtual by the hypervisor) arrives at the GIC • GIC Distributor signals a Physical IRQ to the CPU • CPU takes HYP trap, and Hypervisor reads the interrupt status from the Physical CPU Interface • Hypervisor makes an entry in register list in the GIC • GIC Distributor signals a Virtual IRQ to the CPU • CPU takes an IRQ exception, and Guest OS running on the virtual machine reads the interrupt status from the Virtual CPU Interface Virtual Virtual IRQ External CPU Guest OS Interrupt source Interface Distributor Physical CPU CPU Hypervisor Physical IRQ Interface
  • 72. Spanning Hypervisor Framework ARM Non-Secure Execution Environment ARM Secure Execution Environment Platform Resources SoC NoC User A A A A Secured SoC Management sMMU Exception Level P P P P Services Management Domains (Application P P P P Domain Domain (ST/TEI) Coherence Layer) API API Resource API Kernel/Supervisor RTOS/uKernel Open OS Open OS Exception Level Para-virtualization & Drivers (Linux) with platform service API’s Secured Driver (OpenMP RT) Resource Driver Virtualized TZ Call hardware timer Virtualized TZ Call (tick) HYP(ervisor) Exception Level Open Platform Hypervisor Full Virtualization (KVM) Accelerators Virtualized Heterogeneous (DSP / GPU) TZ Monitor Exception Level TrustZone Monitor Source: Hardware accelerated Virtualization in the ARM Cortex™ Processors, John Goodacre, ARM Ltd. (2011)
  • 73. What does Hypervisor looks like • Thin layer of software running on the hardware • Supports creation of partitions • Each partition is a virtual machine • Each partition has one or more virtual processors • Partitions can own or share hardware resources • Software running in partition is called a guest • Enforces memory access rules • Enforces policy for CPU usage • Virtual processors are scheduled on real processors • Enforces ownership of other devices • Provides simple inter-partition messaging Parent Partition • Messages appear as interrupts • Exposes simple programmatic interface called (Minimum Footprint “hypercalls” Operating System) Hypervisor Ethernet Hard Disk CPU RAM NIC
  • 74. Monolithic vs. Microkernel Monolithic hypervisor Microkernel based ● Simpler than a modern hypervisor kernel, but still complex ● Simple partitioning ● Contains its own drivers functionality model ● Increase reliability and minimize TCB ● No third-party code ● Drivers run within guests VM 1 VM 1 VM 2 VM 3 (“Parent”) (“Admin”) Virtual- VM 2 VM 3 ization (“Child”) (“Child”) Stack Drivers Drivers Drivers Drivers Drivers Drivers Hypervisor Drivers Drivers Drivers Drivers Drivers Drivers Hypervisor Hardware Hardware
  • 75. Virtualization Stack • Collection of user-mode and kernel-mode components WMI • Runs within a partition on top of a (minimal) OS Provider • Contains all VM support not in the hypervisor VM Worker VM Worker • Interacts with hypervisor VM Service VM Worker Process Process • Calls the hypervisor to perform certain actions Process • Responds to messages from the hypervisor or from other partitions • Creates and manages a group of “child partitions” • Manages memory for child partitions • Virtualizes devices for child partitions Virtualization • Exposes a management interface Infrastructure VMBus Driver Bus Driver Parent Hypervisor API & Partition Message Library Child Partition 1 Child Partition 2 Hypervisor
  • 76. Device Virtualization • Standard VSP (Virtualization service providers) – Storage: support difference drive chains – Network: provide virtualized network mechanism – Video: 2D/3D graphics w/ or w/o HW acceleration – USB: allow a USB device to be assigned to a partition – Input: keyboard, mouse, touchscreen – Time: virtualization for RTC hardware
  • 77. Device Virtualization • Physical devices • Managed by traditional driver stacks • Virtualization service providers • Virtualize a specific class of device • Expose an abstract device interface Storage Storage VSP • Run within the partition that owns the VSP corresponding physical device • Virtualization service clients Storage Storage Storage Storage • Consume virtualized hardware service Stack Stack Stack Stack • VMBus • Software “bus” (enumeration, hot plug, etc.) Storage Storage • Enables VSPs and VSCs to communicate Port Port VSC VSC efficiently Driver Driver • Uses memory sharing and hypervisor IPC Parent VMBus VMBus VMBus VMBus messages Partition Hypervisor Hypervisor Disk Disk
  • 78. Embedded Virtualization Issues • Memory footprint • Security – Increases size of Trusted Computing Base • Direct IO Access • Emulate IO • Virtual IO • Real-time support
  • 79. Direct I/O Access • Guest can directly access physical IO without host involvement – Native speed • IOMMU provides isolation and physical address translation (DMA) – Translation could be done with guest modifications • Issues: – IOMMU required for DMA isolation – Limited by number of physical IO devices – Guests must have device drivers – What about legacy guests on new hardware? – Breaks migration – IRQ delivery and routing
  • 80. Emulated I/O • Host software emulates guest IO accesses • Issues: – Must write software to (perfectly?) emulate hardware – Dramatic increase in IO latency – Host OS must have physical device drivers • Device driver availability, licensing concerns
  • 81. Virtual I/O • No hardware at all, just inter-guest data transfer • New guest device drivers co-operate with host • Issues: – Requires guest modification (at least new device drivers) – Host OS still needs physical IO drivers
  • 83. Embedded Hypervisors for ARM (open source part) • Xen – Xen-arm, contributed by Samsung ARM9, ARM11, ARM Cortex-A9 MP – Xen-arm-cortext-a15, contributed by Citrix - https://lkml.org/lkml/2011/11/29/265 ARM Cortex-A15 • OKL4 (from open to close source), OKLabs • L4Linux, TU Desden • KVM ARM porting – Columbia University – NTHU, Taiwan • Xvisor: supports ARMv5, ARMv7, ARMv7+VE • Codezero
  • 84. Xen-ARM (Samsung) Goals Lightweight virtualization for secure 3G/4G mobile devices  High performance hypervisor based on ARM processor  Fine-grained access control fitted to mobile devices Architecture of Xen ARM VM 0 VM n Application Lightweight Xen- Application Application Tools Application Guest Backend Drivers Frontend Drivers Domain Native Drivers VM Interface VM Interface Secure Xen ARM Domain Resource Access Hypervisor Manager Allocator Control Hardware Peripheral CPU System UART Devices Memory
  • 85. Overview Xen-ARM (Samsung) Logical mode  CPU virtualization split  Virtualization requires 3 privilege CPU levels, but ARM supports 2 levels Xen ARM mode  Xen ARM mode: supervisor mode ( most privileged level) virtual kernel mode  Virtual kernel mode: User mode ( least privileged level) virtual user mode  Virtual user mode: User mode ( least privileged level) VM 2 Xen ARM  Memory virtualization VM 0 VM 1 VM 2 Address Address Address VM 1  VM’s local memory should be Spaces Spaces Spaces Kernel VM 0  protected from other VMs User Process Process User Process User Process User Xen ARM  Xen ARM switches VM’s virtual address space MMU Physical Virtual  using MMU Xen ARM Address Space Address Space  VM is not allowed to manipulate MMU directly VM0 (Linux) VM1 (Linux )  I/O virtualization Application Application Application Application Application Application  Split driver model of Xen ARM Native Back-end Front-end  Client & Server architecture for shared I/O devices driver driver driver  Client: frontend driver Interrupt I/O event  Server: native/backend driver Xen ARM Device
  • 86. • Xen without assisted hardware VM
  • 87. • Xen with assisted hardware VM
  • 88. Micro-hypervisor • Microvisor – OKL4 4.0 • Research projects such as NOVA, Coyotos, and seL4 • Microhypervisor • VMM – “the kernel part” – “the userland part” – provides isolation – CPU emulation – mechanisms, no policies – device emulation – enables safe access to – virtualization features to userspace
  • 90. Source: VIRTUALIZATION, Julian Stecklina, TU Dresden
  • 91. Advantage of NOA architecture: Reduce TCB of each VM • Micro-hypervisor provides low-level protection domains – address spaces – virtual machines • VM exits are relayed to VMM as IPC with selective guest state • one VMM per guest in (root mode) userspace: – possibly specialized VMMs to reduce attack surface – only one generic VMM implemented
  • 92. Reference • 前瞻資訊科技–虛擬化 , 薛智文 , 台大資訊所 (2011) • ARM Virtualization: CPU & MMU Issues, Prashanth Bungale, vmware • Hardware accelerated Virtualization in the ARM Cortex™ Processors, John Goodacre, ARM Ltd. (2011) • Hypervisors and the Power Architecture http://www.techdesignforums.com/embedded/embedded-topics/embedded-development- platforms/hypervisors-and-the-power-architecture/ • Philippe Gerum, State of Real-Time Linux: Don't Stop Until History Follows, ELC Europe 2009