티스토리 뷰

Operating System Support for Virtual Machines


USENIX 2003 

University of Michigan



Abstract

VMM기술은 OS와 APP를 추가 하기 좋은 기술이다. Type2 VMM(Hosted)는 제공하는 추상화를 기반으로 한다. Type2 VMM는 우아하고 편리하지만 그 성능은 native한 성능보다 느리다. 본 논문은 Type2 VMM의 오버해드의 이유를 확인하다. 호스트 운영체제의 몇가지 간단한 확장으로 VMM를 빠르게 동작할수 있는 플랫폼을 만들 수 있다는 것을 발견하였는 이러한 확장을 활용하여 Type2 VMM의 성능을 14 ~38%향상하였다. 


1. Introduction 

VVM은 전체 컴퓨터 시스템의 하드웨어를 에뮬레이션하는 소프트웨어 레이어이다. VMM에 의하여 생선되는 것을 VM이라고 한다. VMM에 의하여 에뮬레이터된 하드웨어는 일반적으로 VMM의 하드웨어와 유사하거나 동일한 하드웨에서 동작한다. (전가상화와 반가상화의 이야기 인거 같다.)

// VM의 장점

VM은 1960년대 개발되어 사용되었다. VM의 몇몇속성들은 다양한 사용을 하기위해서 유용하였다. 

첫째로 하나의 물리적인 기계에 여러 VM을 생성할수 있다. 

둘때로 VM은 물리적 하드웨어를 사용라여 OS를 디버깅하는것보다 더 편리한 환경을 제공한다. 

셋째로 VM은 기능을 추가하기위한 편리한 인터페이스를 제공한다. 

마지막으로 VM은 VM instance 간의 강력한 Isolation을 제공한다 


소프트웨어 레이어에서 VMM은 낮은 수준의 하드웨어 와 소프트웨어 플랫폼에서 동작한다. ( 호스트 운영체제위헤서 동작한다는말) 그리고 높은수준의 소프트웨어와의 인터페이스를 제공한다. ( 호스트운영체제와 VM사이에서 인터페이스를 제공한다는 말이다.) 이 논문에서는 로우 레벨의 플랫폼(호스트운영체제)가  VMM을 지원하는것에 대하여 관심을 가지고 있다.  이 플랫폼은 하드웨어 일수도 있고 호스트운영체제일수도있다, 하드웨어 위에 바로 VMM을 구성하면 소프트웨어 레이어가 줄어들어 보더해드가 줄어들수 있다. 그리고 하드웨어 기능을 최대한 다 사용할수 있다. 다른 한편 호스트 운영체제에서 VMM을 구축하면 호스트운영체제가 추상화를 사용하게 하여 VMM을 단순화한다.


이논문에서는 호스트운영체제에서 VMM을 동작했을떄 성능 오버헤드를 줄일수 있는 방법에 대하여 examine하고 줄이는 것을 목적으로 하고 있다. 호스트 운영체제에 몇가지 간단한 수정으로 VM의 성능 오버헤드를 14~35%감소 시켰다.


세션 2에서는 

- 전통적인 VM 2가지 

- VMM이 제공하는 하이레벨 인터페이스 

- 로우레벨 플랫폼에서 VMM에세 제공하는 인터페이스에 대한성명을 한다. 

세션 3에서는 그들이만든 수정된 호스트 운영체제인 UM Linux에 대한 설명은 하고 

세션 4에서는 화장된 호스트 운영체제에 대하여 설명한다. 호스트운영체제웨서 구성되어도 하드웨어에서 직접 실행되는 스피드를 가질수 있도록한

세션 5에서는 성능 평가 

세션 6에서는 관련 연구 

셋션 7에서는 마무리 


2. Virtual machines

VMM은 많은 차원으로 분류할 수 있다. 이 세션에서는 두가지로 분류하겠다.

VMM의 제공하는 high-level Interface와 low-level 플랫폼의 구축 

 

VMM을 분류할수 있는 첫번째 방법은 VMM이 제공하는 하이 레벨 인터페이스가 물리적 하드웨어의 인터페이스와 얼마나 가깝게 일치하는가를 따른다. 몇가지 면에서 VMM이 하드웨어와 같은 인터페이스를 제공하는것은 가상화를 어렵게 하고 느리게 한다.  일부 아키텍쳐들은 특권모드와 유저모드에 의존적인 sensitive instruction이 존재 한다. 이는 VMM에 트랩이 유발하지 않고 사용자 모드에서 실행할 수 있다. 이러한 민감하면서도 권한이 없는 명령어는 가상화에 상당한 복잡성을 추가 하게 된다 즉 어버해드가 된다.(에뮬레이션 하는 과정에서 민감한 오퍼레이션 CPU에 특화된 모드 명령어 들에서 변환과정에서 오버해드가 발생한다는 말같음) 그리고 I/O처리 에뮬레이션은 VMM과 VM과 호스트운영체제 실행장치간의 빈번한 전환이 발생하게 된다. I/O 문제를 해결하기 위해서 일반적으로 반 가상화 방법이 사용되고 있다. 

