Hardware accelerated virtualization in the ARM Cortex ... - Xen

More documents

Recommendations

Info

Virtual Memory in Two Stages Stage 1 translation owned by each Guest OS Virtual address (VA) map of each App on each Guest OS 8 Stage 2 translation owned by the VMM “Intermediate Physical” address map of each Guest OS (IPA) 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
Classic Issue: Interrupts � An Interrupt might need to be routed to one of: � Current or different GuestOS � Hypervisor � OS/RTOS running in the secure TrustZone environment � Basic model of the ARM virtualisation extensions: � Physical interrupts are taken initially in the Hypervisor � If the Interrupt should go to a GuestOS : � Hypervisor maps a “virtual” interrupt for that GuestOS Operating System 9 App1 App2 Physical Interrupt Virtual Interrupt Physical Interrupt App1 Guest OS 1 VMM App2 System without virtualisation System with virtualisation App1 Guest OS 2 App2
Page 1 and 2: Hardware accelerated Virtualization
Page 3 and 4: Large Physical Addressing � Corte
Page 5 and 6: How does ARM do Virtualization �
Page 7: Memory - the Classic Resource � B
Page 11 and 12: Virtual Interrupt Controller � Ne
Page 13 and 14: Virtual interrupt example � Exter
Page 15 and 16: Helping with Virtual Devices � AR
Page 17 and 18: Potential of System MMU 17
Page 19 and 20: Base Secure System � Minimal Trus
Page 21 and 22: Propagating System Security NS : No
Page 23 and 24: ig.LITTLE Multi-Processing � “B
Page 25 and 26: ig.LITTLE Processing � Right size
Page 27 and 28: Forms of big.LITTLE � big.LITTLE
Page 29 and 30: Spanning Hypervisor Framework 29 AR

Hardware accelerated virtualization in the ARM Cortex ... - Xen

Create successful ePaper yourself

Delete template?

Save as template?