1. KVM/ARM: The Design and Implementation of the Linux ARM Hypervisor Christoffer Dall Department of Computer Science Columbia University Jason Nieh Department of Compouter Science Columbia University
김해천

2. ARM ~1.2 billion ~300 million 논문에서 ARM에 대한 내용을 서술하기에 간단히 소개를 하겠습니다.
저전력과 함께, RISC의 cpu의 대표로 각광받고 있습니다.

3. ARM ARM Server ARM Network infrastructure
뿐만 아니라 ARM을 이용한 SERVER, Network 기반 시스템까지 영역을 확장해 가고 있습니다.

4. Virtualization Extensions
Key Challenges
ARM
Virtualization Extensions
intel
VT-x !=
지금까지 우리가 intel cpu위에서 흔히들 vmware, virtual machine, xen등을 사용하였는데,
Intel cpu는 기본 하드웨어대한 표준이 존재하여, 편하게 사용해왔던 만큼, 가상화도 상대적으로 쉽게 이루어졌습니다.
하지만 ARM은 여러 제조사에서 각 회사에 특성에 맞게 application processor라는 기존 arm core만 놔둔체
새로 디자인 되어서 사용되었습니다. 그래서 하드웨어의 특성을 이용하여 가상화하는데 어려움이 있었습니다.
No PC-standard on ARM

5. Hypervisor Layering in software stack
Type 1
HyperOne, Xen, PikeOS, OKL4,
Hyper V, Vmware ESX
Type 2
KVM, VirtualBox, Virtual PC,
Parallels, BlueStacks
Hypervisor를 크게 나누어보면 H/W에 Hypervisor를 올리고 그 위에 virtual machin들을 올리는 방법과
KVM, Kernel-based Virtual Machine 라는 이름처럼 os kerne에 hypervisor를 포함시키는 방법이 있습니다.
점점 가상화를 사용 범위가 확대 되고, 가상화를 위한 H/W의 성능이 향상됨에 따라서 KERNEL에 기본적으로
Hypervisor를 포함시키는 방향으로 가상화 방식이 흘러갈 것이라는 예측이 있습니다.

6. ARM Virtualization Extensions
Provides virtualization in 4 key areas:
CPU Virtualization
Memory Virtualization
Interrupt Virtualization
Timer Virtualization
ARM 가상화의 주요 영역은, cpu, 메모리, 인터럽트, 그리고 타이머가 되겠습니다.

7. ARM Virtualization Extensions CPU Virtualization
ARM introduces a new CPU mode for running hypervisors called Hyp mode
Hyp mode was introduced as a trap and emulate mechanism to support virtualization
Giving control to the hypervisor, manage the h/w, provide the required isolation
User
User
ARM은 하이퍼바이저가 수행되는 hyp mode라는 새로운 cpu mode를 소개하였습니다.
Hyp 모드는 가상화를 위한 하드웨어의 트랩을 처리하고, vm들에게 하드웨어를 emulate해주는 역할을 합니다.
그리고 하이퍼 바이저에게 하드웨어에 대한 컨트롤 권한을 주고, 하드웨어를 관리함으로써 vm들의 isolation도 제공해 줄 수 있습니다.
하지만 vm들의 시스템 콜이나, 페이지 폴트 같은 몇몇 트렙들은 하이퍼 바이저를 거치지 않고 vm의 커널에게 직접 트랩을 걸면서
하이퍼바이저를 트랩하면서 발생하는 오버헤드를 줄일 수 있습니다.
Kernel
Kernel
Hyp
H/w

8. ARM Virtualization Extensions memory virtualization
Hardware support to virtualize physical memory: stage 2 Page Tables
Arm은 또한 물리메모리를 가상화하는데, 두 단계의 page table을 통하여 실제 물리 메모리를 ipa라는 intermediate physical address로 변환 후, 다시 vm에게 virtual addres를 제공해줍니다.
가상화 여부에 따라 하이퍼 모드에서 인에이블 디세이블 또한 가능합니다.

