#10 Virtualization

기본적인 virtualization

파일도 virtualization / HDD와 SSD를 가상화 -> 구조를 세부적으로 알지 않아도 abstraction을 통해 기능 제공

실제로는 하나만 있는데, 가상으로 서로 다른 2개의 디스크가 있는 것 처럼 분할

 

"Machine"

Computational HW / Main Memory / IO devices / 이를 연결해주는 bus / Management SW / OS / Libraries / App

여러 관점이 있다.

 

System VM

OS와 HW 단 사이에 VMM / Hypervisor를 집어넣어 위에 위치한 SW 단에게 HW에 대한 illusion을 제공한다.

VMware, Xen, KVM 등

 

Process VMs

OS, library를 건들이지 않고 compiler와 software toolchain에 들어가있다.

App을 속이는 것이 목적

Language VM (JVM, CLR)

 

Co-designed VMs

HW단에 함께 딸려오는 VM

low-level code에 위치하며, microcode를 support하도록

dynamic binary translation을 CPU 안에 plant

 

이번 강의의 주 관점은 System VM이다.

---

Partitioning & Encapsulation

 

Consolidation

실제로 host OS에 있는 자원을 언제나 모두 사용하는 것이 아니므로, 다양한 어플리케이션을 한 곳으로 뭉쳐 machine 하나 위에서 돌아가게 하는 것

 

Encapsulation된 VM을 옮기거나 가져올 수 있다. (load balancing)

VM이 아예 없더라도 일부 power를 먹기 때문에 자원 관리가 중요하다.

 

VM을 보안목적으로 사용하기도 한다.

Network Function Virtualization (NFV)로 거쳐서 들어가도록 한다.

partitioning 자체의 isolation 활용, 한개의 오류가 다른 VM으로 전파되는 것 방지

 

Client Centralization

입출력만 말단 장치에서 담당하고, 주 연산은 서버에서 (RDP)

Virtual Desktop Infrastructure

Virtual Mobile Infrastructure

---

 

Embedded Devices (자동차)에서 필요한 Real-time OS (RTOS)

real-time system에서 VMM이 필수적인 이유 -> legacy support 측면 (탑재되는 OS와 App은 굉장히 안정적이어야 하기 때문에 업데이트가 느리다, 보수적 검증 기간이 길다)

반도체(HW)는 빠르게 발전하는 반면, 위의 SW는 느리게 발전한다.

 

Hypervisor Architecture와 Hosted Architecture가 공존하는 이유

Hypervisor 구조는 MS (Hyper-V)

그외는 Hosted 구조를 선택 (리눅스 계열들)

 

MS는 Windows OS 코드를 들고 있기 때문에 자연스럽게 적용될 수 있도록 Hypervisor를 만들 수 있다.

 

---

Full Virtualization

Virtualization transparent to gues OS & App

baremetal machine에 깔리는 것과 차이가 없다면 full virtualization이다.

 

Paravirtualization

OS를 일부 개조, OS와 협조하에 virtualization을 구현한다.

transparent to app but not guest OS

 

---

VMM이 자원을 나누는 방법

 

time multiplexing -> 시간 별로 나눠서 사용 (processor core)

resource partitioning -> 구역을 쪼개서 사용 (disk or memory)

Mediating HW interfaces -> time multiplexing은 특정 시간에 하나의 VM이 자원을 독점하고 있고, resource partitioning은 시간 관계 없이 특정 구역만 점유하고 있다면, 이 방식은 완전히 독점하는 것도 아니고, 분할 점유도 아니며, 중간에 VMM이 중재하에 VM의 요청을 전달하는 것

해당 자원들은 VMM이 소유한다.

 

몇 가지 방법을 적당히 섞어서 사용하게 된다.

 

---

Unmodified Guest

너무 큰 overhead. Guest가 중요한 call을 실행하려고 할 때마다 hypervisor에게 넘겨야 하는 구조

때문에 일부 modification을 가해서 좀 더 빠르게 하려는 시도가 있었다.

 

Guest OS가 Ring 1에서 돌아가게 한다면 Ring 0에서 돌아야 하는 privilege instruction에 대해서 exception이 생기게 된다.

syscall 같은 것도 잡혀들어올텐데 문제는 안 걸리는 특수한 instruction이 있다. (CLI, STI)

인터럽트를 받을지 말지를 결정하는 명령어

이들은 Ring 1에서도 돌 수 있는 instruction이기 때문에 VMM이 감지할 수 없는 문제가 있다.

 

NIC 카드에서 인터럽트를 받아도 VMM이 이를 알 수 없다면 처리를 할 수가 없기 때문에 이들은 VMM이 감지할 수 있도록 OS를 수정해서 알려준다. (Binary Translation)

Binary를 살펴본뒤, 특정 부분의 binary code를 바꿔서 modify

 

---