// 가상화의 속도문제는 대부분 sensitive instruction과 I/O 문제에서 발생한다고 말한다.

 다른 가상화 전략은 기본 하드웨어에서의 인터페이스와 다르게 구성하는 것이다. 


VMM을 분류할수 있는 두번째 방법은 플랫폼을 따르는것이다. type 1, 2 애 대한 이야기 결론이 이논문은 type2의 장점을 유지하면서 단점인 성능 문제를 호스트 운영체제의 몇가기 간단한 변경으로 가능하게 했다인데 난 그 몇가기 간단한 변경이 먼지 궁금하다. 


3. UMLinux

본 연구를 수해하기 위해, 이들은 Type2 VMM인 UMLinux를 사용 하였다.  

UMLinx는 타입2 VMM이다 게스트 운영체제와 게스트 응용프로그램은 하나의 프로세서에서 동작한다. 리눅스 호스트 운영체제위에서 그리고 underlying 하드웨어와 다른 하이 레벨 인터페이스를 제공한다. 그 결과 게스트 리눅스 운영체제의 시스템에 의존하는 부분은 VMM에서 제공하는 인터페이스를 사용하여 수정해야 한다. 간단한 장치 드라이버는 가상 시스템의 장치를 구현하는데 사용되는 호스트의 추상화와 상호 작용하기 위해 추가 되어야만한다. 몇가기 어셈블리어 명령어 또한 에뮬레이션 코드를 함수 호출로 대체해야하며, 게스트 커널 다른 주소 범위에 다시 연결해야 한다. 코드는 약 17000라인으로 응용 프로그램은 게스트 운영체제에 대한 수정 하지 않고 호스트 운영체제에서 직접 컴파일한다. 


또 가상 하드웨어에 자연스럽게 매핑하여 호스트 운영체제에서 기능을 사용한다. 호스트 신호는 가상 인터럽트 역할을 한다. 


4. Host OS support for Type 2 VMMs

Type2 VMM을 실행할 때 발생하는 세가지 병목 현상을 조사하고, 제거한다.