9. ARM Virtualization Extensions Interrupt virtualization
One distributor in a system, but each CPU core has a cpu Interface
Distributor is used to configure the GIC(general interrupt controller)
CPU interface is used to acknowledge(ACK) and to signal End-Of-
Interrupt(EOI)
Interrupt can be configured to trap to either Hyp or Kernel mode
Trap to kernel : does not work in VMs, hypervisor loses control over the H/W
Trap to Hypervisor : hypervisor retain control, but big cost
☞ GIC v2.0 include H/W virtualization (VGIC)
Virtual CPU interface : raise the virtual interrupts directly to a vm’s kernel
List Register : special register, for generating the v interrupts
No longer need to trap to the hypervisor
Vgic cpu interface includes support for ACK and EOI
VGIC
그 다음은 ARM의 인터럽트 가상화입니다.
Gic라는 general interrupt conroller가 있는데 각 cpu에게 날라오는 인터럽트를 전달해주는 역할을 하고,
그 안에 disetributor는 각 인터럽트의 종류와 CPU의 상태에 따라 알맞게 해주는 역할을 합니다. 그리고 CPU가 인터럽트를 인지한 acknowledge 신호, 인터럽트의 끝인 EOI
신호를 사용합니다. 기존 방식에서 인터럽트를 커널모드와 HYP모드 각각 전달해줄 수 있었는데, 문제점은 커널에게 전달 시, 하드웨어에 대한 컨트롤을 hypervisor가 잃어버려서
Vm안에서 동작하지 않은 문제점이 있었습니다. 그래서 인터럽트에 대한 트랩을 하이퍼바이저에게 전달해 주어야 했는데, 이는 많은 cost를 야기했습니다.
그래서 GIC v2.0에서 VIRTUAL GIC를 추가하였고, 이러한 문제를 해결했습니다.
PPI: Private Peripheral Interrupts
SPI: Shared Peripheral Interrupts SGI: Soft Generated Interrupt
GIC : Generic Interrupt Controller

10. ARM Virtualization Extensions Interrupt virtualization
Generic Interrupt Controller : Trapping Interrupt in Hyp Mode Vm
3) Emulate Virtual Interrupt By signal
Hypervisor
Cumbersome & Expensive
2) trap
1) interrupt
H/W

11. ARM Virtualization Extensions Interrupt virtualization
Generic Interrupt Controller (V2.0) , Virtual GIC : Trapping Interrupt in Kernel Mode Vm
Hypervisor
2) trap
Good
1) interrupt
H/W

12. ARM Virtualization Extensions Timer virtualization
ARM define the Generic Timer Architecture
The timers used by the hypervisor cannot be directly configured and manipulated by guest OSes.
Such timer accesses from guest OS would need to trap to Hyp mode, incurring additional overhead
Timer 0
CPU 0
Timer 1
CPU 1
Accessible from Hyp mode
counter
Timer 2
CPU 2
Timer 3
CPU 3
기존의 타이머는 직접적으로 게스트 오에스들이 사용할 수 없었고. 접근하게 되면, HYP mode에 trap을 야기 하였습니다.
그래서 ARM에서 virtual counte와 virtual timer를 사용할 수 있게 하여 각 virtual cpu에서 직접 사용할 수 있게 되었습니다.
Virtual counter
Virtual Timer 0
Virtual CPU 0
Virtual counter
Virtual Timer 1
Virtual CPU 1
ARM provides ☞
Accessible from VMs
Virtual counter
Virtual Timer 2
Virtual CPU 2
Virtual counter
Virtual Timer 3
Virtual CPU 3

