SOSP 2003 https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf
개요
XEN의 원저자가 작성한 최초의 논문으로, 어떻게 XEN을 구현하였는지 저술한 논문이다. XEN은 Guest Operating System에 수정을 가하여 위와 같은 성질을 모두 이룰 수 있도록 하였다. Linux, Windows XP 그리고 NetBSD까지 모든 운영체제를 반가상화기법을 이용하여 빠르게 가상화 시켰다. Fork, Execv와 같은 시스템 콜로 프로세스를 형성시키는 것에 비해서 가상화된 운영체제를 돌리기 때문에 프로세스 대비 느리고, 리소스를 많이 먹는 다는 것이 프로세스 기반 가상화 기법대비 강력한 Isolation을 제공하나 Performance 측면에서의 단점이다.
Motivation
시스템을 가상화 시키는 것은 리소스를 효율적으로 사용하게 하며, 시스템 설정을 간편하게 하고, 그리고 다른 리소스와의 Isolation을 강력하게 실행하게 한다는 특징으로 인해서 하드웨어 가상화는 점점 중요한 Computing requirement가 되고 있다 (2003년). 이를 위한, 효율적인 가상화 시스템은 다음 조건을 만족해야 한다.
- Strong isolation (For Safety)
- Support different operating systems (For Fidelity)
- Overhead must be small (For Performance)
어떻게 하면 이러한 조건을 모두 만족시키는 효율적인 가상화 시스템을 만들 수 있을것 인가?
Importance
2003년 VMware ESX와 같은 시스템은 Full virtualization을 위해서 Binary translating과 같은 기법을 이용하였다. 그러나 이러한 기법은 성능 면에서 한계를 보였다. 2003년 Denali와 같은 시스템들도 개발되고 있었지만, x86 ABI, Application multiplexing, Paging과 같이 여러 측면에서 한계가 있는 프로젝트가 대다수였다. 이와 같은 상황을 극복하기 위해서, 반가상화기법을 시스템의 여러 부분에 과연 어떻게 사용해야 하는 가에 대한 연구가 필요한 시점이었다.
Main Idea
Full virtualization은 모든 운영체제를 수정없이 돌릴 수 있다는 장점이 있지만, 그곳에서 발생하는 overhead가 크다는 단점이 있었다. 이러한 한계를 극복하기 위해서 XEN는 Paravirtualization이라는 기법으로 GuestOS에 적절한 수정을 가하여 시스템을 가속화하였다.
Design principle은 다음과 같다.
- 사용자는 유저 어플리케이션을 수정하지 않아도 되어야 한다.
- 사용자는 다양한 유저 어플리케이션은 하나의 GuestOS에서 돌릴 수 있어야 한다. (LibOS는 1 to 1 이라서 이 문제를 지적한듯 하다.)
- x86과 같이 가상화에 대한 하드웨어 지원이 미비한 ISA에서도 좋은 성능을 내어야 한다.
- Hardware-based virtualization을 지원받더라도, Paravirtualization이 함께 사용되면, 더욱 좋은 성능을 가져올 것이다.
Design
| The paravirtualized x86 interface | ||
|---|---|---|
| Memory Management | Segmentation | Segment descriptor에 직접 접근 할 수 없다 (DPL 0처럼 세그멘테이션의 Privileged 명령을 내릴 수 없다). Linear address space가 Host (Dom 0)와 같을 수 없다. |
| Paging | Guest OS는 hardware page table에 직접 읽는 것은 가능하나, Update는 Hypervisor에 의해서 검수되어서 Batching으로 처리 되어야 한다. | |
| CPU | Protection | Guest OS는 XEN보다 더 낮은 Privilege level에서 작동해야 한다. (이 당시에는 Root, Non-root에 대한 개념이 없어서 Ring개념으로 이해해야 한다.) |
| Exceptions | Guest OS는 Descriptor table을 Hypervisor을 통해서 등록하여 사용해야 한다. 이중 Page fault는 하이퍼 바이저에 의해서 특별히 처리된다. | |
| System Calls | Guest OS는 System call handler를 위한 처리 루틴을 Xen을 통해서 등록하여, Xen을 반드시 거쳐야 하는 Indirect call을 피할 "수" 있다. | |
| Hardware Interrupts | 하드웨어 인터럽트는 Event System에 의해서 대체된다. 이는 진짜 인터럽트가 아니라 CPU가 풀링하고 있는 메모리의 특정 영역으로 소프트웨어 인터럽트를 제공하는 것을 말한다. | |
| Time | Guest OS는 Timer에 대한 정보를 Real그리고 Virtual환경을 통해서 가져올 수 있다. | |
| Device I/O | Network, Disk, etc. | Virtual device들은 Hardware device와 다르게 간단한 Ring buffer specification을 가진다. 또한 Hardware interrupt가 아닌 Event system으로 통신한다. (Virtio와 비슷한 방식) |
메모리
- Paging
- 이 논문이 나왔을 당시에는 EPT와 같은 하드워어 가속 시스템이 아직 x86에 없던 시절이었다. 따라서 Paging는 GuestOS에 일임하여 하드웨어 페이지 테이블에 직접 접근할 수 있는 권한을 주었다. 그러나 GuestOS의 페이지 테이블은 Write권한이 없는 채로 GuestOS에 주어졌다. 이를 통해서 page table update는 반드시 XEN을 통하도록 하였다.
- TLB Flush overhead
- 메모리 상단의 64MB를 XEN에 할당하여 불필요한 Guest <-> Xen간의 World switch에서 TLB flush에 드는 Overhead를 줄였다.
- Segmentation
- Segmentation은 Hardware segment descriptor table에 대한 Update를 Xen을 통하도록 하여서, Xen보다 낮은 Segment권한을 가지는지, Xen이 등록한 Linear address와 겹치는 지를 체크하였다.
CPU
GuestOS의 잘못된 동작에 대비하여, 게스트 OS는 하이퍼바이저보다 반드시 낮은 권한으로 작동하여야 한다. 또한 역시 이 당시에는 Hardware-based isolation을 x86에서 지원하지 않아서, GuestOS는 Ring 1에서 작동하였다. 이러한 방식으로 GuestOS의 Privileged 명령어들은 Ring0인 Dom0 (Hypervisor)을 반드시 거치도록 하였고, Ring 3에 올라가는 User application들을 GuestOS가 효율적으로 관리하도록 하였다. 또한 Hardware-based isolation을 통한 인터럽트의 Forwarding도 지원하지 않기 때문에, Hypervisor가 받은 인터럽트의 처리 또한 소트프웨어적인 관리 대상이 되었다.
- Privileged instruction
- 민감한 명령어(예를 들어서 halt)와 같은 경우는 XEN에서 작동하도록 paravitualized하였다. 이러한 작업에는 새로운 Page Table설치, hlt, lgdt와 같은 민감한 명령어들이 포함된다.
- Exception
- Exception 처리는 GuestOS가 Xen에 의해서 검수 받은 interrupt handler에 의해서 처리되도록 하였다. 그러나 Page fault와 같은 경우 XEN에 의해서 약간의 콜 스택 변형이 필요한데, 이는 CR2 레지스터를 폴트난 페이지의 주소값을 읽는 데 사용하는 일은 Privilege 명령어 이기 떄문에, Xen이 미리 콜스택에 이 값을 써 넣어 주기 위해서 이다.
- 시스템 콜
- 시스템콜과 같은 경우는 VMM에 있어서 성능 하락의 주범이 되는 녀석이었는데, XEN에서는 fast system call이라는 핸들러를 등록 할 수 있도록 하여서 이러한 한계를 극복하였다. 이러한 핸들러는 Ring 0인 Hypervisor를 거치지 않고도 처리될 수 있도록 구현하여, 시스템 콜에서 불필요한 Context switch에 대한 cost를 낮추었다. GuestOS는 시스템 콜 처리를 위해서 핸들러의 주소를 Xen에 넘기고 Xen은 핸들러의 코드 세그먼트가 Ring 0가 아닌지를 검사한 후 CPU에 핸들러의 주소를 등록한다. 시스템콜이 정상적으로 불리면 CPU는 등록된 핸들러의 포인터를 실행시키며, 만약 핸들러가 잘못 작성되어 있어 문제가 발생할 경우 Xen은 Guest OS를 강제 종료한다.
Device I/O
실제하는 디바이스를 Emulating하는 것이 아니라, 간단한 Shared, asynchronous ring buffer구조를 통해서 불필요한 Overhead를 줄이고 Isolation을 높여서 효율적인 I/O구현이 가능하도록 하였다. 또한 Device interrupt를 Event channel로 구현해서 인터럽트에 의한 world switch overhead를 줄였다.
Control and Management
Xen은 Policy를 Mechanism에서 분리하는 원칙을 지키기 위해서, Hypervisor은 정말 간단한 체크와, 디바이스 드라이버처럼 필수적인 요소만 가지고 있도록 하였다. 이를 위해서 Dom 0 (Domain 0)라는 Guest OS가 다른 모든 Guest OS에 대한 Application-level 컨트롤 및 백엔드 디바이스 드라이버의 역활을 하도록 하였다. Dom 0는 Xen에 있는 Dom 0용 Control interface를 통해서, 다른 Guest OS를 스폰하거나, 가상 디스크(VBD)를 만들고, 가상 네트워크 디바이스(VIF)를 할당하는 다양한 가상머신 관리를 할 수 있도록 하였다.
전반적인 구조는 H/W <-> Dom0 Interface - VCPU, VDEV, VNET... <-> GuestOS와 같다. 이러한 가상장치들은 event channel을 이용하여 Guest OS와 통신할 수 있도록 하였다.
Detailed Design (& Implementations)
Xen은 다양한 Optimization, Paravirtualization 기법들을 만들거나 채택함으로서, 성능, 보안 그리고 다양한 하드웨어의 지원을 달성하고자 하였다. 이러한 Implementation-detailed들은 다른 논문들의 Implementation과는 다르게 매우 선구적, 그리고 향후 반가상화 기법에 많은 영향을 주었기 때문에 따로 정리하였다.
Control Transfer
- Guest OS to Xen
- Guest OS가 Xen에 Notification을 보내기 위해서 Xen은 하이퍼콜이라는 개념을 사용하였다. 하이퍼콜은 도메인이 동기적인 소프트웨어 트랩을 하이퍼바이저에 걸수 있도록 하였다 (마치 시스템 콜처럼). 예를 들어서 Hlt, Page table update와 같은 기능들이 Hypercall을 통해서 이루어지도록 하였다.
- Xen to Guest OS
Xen이 Guest OS에 정보를 제공하기 위한 방식으로 Event channel을 사용하였다. event channel은 기존의 인터럽트를 대체하는 비동기적인 통신 방식으로, per-domain bitmask에 pending event들이 작성되고 Xen은 Guest OS의 핸들러를 호출한다. 그후 Guest OS가 bitmask에 표기된 event들을 처리하고 update하는 방식으로 구현되었다.
I/O Rings
I/O transfer은 resource management와 event notification을 중점으로 하여 개발되었다. 환형 큐를 이용하여 Request와 Response가 처리되도록 하였으며, 각각의 qeue에는 producer-consumer pointer가 존재하여 도메인이 어느 위치에 request를 쓰고 어느 위치에서 response를 가져가면 되는지 마킹할 수 있도록 하였다. 이는 Produce-consumer모델에서 Order가 필요없도록 하여서, Guest OS와 Xen이 적절히 요청의 순서를 변경시키거나 배칭으로 처리할 수 있도록 하여서 성능상의 이점을 가져올 수 있도록 하였다.
CPU Scheduling
도메인간의 스케쥴링은 Borrowed Virtual Time 스케쥴링을 이용하여 구현하였다. 이 알고리즘은 work-conserving이고 적은 코스트로 event발생시에 event를 dispath할 수 있는 매커니즘이 있어서 채택되었다. Dispath상황에서 BVT알고리즘은 임시적으로 Ideal한 알고리즘을 무시하고 event를 처리할 수 있도록 하여서 TCP스택처럼 Latency가 중요한 작업에서 성능을 보장해 준다.
Time and timers
XEN은 real time, virtual time그리고 wall-clock time을 제공하였다. 각각은 부팅후 시간, 게스트 운영체제 동작 시간 그리고 현재 real time에 더해야할 offset을 말한다. 각각의 운영체제는 알람 타이머를 프로그래밍 할 수 있으며 주어진 타이머를 가지고 Application에 Time slice를 주거나 스케쥴러를 구현하는등 여러 작업을 할 수 있다. 이러한 Timer event는 Event-channel을 통해서 전달된다.
Virtual address translation
Full virtualization이 Shadow page table의 사용을 요구하는 것과 다르게, XEN은 페이지 테이블의 관리를 모두 GuestOS에 일임하였다. 그러나 Page Table의 Update는 XEN이 체크하도록 하여서 적합한 것인지를 검수하게 하였다. 즉 이러한 방식을 통해서 Shadow page table을 통한 overhead나 구현의 복잡성을 피하였다. Guest page table은 Xen에 의해서 Guest OS는 Read-only권한만을 가지도록 강제되기 때문에 Page table에 대한 Implicit write access는 금지된다.
Validation을 구현하기 위해서, type과 Reference를 page frame에 대해서 분리하여 구현하였다. 각각의 page들은 다음 5개의 타입중 여러개를 복수개 가질 수 없도록 하였다. 즉 각 Domain (Guest OS)는 다음 5개의 타입 중 하나만을 가질 수 있다; Page directory, Page table, Local descriptor table, Global descriptor table, 그리고 Writable page. 이처첢 Type을 통해서 Writable이 아니여야만 Sensitive한 하드웨어 자료 구조 접근할 수 있도록 하였다. 또한 page들은 Reference를 가지고 있는데, Reference값이 0이 되어야만 Xen이 Guest OS에 할당된 페이지를 안전하게 deallocation을 수행하도록 구현되었다.
이러한 Hypervisor을 통한 간접 접근은 Sensitive data에 대한 update를 요청하는 명령어들이 배칭되어 처리 될 수 있도록 하여서, 시스템의 효율을 더욱 끌어 올리는 장점을 가져올 수 있었다. 또한 Type system을 통해서 한번 Sensitive page로 매핑된 페이지가 같은 용도로 재사용될때, Validation을 하는 비용을 제거하였다.
Physical memory
최초의 메모리 할당은 정적으로 이루어지도록 하였다. Physical memory는 정적인 시간에 Parition되어서 Guest OS에 전달된다. 만약 Memory Pressure가 심해진다면, 더 많은 메모리를 할당하도록 Guest OS는 Xen에 요청할 수 있고 Xen은 이러한 요청을 받아 줄 수도 있고, 무시할 수도 있다. Xen은 Ballon driver을 구현하여서 메모리의 할당을 조절할 수 있도록 하였다. 그러나 Paravirtualization은 이러한 Ballon driver없이도 같은 역활을 수행할 수 있도록 할 수도 있다.
Network
Device driver의 일종으로 DMA를 이용하여 메모리 버퍼에 요청하는 qeueue를 작성하는 방식으로 구현하였으며, 이러한 작업의 Virtual Interface는 Dom 0에 구현되도록 하였다. Virtual network interface (VIF)는 두개의 링 버퍼를 가지고 각각 transmit과 receive를 위해서 사용된다. Dom 0는 Virtual firewall router(VFR)를 통해서 VIF들이 VFR에 연결되도록 하였고, VIF들의 Rounting을 Dom 0의 Rules들이 IP, Port 그리고 Hardware interface와 같은 것들을 참고하여 안전하게 Forwarding하도록 구현하였다. (이는 현재 Virtio의 Network구현과 매우 비슷한 구조를 가지고 있다.)
Disk I/O
Ring Buffer를 이용하여 실제 Dom 0의 Physical Device와 Dom #의 Abstracted driver가 통신하며 Disk에 간접적으로 Dom 0을 통해서 접근하도록 구현하였다. Dom 0만이 실제 Device driver에 직접 접근이 가능하며, 나머지 도메인들은 Virtual bock devices (VBD)를 통해서 추상화되어 간략화된 front-end driver을 통해서 Dom 0의 Back-end driver에 정보를 주고 받는 방식으로 디스크에 간접 접근할 수 있게 하였다. Dom 0는 중간에 Isolation과 Protection을 위해서 Valid한 접근인지를 체크하는 역활을 수행하도록 하였다. 데이터 전송은 User buffer와 Hardware사이에 DMA를 통해서 전송하도록 하여서 불필요한 Memory copy를 줄였다.
배칭을 통해서 성능향상을 보일 수 있었으며, 또한 Xen에 의한 Request reordering을 막기 위해서 Guest OS가 베리어를 전송할 수 있도록 하여서 Logging처럼 순서가 중요한 Operation에서의 시맨틱을 보장할 수 있도록 설계하였다.
Result
Linux native, XenoLinux (Xen for Linux), VMware workstation, User-mode linux에 대한 비교를 실시하였다. 이때 VMware ESX Server와 같은 경우에는 라이센스 문제로 인해서 정확한 수치는 제공하지 못하였지만, 성능상으로 압도한다고 말하였다. 여기서 User-mode linux (UML)은 당시 유행하던 리눅스를 유저 모드에서 돌리는 프로젝트였는데, 현재는 성능상의 이점이 Container와 같은 시스템과 비교하여서 별로 없어서 사장되었다.
매크로, 마이크로 벤치마크에서도 기존 시스템 대비 매우 빠른 성능을 제공하였다.
Contribution
- 반가상화 기법에 대한 거의 정립된 디자인과 구현을 제시함
- 반가상화, 가상화 논문에 대한 Insight를 제시함
- 가상화 기법이 어떻게 Optimization될 수 있는지에 대한 깊은 Background를 제공함
- 후에 Virtio와 같은 기법에 지대한 영향을 미침
- Evaluation도 매우 구체적이고 다양한 Performance비교를 수행하여 서로 다른 Virtualization기법에 대한 성능 분석을 제공하고 있음
Criticize
- Intel VT-d와 같은 Hardware-based virtualization이 대중화된 2023년 시점에서는 Out-dated된 내용들이 있음 (MMU관리등)
- Speculative버그가 발견된 현재, TLB때문에 Xen코드를 Guest위에 올려두는 것은 특정 CPU에 대해서 Security에 대한 Attack point가 될 수 있음
- 2023년 현재 시점에서도 반가상화 및 가상화에 대한 깊은 분석과 디자인 그리고 엄청 많은 Implemenatation을 가지고 있는 대단히 선구적이고 영향력있는 논문임