이제 HW support가 들어오면 좀 더 편해진다.

VMware는 HW 도움 없이 SW의 힘만으로 가상화를 구현한 것이 경쟁력이었는데 인텔이 개입

AMD도 비슷하게 개발

 

Ring -1을 도입한 것

일부 명령들을 ring -1로 권한을 변경해서 VMM의 도움을 구하도록 한것 (VMCS를 통해 configuration)

특정 부분이 건들여지면 VMM으로 jump할 수 있도록 한다. (VM Entry와 VM Exit)

 

VT-x를 통해 프로세서 가상화

한 개의 코어를 여러개가 있는 것처럼

---

Memory Virtualization Challenge

GV -> GP (HV) -> HP

VA -> PA -> MA

HW의 도움 없이는 Shadow Page Table을 유지하면서 변환을 할 수 밖에 없었다.

page table exception을 VMM이 낚아채서 demand paging을 한다.

guest OS까지 propagation 되어야 하는 때는 동적 할당을 했을 때 등

guest OS도 온전히 돌아가야 하기 때문에

이런저런 corner case를 고려할 필요가 있다.

 

Page fault는 굉장히 빈번하게 일어나기 때문에 성능상의 문제가 생길 수 밖에 없다.

때문에 intel이 Extended Page Table이라는 것을 운영하기 시작했다.

EPT는 PA -> MA로 변환하는 역할을 한다.

shadow page table에서는 VA -> MA가 한 번에 됐었는데 이번에는 traverse가 이중으로 일어나는 것이다.

shadow page table은 엔트리가 많았던 반면, EPT는 VM만큼만 있으면 되기 때문에 엔트리 숫자가 적다.

 

HW로 만들어놓으면 빨라질 것이라고 생각을 했는데....

굉장히 단계가 많다.

Traverse를 할 때 

CR3를 보고 인덱스를 찾아가서 테이블 내 엔트리를 사용해 다음 테이블로 진행하는데

이 테이블을 한 번 찾을 때마다 PA -> MA 번역이 한 번씩 소모된다. (EPTP, EPT base pointer 부터 시작)

 

때문에 TLB miss가 한 번 날 때마다 긴~ traverse를 해야한다.

translation이 너무 많은데 이걸 피할 방법이 정녕 없는가

traverse가 일어나는 것은 TLB miss가 났을 때

TLB hit이 많이 일어나면 따라갈 필요는 없다.

그렇다고 TLB의 크기를 무한정 늘릴 수는 없는 것이 HW 적으로 동시에 access하는 방식에서는 크기를 늘리면 속도가 떨어지기 때문에

 

따라서 tiered cache 방식으로 하거나, V -> M mapping을 큰 단위로 할 수 있도록 한다. (huge page)

그렇다고 모든 페이지를 이렇게 크게 잡으면 internal fragmentation으로 메모리가 낭비되므로 적정한 메모리 할당 방식이 요구된다.

 

---

IO device의 경우

예전에는 VMM이 proxy 역할을 하는 중재자 모델이 가장 널리 사용되었다.

근데 매번 이렇게 여러 syscall이 오가는 구조는 실시간성이 떨어진다.

IO port -> x86 instr을 보면 IN/OUT 명령어가 있는데, 

데이터가 왔다갔다 함에도 명령어는 따로 움직일 수 있도록

Memory Mapped Register : Address Mapping이 되어 있는 것에서 일부 가상 영역을 입출력 장치에 직접 연결

-> 자세히 알 필요는 없을듯

 

중요한 것은 이 과정의 overhead가 크다는 것. 그래서 HW support를 요청한다.

IO 장치는 매핑이 이중화됨에 따라 어디로 보내야할지 구체화하기가 어렵다.

그래서 초창기에는 hypervisor로 모두 던져서 hypervisor가 분류해주는 역할이었다.

 

그래서 나온 HW 가속화가 IOMMU이다.

IOMMU는 IO request에 들어가는 Physical Address를 Machine Address로 매핑해주는 역할을 한다.

DMA request가 들어오면 IOTLB를 보고 hit이 나면 번역하고 miss가 나면 page table traverse를 해야 한다.

문제는 어떤 페이지 테이블을 따라갈지, 즉 해당 request가 어떤 VM의 요청이었는지를 알아야 한다는 것인데, 이는 DMA request의 Device ID를 보고 판단한다. device assignment table에서 PTBR을 구한다.

 

저 device ID로 따라 가는 것도 traverse라 이를 caching 하는 것이 context cache이다.

 

요즘에는 더 발전해서 NIC 카드 자체를 가상화한다. 각 카드를 device ID와 1:1 매핑시켜서 더 빠른 탐색 및 주소 번역이 가능하도록 한다.

 

Interrupt Remapping 

 

HW support가 없을 때의 binary translation

요즘은 거의 다 HW support를 받는다.