13. Hypervisor Architecture
KVM/ARM builds on KVM and leverages existing infrastructure in the Linux kernel
Bare metal hypervisor(xen) vs KVM/ARM
ARM platform designs are non-standard ways by different manufactures
Samsung exynos, qualcomm snapdragon, Apple A series
But, Linux is supported across almost all ARM platform ☞ by integrating KVM/ARM with Linux
PL0 User
하이퍼바이저 architectur에 대해 소개하겠습니다.
KVM/ARM은 기존의 x86을 위해 설계된 KVM위에 만들어졌고, 기존 리눅스 커널을 기반들을 사용합니다.
XEN도 ARM의 가상화를 지원하고 있지만, ARM platform의 표준화가 없어서 소스를 각각에 맞게 수정해야 하는 문제점이 있었습니다.
하지만 리눅스 커널은 이미 거의 모든 ARM platfor을 지원하고 있어서, 기존 리눅스 커널을 이용한 KVM/ARM이 어떤 수정없이 ARM을 지원할 수 있게 되었습니다.
PL1 Kernel
PL2 Hyp
Linux kernel KVM

14. Hypervisor Architecture Split-mode Virtualization
Running KVM/ARM in Hyp mode implies running the Linux kernel in Hyp mode
This is problematic
Low-level architecture dependent code in Linux is written to work in kernel mode
Running the entire kernel in Hyp mode would adversely affect native performance
Kernel
KVM/ARM이 커널을 이용한다고 했는데 커널이 하이퍼바이저를 위한 HYP mode에서 수행된다면 이는 문제가 될 것 입니다.
아키텍쳐에 종속적인 코드들이 커널 모드에서 수행되도록 작성되어 있고, 커널을 hyp mode에서 수행되는것은 부정적인 퍼포먼스를 야기할 것입니다.
Kernel mode ?
Kernel
Hyp mode

15. Hypervisor Architecture Split-mode Virtualization
KVM/ARM introduces split-mode virtualization
It runs across different privileged CPU mode to take advantage offered by each CPU mode
Two components, the lowvisor and the highvisor
Lowvisor takes advantage of the H/W virtualization support available in Hyp mode
Set up the correct execution context by configuration of the H/W
Enforce protection and isolation between different execution context
Switch from a VM execution context to the host execution, vice versa
Provide a virtualization trap handler
Highvisor can directly leverage existing Linux functionality
Scheduler, kernel data structure, locking, memory allocation functions
Kernel mode
OS Kernel
Hypervisor
그래서 KVM/ARM은 split-mode virtualization을 소개하였습니다. 다른 특권 cpu mode에 걸쳐서 수행되도록 한 것인데, 각 cpu mode의 장점을 얻을 수 있습니다.
그리고 하이퍼바이저는 hyp mode쪽의 low visor, 커널 모드 쪽의 high visor로 나누어져 있습니다.
로우 바이저는 hyp mode에 존재하는 만큼, 하드웨어 가상화에 이점을 두고 있습니다.
하이바이저는 직접적으로 리눅스 커널의 기능들을 이용할 수 있게 되었습니다.
High
visor
Handles High level Functionality
Hyp
mode
Low
visor
Handles Low level Functionality

16. Hypervisor Architecture Split-mode Virtualization
Switching between a VM and the highvisor
OS Kernel
Hypervisor VM
Highvisor
Kernel mode
Run VM
Trap
Trap
하이바이저에서 vm으로 스위칭 되는 과정을 살펴보겠습니다.
로우바이저가 Vm으로 스위칭 시키는 역할을 하므로, 하이바이저에서 로우바이저로 trap이 일어나고, 다시 로우바이저에서 vm으로 trap이 일어나게 됩니다.
Hyp mode
Lowvisor

17. Hypervisor Architecture Split-mode Virtualization
Switching between a VM and the highvisor
OS Kernel
Hypervisor VM
Function call
Highvisor
Kernel mode
Trap
Trap
역으로 vm에서 하이퍼바이저로 switching 될 때도 두 번의 trap이 일어나게 됩니다.
Hyp mode
Lowvisor
As a result, split mode virtualization incurs a double trap cost in switching to and from the highvisor