- UMLinux는 VMM 프로세서와 게스트OS가 분리된 호스트 프로세스로 존재 하기 때문에 호스트 OS의 빈번한 컨텍스트 스위칭을 발생시킨다. ( Type 1에서는 VMM의 기능이 호스트 커널에 녹아들어 가야 한다 우리같은 경우는 현제 쉘의 역활이 커널 영역으로 들어 가야 한다. 

- 게스트 커널과 게스트 유저(메모리 영역) 사이의 스위칭에서 많은 수의 메모리 protection operations이 발생한다. 

- 두 게스트 어플리케이션 간의 스위칭에서 많은 수의 메모리 mapping operation이 발생한다. 

// 이논문의 핵심

// 아무레도 타입 2가 레이어의 수가 많으니까 각 레이어의 스위칭과정에서 생겨나는 스위칭을 줄여야 한다 그럼 나도 타입 1으로 갈때는 자연스럽게 이러한 스위칭이 줄어들겠지만 스위칭이 진짜 줄어 들수 있도록 만들어야 할거 같다. 


4.1 Extra host context switches

UMLinux의 VMM프로세스 는 Ptrace()를 사용하여 게스트 프로세스의 키 오퍼레이션(시스템콜과 시그널)을 감지 한다. 이러한 ptrace는 강력한 디버깅 도구이긴하지만 가상화된 환경에서 사용하게 된다면 빈번한 컨텍스트 스위칭을 만들게 된다 밑의 그림과 같이  


//이부분이 내가 해야할일 첫번째 

우리는 VMM프로세서의 기능을 호스트 커널에 이동시켜서 이러한 컨텍스트 수위칭을 제거할 수 있다. 대부분의 VMM 프로세서 기능을 loadable kernel을 사용하여 케슐화한다.(커널에 기능을 넣는다는 이야기) 호스트 커널의 시스템콜 과 시그널 일부분을 수정해야 하는 작업이 필요하였고 VMM수신 과정에서 필요한 시스템콜과 시그널이고 VMM의 송수신 부분도 수정 했다고 논문에 나왔있고 정확한 이야기 는 없고 150줄 정도의 코딩이라고 말하고 있다. 


호스트 커널에 VMM과정의 기능을 이동하는 것으로 (당연한 말인데 이건 호스트 커널을 수정해서 타입 1의 효과를 낸다는 거같다는 생각이 든다 타입 1과 다른건머지? ) UMLinx에서 컨텟스트 스위치의 수를 줄일 수 있다. 


그림 5와 같이 게스트 운영체제의 시스템콜을 단 두번의 컨텍스트 스위치로 해결할 수 있다. 이전 방법에서 8번의 컨텍스트 스위칭이 발생하는 것보다 1/4의 숫자이다. 


4.2 Protecting guest kernel space from guest application processes

VM안에서도 게스트 커널모드와 게스트 유저모드의 스위치가 빈번하게 발생한다. 

게스트 커널은 게스트 어플리케이션의 게스트 시스템콜이나 다른 예외처리그리고 가상 I/O드라이브의 시그널로 호출이된다. 

VM에서 유저모드와 커널모드로 스위칭될대마다  가장 처음 되야 하는것이 게스트 커널의 portion된 주소공간으로 엑세스를 가능하게 하도록 설정해야 한다.

VM은 주소 공간을 조작하는데 호스트 운영체제의 mmap, munmap, mprotect를 사용한다. 

 mmap, munmap, mprotect을 VM이 사용하여 페이지를 많이 보면 볼수록 오버해드가 발생하게 된다 


이들은 게스트 커널 모드와 게스트 사용자 모드를 전환 할때 발생하는 오버해드를 제거 하기 위해 x86의 페이지 세그먼트와 권한 모드를 사용하는 두 솔루션을 만들었다. Linux normally uses paging as its primary mechanism for translation and protection, using segments only to switch between privilege levels. 리눅스는 4개의 세그먼트를 사용한다 : kernel code segment, kernel data segment, user code segment, and user data segment.

 

(그림 6)리눅스는 특권모드 비트를 사용한다 페이지 테이블에 유저(ring 3)상태에서 OS의 테이터에 접근하지 않게 하기 위해서

(그림 7)그들의 첫번째 해결책은 게스트 커널 공간을 보호하는것이다 게스트 유저코드로 by bound 한다. 유저코드 그리고 데이터 세그먼트를 


이 솔루션의 한계는 게스트 커널공간이 호스트 커널 공간 바로 아래 존재 한다고 가정하는것이다. 

(그림 8) 그들의 두번째 해결책은 게스트 커널 공간이 게스트 커널 모드와 게스트 사용자 모드 사이를 구별하는 비트 페이지 테이블의 전용 관리자를 사용하여 게스트 응용프로그램 공간의 범위를 점유 할수 있게 하는것이다. 

게스트 머신의 프로세서가 호스트 커널의 공간을 접근하지 못하도록 방지하는데 의의가 있다. 


4.3 Switching between guest application processes

3번쨰 성능 오버해드는 게스트 어플리케이션 간의 주소공간 스위치에서 발생한다. 게스트 주소공간을 변경한다는 의미는 가상 머신의 "physical"메모리 파일에서 게스트 가상 페이지와 페이지 사이의 현재의 매핑을 변경하는 것을 말한다. 


기존의 mmap 과 munmap을 통하여 메모리 영역을 할당(맵핑)하였는데 호스트 운영체제의 코드 320줄을 수정하여 하나의 프로세서 메모리 공간을 정의하고 (미리 메모리 공간을 잡아 두고 있겠다는 것이다 동적 할당하지 않고 그러면 당연히 메모리 할당에 소요되는 시간이 없어 지니까 속도는 빨라 지지만 메모리 공간에 제약이 있는 시스테에서는 안좋을수 있다.)  To switch address space definitions, switchguest needs only to change the pointer to the current first-level page table. 오직 현재  페이지 테이블의 포인터만 변경하는것으로 가능하다. ( 이러면 메모리 공간이 넉넉히 필요하다는것인데 우리 시스템에서 는 유용 하지 않을거 같다.  우리는 메모리 공간이 너무 제약 상황이 많다.이런건 서버급 컴퓨터에서 유용 할것같다. )



7. Conclusions and future work


첫번째 문제점

Os는 별도의 호스트 유저 프로세서가 필요하다 to 메인 게스트 머신 프로세서를 제어 하기 위한 and 이것은 많은 컨텍스트 스위치를 발생시킨다. 

첫번째 해결책

이문제는 게스트 머신 프로세서를 제어라는 코드를 호스트 커널에 옮겨서 해결한다. 


두번째 문제점 

게스트 커널과 게스트 유저 공간 간의 스위칭은 많은향의 메모리 보호 오퍼레이션을 야기 시킨다. 

두번째 해결책 

세그먼트 경계를 만들고(호스트 OS영역을 아예 접근 하지 못하도록) 게스트 머신 프로세서를 ring1 특권모드 에서 동작 하도록한다. 


마지막 문제점 

두개의 게스트 응용 프로그램간의 스위칭은 많은량의 메모리 매핑 오퍼레이션을 야기 시킨다. 

두번째 해결책 

이문제점은 호스트 운영체제에서 하나의 주소공간은 유지 하도록 정의 하여 해결하였다. (항상 매핑되어있는 상태를 만든다)


미래 작업으로 호스트 운영체제의 축소를 말하고 있는데 이것은 가상화에 사용되는 시스템콜의 양이 적기 때문에 이러 한 최소화가 타입 2 성능에 좋은 영향을 미칠거라는 말이다. 




 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함