18. Hypervisor Architecture CPU Virtualization
Register state not affecting VM isolation can simply be Context switched
S/W in the VM must have persistent access to same register state as S/W running on the physical CPU
Host
Hypervisor VM
ARM
physical H/W state associated with the hypervisor and its host kernel is persistent across running VMs
Virtualized cpu
hypervisor의 cpu 가상화에 대해 말씀 드리면 , 각 VM들은 가상화된 CPU위에서 수행되지만 실제 물리 CPU와 같은 register state들을 갖고 수행된다는 것입니다.
그리고 table1의 처럼 간단한 context switc만으로 여러 레지스터에 접근할 수 있게 되고, vm이 vm의 커널에 직접 접근 가능하기에 stage1 page table같은 경우 직접 접근이 가능합니다.
그리고 VM isolatio에 문제가 없다면 host와도 간단한 context switc가 이루어질 수 있습니다.
그렇지만 table 1dml trap-and emulate actio처럼 WFI같은 인스트럭션은 CPU를 정지하는 직접적인 하드웨어에 수행에 영향을 미치는 ACTION은 TRAP을 통해서 이루어지게 됩니다.
Controlled by the Hypervisor
trap
Performs trap and emulate on sensitive instruction and when accessing H/W state

19. Hypervisor Architecture Memory Virtualization
KVM/ARM provides memory virtualization by enabling Stage-2 translation
When running in a VM
Completely transparent to the VM
The highvisor manages the Stage-2 translation page tables to only allow access to memory allocated for a VM
Other accesses will cause stage-2 page faults which trap to the hypervisor
Stage-2 translation is disabled when running in the highvisor and lowvisor
KVM/ARM은 Stage-2 translatio을 이용하여 메모리 가상화를 합니다.
Vm이 실행되고 있어야하고, 이러한 translation을 vm은 알아차리지 못합니다. 그리고, 하이바이저는 stage-2 translatio을 관리하게 되고, 메모리가 할당된 vm에게만 접근을 허락합니다.
다른 vm의 접근은 page faullt를 야기하여 trap을 발생시킵니다. 그리고 당연히 highsor와 lowvisor가 수행시에는 stage-2 translatio이 필요없는 상황이므로 disable됩니다.

20. Hypervisor Architecture Memory Virtualization
Configuring page tables is a high level Functionality
OS Kernel
Hypervisor VM
Highvisor
Kernel mode
Stage -2 page table이란 IPA( Inter mediate page address)와 VM의 Virtual address의 변환을 위한 table입니다. 이를 highvisor가 관리하게 됩니다.
Hyp mode
Lowvisor
Configures Stage-2 Page Tables

21. Hypervisor Architecture Memory Virtualization
LowVisor has hardware access as it runs in Hyp Mode
OS Kernel
Hypervisor VM
Highvisor
Kernel mode
그리고 이러한 stage 2 translation을 arm h/w가 지원하는 것이므로, low visor가 하드웨어의 컨트롤을 갖고 있기에 로우 바이저가 이를 enable해줍니다.
Hyp mode
Lowvisor
Enables Stage-2 Translation

22. Hypervisor Architecture Memory Virtualization
get_user_pages()
OS Kernel
Hypervisor VM
Highvisor
Kernel mode
그리고 vm에서 page fault가 발생 시, 커널에서 관리하는 물리 address에서 page를 더 할당해주면 되므로, 일단 vm과의 state-2 translation이 disabl되고
기존의 리눅스에서 사용하는 get_user_pages를 호출하여 할당해주면 됩니다.
Page fault
Hyp mode
Lowvisor
Disables Stage-2
Translation

23. Hypervisor Architecture Interrupt Virtualization
When running in a VM or Host & highvisor
All, H/W interrupt processing is done in the host by using Linux’s existing interrupt handling func
However, VM must receive notifications in the form of virtual interrupt from emulated devices
KVM/ARM uses the VGIC
Multicore guest Oses musts be able to send virtual IPIs
to others
OS Kernel VM VM
Kernel mode
High
visor
먼저 VM을 수행하고 있을 때, H/W인터럽트가 하이퍼바이저로 들어오게 되고 VM에서 하이바이저로 world 스위치가 일어난다
그리고 host나 하이바이저를 수행하고 있을때 H/W인터럽트가 들어오게 되면, 바로 커널 모드로 트렙이 걸리게 되고
기존 리눅스의 인터럽트 핸들링을 이용하여 이를 처리하게 된다.
하지만 vm도 인터럽트를 받을 수 있어야 하는데, 이는 앞에서 설명한 KVM/arm의 GIC version2에서 VGIC를 사용하여 VIRTUAL 인터럽트 형태로 제공한다.
그래고 또한 멀티코어 환경에서 여러 OS들이 존재할 때 서로간의 INTER PROCESSOR INTERRUPTS를 보낼 수 잇어야 한다.
Low
visor
Hyp
mode
Trap
Trap
H/W

24. Hypervisor Architecture Timer Virtualization
KVM/ARM leverage ARM’s H/W virtualization features of the generic timer to
allow VMs direct access to reading counters and programming timers
Unfortunately, due to architectural limitations, the virtual timers cannot directly raise virtual interrupts
KVM/ARM detects when a Virtual timer expires and Injects
a corresponding virtual interrupt to the VM
OS Kernel VM VM
Kernel mode
High
visor
KVM/ARM은 타이머의 가상화를 이용합니다, virtual timer도 직접적으로 virtual interrup를 VM에게 줄 수 없는데,( 하드웨어 인터럽트는 항상 트랩을 통해 전달된다)
그리고 virtual timer의 시간이 끝나면 KVM/ARM이 이를 감지하고, VM에게 virtual 인터럽터를 넣어줍니다. 그리고, KVM/ARM이 ACK와 EOI를 수행해줍니다.
Prepare
Enable virtual timer
Low
visor
Hyp
mode
Hypervisor
trap
timer

25. Experimental Setup

26. Experimental Setup

27. - Cost of two world switch
Experimental Results
Table 3 presents costs of virtualization using KVM/ARM on ARM and KVM x86 on x86
Measured in cycle units
- Saving & restore VGIC state is quite expensive on ARM.
- x86 provides H/W support
Hypercall
- Cost of two world switch
Trap
- Cost of switching the h/w mode from the into the cpu mode bg bg bg

28. Experimental Results
Figure 3,4 show normalized performance for running lmbench in a VM versus Host
Updating the run queue clock in the Linux Scheduler
☞ Reading a counter traps to user space without vtimers
Lmbench : 메모리 레이턴시와 bandwidth 측정하는 밴치마크
lmbench is a suite of simple, portable, ANSI/C microbenchmarks for UNIX/POSIX. In general, it measures two key features: latency and bandwidth. lmbench is intended to give system developers insight into basic costs of key operations. Supports-
Repeatedly sending an IPI, Cost of KVM is higher than KVM/ARM
Because this require trapping to the hypervisor on x86 but not on ARM
KVM/ARM has less overhead than KVM x86 fork & exec
Without using VGIC/vtimer, KVM/ARM also incurs high over-head
UP: uni-processor
SMP:symmetrical multi-processing

29. Experimental Results
Figure 5,6 show normalized performance for running application workloads
More mature KVM x86 system has significantly higher virtualization overheads,
KVM/ARM’s split-mode virtualization design allows it to leverage ARM H/W support with comparable performance to traditional hypervisor using x86 H/W support

30. Experimental Results
Figure 7 shows normalized power consumption of using virtualization
As well as ARM, mac air’s i7 is one of Intel’s more power optimized processors
Both workloads are not CPU bound on both platforms & the power consumption is not significantly affected by the virtualization layer
However, due to ARM’s slightly higher virtualization overhead, the energy virtualization overhead is slightly higher

31. http://www. linux-kongress. org/2010/slides/KVM-Architecture-LK2010
esc2014chhypforarmv pdf
kvm/arm experiences building the linux arm hypervisor

33. VIRQ
Virtual CPU Interface
ACK
Virtual CPU Interface