Emulation

Native 플랫폼에서의 I/O 메카니즘은 일반적으로 하드웨어 장치의 일부 종류에서 수행된다. 소프트웨어 스택 (흔히 말해서 OS의 드라이버)는 memory-mapped (MMIO) 메커니즘의 일부 종류를 통해서 하드웨어와 인터페이스하게 되고, 프로세서는 특정한 메모리 (혹은 포트) 주소 범위에 읽기와 쓰기를 하는 instruction들을 issue하게 된다. 값을 읽고 쓰는 것은 하드웨어의 direct function들에 의해서 대응된다.

에뮬레이션이란 소프트웨어에서 실제 하드웨어를 완전히 구현하는 것을 의미한다. 이의 큰 장점은 기존에 존재하는 guest 소프트웨어에 대해서 어떻한 변경도 요구되지 않다는 점이다. 소프트웨어가 native인 환경에서 수행하듯이 수행하게 되고 VMM 에뮬레이터와 interacting하면서 마치 실제 하드웨어와 동작하는 것처럼 동작을 하게 된다. 소프트웨어는 실제로 가상화된 장치와 이야기하는 것인지를 인식하지 못한다. 이러한 에뮬레이션이 동작하기 위해서는 몇몇 메커니즘들이 필요하다.

VMM은 guest 소프트웨어에 의해서 discovered 될 수 있는 것과 동일한 방식으로 장치를 표출시켜야만 한다. 예를 들어, PCI 설정 공간에 있는 장치가 있다면, guest 소프트웨어는 device를 볼 수 있고, 장치와 interact하는데 사용되는 메모리 공간을 찾을 수 있게 된다.

VMM은 또한 device-discovery 공간에 접근을 capturing 하는 것은 물론 장치의 주소 범위에 read 와 write들을 capturing하는 일부 메소드를 갖고 있어야만 한다. 이는 VMM으로 하여금 guest 소프트웨어가 인터테이싱하고 있다고 믿고 있는 진짜 하드웨어를 에뮬레이트하는 것을 가능하게 한다.

(일반적으로 장치 모델이라 불리는) 장치는 소프트웨어로 VMM에 의해서 완전히 구현된다. 이는 일부 I/O를 서비스하는 것과 동일한 방법으로 플랫폼에서 하드웨어의 일부 부분을 접근할수도 있으나, 해당 하드웨어는 실제 장치 모델과는 관계는 독립적이다. 예를 들어 guest가 VMM에 의해서 표출된 IDE 하드 디스크 모델을 볼수 있는 반면, 실제 플랫폼은 SATA 디스크를 제공하곤 한다는 것이다.

VMM은 또한 에뮬레이트되는 장치의 일부로써 적절한 시기에 인터럽트들을 guest에게 주입(injection)할 수 있는 메커니즘을 가져야만 한다. 이는 일반적으로 PIC를 에뮬레이트하여 이뤄진다. 다시 말하자면 guest 소프트웨어가 PIC를 사용할 때, (guest의) 이러한 접근은 trap되어야만 하고, PIC 장치에 대한 에뮬레이트가 VMM에 의해서 적절히 수행되어야 한다. PIC가 단지 또 다른 하나의 I/O 장치로 생각되는 반면, 적절하게 에뮬레이트되는 임의의 다른 interrupt-driven I/O 장치도 존재해야만 한다.

에뮬레이션은 VM의 하나의 플랫폼에서 또 다른 하나의 플랫폼으로의 이주를 용이하게 한다. 장치가 완벽하게 에뮬레이트되고 있고, 플랫폼 상에서 어떠한 physical 장치들에도 (직접적으로) 묶여있지 않기 때문에, VM을 VMM이 정확하게 똑같은 에뮬레이션되는 장치들을 지원하는 또다른 플랫폼으로 이동하는 것이 간단해진다. 만약 guest VM이 어떠한 플랫폼 물리 장치들에 일부 엮여 있다면, 이러한 같은 physical 장치들이 VM이 이주될 임의의 플랫폼에 존재해야할 필요가 있다.

에뮬레이션은 역시 같은 종류의 플랫폼 물리 장치들의 공유를 용이하게 한다. 이는 에뮬레이션 모델의 인스턴스들이 많은 guest들에 잠재적으로 표출될 수 있기 때문이다. VMM은 하나의 물리 장치에 대한 모든 guest들의 에뮬레이션 모델 접근을 허용할수있는 공유 메커니즘을 일부에 사용할 수 도 있다. 예를 들어 에뮬레이션되는 네트워크 아답터들을 이용하는 많은 guest로부터의 traffic은 platform의 물리 네트워크 아답터로 브릿지 될 수 있다는 것이다.

에뮬레이션이 guest 소프트웨어에게 일부 존재하는 물리 하드웨어 장치와 동일한 인터페이스를 제공하기 때문에, OS 독립적인 방법을 사용하여 다수의 서로 다른 guest OS들을 지원할 수 있게 된다. 예를 들어 특수한 저장장치가 완벽하게 에뮬레이트된다면, guest OS 가 windows xp건, linux이건 혹은 또다른 어떠한 IA기반의 OS 이건간에 상관없이 모든 소프트웨어가 해당 장치를 문제없이 사용하게 해준다. 대부분의 modern 운영체제들은 잘 알려진 장치들에 대한 드라이버를 기본적으로 제공하고 있기 때문에, 특별한 장치들의 경우에도 에뮬레이션을 통해서 기존의 legacy 환경에서도 사용이 가능해 진다.

에뮬레이션이 guest 장치 드라이버를 수정할 필요가 없는 등의 이러한 장점에도 불구하고, 이의 가장 큰 문제점은 성능이 낮다는 점이다. 에뮬레이트된 장치의 guest 장치 드라이버 각각의 interaction은 VMM으로의 transition을 요구하게 되고, transition 후 장치 모델은 필요한 에뮬레이션을 진행하게 되며, 에뮬레이션이 진행된 후 적절한 결과를 가지고서 guest로 transition back하게 된다. 에뮬레이트되는 I/O 장치들의 종류에 따라서 이러한 transaction들이 많이 필요하게 될수 있다. 이러한 움직임은 비-가상화 환경에서 일반적인 소프트웨어-하드웨어간의 interaction에 비해서 상당한 오버헤드를 더하게 된다. 각각 interaction을 진행한 시간은 역시 전체적인 latency를 높이게 된다.

또 하나의 단점은 장치모듈은 하드웨어 장치를 매우 정확하게 에뮬레이트해야할 필요가 있다는 점이다. 종종 하드웨어의 revision 등, 모든 사소한 것까지 에뮬레이트해줘야하는 것이다. 이는 'bug emulation'까지 필요하다는 것을 의미하고, 하드웨어의 새로운 revision들로 인해서 문제는 계속 발생하게 된다.

Paravirtualization

가상 I/O의 또 한가지 테크닉은 guest에 존재하는 소프트웨어를 변경하는 방식으로 paravirtualization이라고 불리운다. I/O paravirtualization의 장점은 더 나은 성능이다. 반면 단점으로는 guest 소프트웨어의 변경을 필요로 한다는 점인데, 이는 특정 장치 드라이버에 대해서 legacy OS에서의 사용성에 의해 제한되기도 하고, 장치 드라이버에 의해 제한되기도 한다. Paravirtualization을 이용할 경우에는 수정된 guest 소프트웨어가 직접적으로 VMM과 통신하게 되는데, 이는 일반적인 하드웨어/소프트웨어 인터페이스보다 높은 추상화 수준을 이용하게 된다. VMM은 I/O 종류에 한정적인 API를 표출시키게 되는데, 예를 들어 네트워크 아답터의 경우에는 네트워크 패킷들의 send 와 receive를 표출시키게 된다. guest에서 변경된 소프트웨어는 하드웨어 장치 인터페이스와 직접적으로 통신하는 대신에 이러한 VMM API를 사용하게 된다.

Paravirtualization은 guest OS와 VMM 간의 통신 수를 줄이게 됨으로써 장치 에뮬레이션에 비해서 높은 성능 (더 높은 처리량, 낮은 레이턴시, 낮은 CPU 사용율)을 제공하게 된다.

에뮬레이트된 인터럽트 메커니즘 대신에, ㅖaravirtualization은 eventing 혹은 callback 메카니즘을 사용하고 있다. 이는 PIC 하드웨어와의 통신이 없어지고, 대부분의 운영체제의 핸들이 단계적으로 발생하는 것을 방해하여 오버해드와 레이턴시가 증가하기 때문에, 더 나은 성능을 낼 수 있는데 도움이 주게 된다. 첫번째로 인터럽트들은 작은 Interrupt Server Routine (ISR)에 의해서 운영된다. ISR 은 일반적으로 인터럽트에 대해서 알고 있고 이를 적절한 worker task에게 할당하게 된다. worker task는 그러면 다른 context 하에서 인터럽트와 관련된 다수의 work를 수행하게 된다. VMM에 의해서 guest 소프트웨어에서 직접적으로 초기화된 event 와 callback 을 이용해서 work는 같은 context 안에서 직접 처리된다. 일부 구현에서는 VMM이 guest 에게 interrupt 를 전달할 때, VMM은 동작하고 있는 guest가 VMM으로부터 나오도록 강제해야 하고, guest가 재진입할 때, 대기하고 있는 interrupt들이 처리될 수 있도록 하고 있다. 동작하고 있는 guest를 강제로 나오도록 하기 위해서, IPI 와 같은 메커니즘이 사용된다. 그러나 이는 다시 direct callback이나 event 와 비교해서 큰 오버헤드를 더하게 된다. 다시 말하자면 이러한 접근의 가장 큰 단점은 guest OS kernel 의 interrupt 처리 메커니즘들이 변경되야 한다는 것이다.

Figure 1에서 보이는 바와 같이, Paravirtualization 은 guest 소프트웨어를 수정해야 하기 때문에, 일반적으로 수정된 컴포넌트들은 guest environment에 제한된다. 예를 들어, windows xp용 paravirtualized storage 드라이버는 linux environment 에서 동작하지 않는다. 그러므로, 분리된 paravirtualized 컴포넌트는 각각 대상 guest environment 를 위해서 개발/지원되어야만 한다. 이러한 변경은 특정한 VMM에 의해서 지원되는 guest environment 에 대한 연역적인 지식을 필요로 한다.

장치 에뮬레이션과 같이, paravirtualization은 VM 이주를 지원하는데, 이때 guest 소프트웨어 스택이 필요로 하는 동일한 VMM API들을 지원하는 플랫폼으로의 이주만을 제공하게 된다.

같은 종류의 어떠한 플랫폼 물리 장치들의 공유는 에뮬레이션과 동일한 방식으로 지원된다. 예를 들어, paravirtualized storage 드라이버를 이용해서 guest 가 데이터를 읽고 쓰기를 할 때 VMM에 의해서 관리되는 동일한 물리 스토리지 장치상의 공간을 사용할 수 있다. Paravirtualization은 점차 I/O-intensive 응용들의 성능 요구조건을 만족시키도록 배포되고 있다. 네트워킹, 스토리지, 그리고 고성능 그래픽과 같은 성능에 민감한 I/O 클래스들의 paravirtualization은 modern VMM 구조의 선택의 방법이 될 수 있다. 설명한 바와 같이, I/O 의 paravirtualization은 장치 에뮬레이션으로 인한 다수의 프로세싱을 없을 뿐 아니라, 클라이언트 VM 과 VMM 간의 transition의 수를 감소시킨다.

Paravirtualization은 guest OS 에서의 I/O 인터페이스를 위한 고수준 추상화를 제공한다. 가상화되고 있다는 사실을 인지하고 있는 I/O 버퍼 할당과 관리 정책들은 완전한 장치 에뮬레이션에 의존하는 수정하지 않은 드라이버로서 가능한 것보다 VT-d 보호와 변환 기능을 더욱 효율적으로 사용할 수 있도록 한다.

적어도 세 주 VMM 회사들은 높은 확장성과 성능을 위해서 I/O 를 paravirtualize 하는 capability 을 적용하고 있다. Xen 과 VMware 는 이미 paravirtualized I/O 드라이버들을 사용하고 있고, MS도 역시 차세대 VMM에서 I/O paravirtualization의 포함을 계획하고 있다.

Direct Assignment

플랫폼상의 물리 I/O 장치를 특정한 guest VM이 직접 소유하도록 원하는 경우가 있다. 에뮬레이션처럼, 직접 할당(direct assignment)는 장치를 소유하고 있는 guest VM이 표준 장치 하드웨어 인터페이스를 이용해서 직접적으로 (장치와) 인터페이스하는 것을 허용한다. 그러므로, 직접 장치 할당은 guest VM에게 native한 경험을 제공하는데, 이는 이미 존재하는 드라이버의 재사용이 가능하거나, 다른 소프트웨어가 장치에 직접적으로 통신하는 것을 지원하기 때문이다.

직접 할당은 에뮬레이션보다 높은 성능을 제공하는데, 이는 guest VM 장치 드라이버들이 virtual emulated device의 장치 명령어 포맷으로부터 변환을 하지 않아도 되고, 해당 native 하드웨어 명령 포맷으로 장치와 통신할 수 있게 되기 때문이다. 더 중요한 것은, 직접 할당은 VMM의 신뢰성을 높이고 VMM의 복잡도를 줄이는데, 이는 복잡한 장치 드라이버들이 VMM으로부터 guest로 옮겨갔기 때문이다. 그러나 직접 할당은 모든 사용에 적합하지는 않다. 첫째, VMM은 오직 플랫폼에 물리적으로 존재하는 수만큼의 장치만을 할당할 수 있다. 둘째, 직접 할당은 VM 이주를 매우 복잡하게 만든다. 플랫폼간의 VM 이주를 위해서, 유사한 장치 종류, 제조사, 그리고 모델이 각각 플랫폼에 꼭 존재해야만 하고 사용이 가능해야 한다. VMM은 역시 이주하기 전의 플랫폼으로부터 어떠한 물리 장치 상태를 알아내는 방법을 개발해야 하고, 이주할 대상 플랫폼에서 그 상태를 복원하는 방법 역시 개발되어야만 한다.

게다가, 직접 할당을 지원하기 위한 하드웨어가 없기 때문에, 직접 할당은 성능 증가와 신뢰성 향상에 대한 잠재능력을 잃게 되었다. 그 첫째로, 플랫폼 인터럽트는 여전히 VMM에 의해서 처리되어야 한다. 이는 물리적인 플랫폼의 나머지를 VMM이 소유하고 있기 때문이다. 인터럽트들은 적절한 guest로 라우팅되어야만 하는데 - 이러한 경우에는 물리 장치를 하나만이 소유하게 된다. 그러므로 인터럽트들을 전달하는데 여전히 약간의 오버헤드가 남게 된다. 둘째, 기존에 존재하는 플랫폼들은 장치가 직접적으로 data 전송을 효율적이고 안전한 방법을 통해서 자신이 속한 guest VM에 속한 system memory 로 전송하는 기능을 제공하지 않는다는 점이다. guest VM은 기본적으로 실제 물리 주소 공간의 일부에서 운영된다. guest VM이 물리 메모리라고 믿고 있는 것은 실제로는 물리 메모리가 아니라, 이는 guest 를 위해서 VMM에 의해서 가상화된 시스템 메모리의 일부인 것이다. 이러한 addressing mismatch 는 DMA-capable 장치에 의해서 문제점을 야기시킨다. 그러한 장치들은 data를 CPU의 관여없이 system memory로 직접 위치시키는데, guest 장치 드라이버가 장치로 하여금 guest 물리 주소들을 이용하여 데이터 전송을 시키려고 할때, 반면 하드웨어는 host 물리 주소들을 이용해서 시스템 메모리를 접근하려 하게 된다.

space space mismatch를 해결하기 위해서, 직접 접근을 혀용하는 VMM들은 guest VM 장치 드라이버와 하드웨어 장치간의 모든 통신에 대해서 intercept 들을 가하는 pass-through 드라이버를 사용하곤 한다. pass-through 드라이버는 guest physical과 physical address들을 언급하는 모든 명령 아규먼트들의 real physical address space간의 번역을 수행한다. Pasds-through 드라이버는 장치-제한적인데, 이는 필요한 번역을 수행하기 위해서 특정 장치를 위한 명령 포맷을 해것해야만 하기 때문이다. 그러한 드라이버들은 전통적인 장치 드라이버들보다는 간단한 작업을 수행하게 되는데; 그러인하여 성능은 에뮬레이션에 비해서 높게 나타난다. 그러나, VMM의 복잡도는 여전히 높고, 그로 인해서 VMM의 신뢰성에 좋지 않은 효과를 가져온다. 여전히 성능 이득에 대해서, 서버 공간을 목표로 하여, VMM에서 이러한 메소드를 도임합이 충분한 것으로 보이지만, 오직 비교적 작은 수의 공용 장치들만을 위한 직접 접근을 지원하게 되는 것도 사실이다.

VMM Software Architecture Implications

다른 I/O 가상화 메소드들은 모든 VMM 소프트웨어 구조 선택에 동등하게 적용되지 않는다.

에뮬레이션은 가장 일반적인 I/O 가상화 방법이고, 수정하지 않은 guest OS 에게 표준화된 I/O 장치들을 표출시키는 것이 가능하다. 그에 따라 기존의 OS-hosted, stand-alone hypervisor 혹은 hybrid VMM 구현에 많이 사용되고 있다.

이미 언급한 바와같이, paravirtualization은 공통 guest들의 성능을 높이기 위해서 점차 많은 VMM들에 의해서 사용되고 있다. 이는 stand-alone hypervisor VMM들에 쉽게 적용이 됐다. 이는 guest OS 와 OS-hosted VMM안의 ULM간의 interaction에 역시 사용될 수 있고, hybrid VMM에서 guest OS 와 service VM에서 사용될 수 있다.

직접 할당은, 수정하기 어렵거나 혹은 특정 응용을 위해서 paravirtualized guest 장치 드라이버들이 인정되지 않는 등으로 인한, guest OS를 수정할 수 없는 경우에 사용된다. 그러나, 일반적으로 그런 VMM들이 실제 플랫폼 장치들을 소유하고 있지 않고, 그런 장치들을 위한 장치 드라이버들을 유지보수하고 있지 않기 때문에, OS-hosted VMM에 직접 할당을 도입하는 것은 어려운 일이다. 다시 말하자면, 작접할당은 원천적으로 stand-alone hypervisor 와 hybrid VMM들에서 복잡도를 줄이는 데 사용되는데, 이는 장치드라이버들이 비교적 guest OS 혹은 service OS들로 이동하기 쉽기 때문이다.

하나의 VMM이 서로다른 다수의 I/O 가상화 기술들을 적용하는 것은 있을 법도 한 일이다. 예를 들어, hybrid VMM에서 직접 할당은 특정한 guest VM에 플랫폼 물리 장치를 할당하는데 사용할 수 있는데, 이때 할당된 플랫폼 물리 장치는 다른 guest들을 위해서 공유되는데 사용될 수 도 있다. guest의 필요와 충분이라는 입장에서 보면, 다른 guest들에게 paravirtualized 솔루션들 뿐만 아니라, emulated 장치 모델들을 제공할 수도 있다. 공통적인 설정 방법으로는 대부분의 공통 guest environment 들을 위해서 paravirtualized 솔루션들을 제공하고, 반면 emulation 솔루션은 모든 다른 legacy environment 들을 지원하는데 제공하는 것이 되겠다.

IOVM Architecture

가상화 소프트웨어 개발자들 간에 새롭게 나타난 주요한 트랜드는, 특히 I/O 프로세싱과 공유의 부분에서, VMM 시스템 decomposition이다.

VMM들의 소프트웨어 구조의 트렌드는 monolithic hypervisor model에서 VMM을 물리적인 하드웨어 바로 위에 존재하는 매우 얇은 privileged "micro-hypervisor"와 hypervisor 에 비해 de-privileged 된 하나 혹은 그이상의 특별한 목적을 갖는 (service 들과 policy를 담당하는) VM들로 나누어진 소프트웨어 구조로 변화하고 있는 것이다. I/O 가상화를 고려한 입장에서, 이러한 VMM의 deprivileged 컴포넌트들은 I/O 프로세싱과 I/O 자원 공유에 책임을 지게 된다. 우리는 이러한 일반적인구조를 (Figure 2와 같이) IOVM이라고 부른다. IOVM 모델은 특정 I/O 기능을 위해 특별히 만들어진 다른 service VM들에게 I/O 장치를 할당하는 hybrid VMM의 일종이라 볼수 있다.

IOVM 모델의 두 중요한 잇점은 IOVM 내의 수정되지 않은 장치 드라이버들을 사용할수 있는 것과 다른 guest OS들, 응용들, 그리고 hypervisor 로부터 물리 장치와 그 다르이버(들)을 격리시킬 수 있다는 것이다. 수정되지 않는 드라이버의 사용은 이러한 드라이버들이, VMM 환경을 위해서 종종 새로 작성되어야 하는 드라이버들을 필요로 하는 monolithic hypervisor와는 다르게, 분리된 OS 환경이서 이러한 드라이버들을 수행할 수 있기 때문에 가능해진다. 장치와 그 드라이버의 격리는 guest VM들이 드라이버 crash로부터 보호받게되는데, 즉 IOVM이 드라이버의 failure 로 인해서 crash되어도 guest OS에 영향가지 않게 된다는 것이다. IOVM 모델의 단점은 guest OS 와 IOVM간의 data 이동과 추가적인 통신이 필요함으로 인해서 오버헤드가 부가된다는 점이다. 이러한 성능에 대한 불이익은 IOVM의 인터페이스를 paravirtualizing 함에 있어서 상쇄시킬 수 있고, 그럼으로 인해서 interaction의 수를 줄일 수 있다. Xen VMM은 이러한 구조를 "Isolated Driver Domains" 라는 이름으로 구현해왔고, Microsoft도 그들의 차세대 VMM에서 이롸 같은 구조를 사용할 것으로 개발을 진행하고 있다.

IOVM으로의 I/O 장치들의 직접 할당은 직접적으로 이러한 사용모델을 수월하게 하고, VMM들이 이러한 구조로 옮겨가는데 중요한 역할을 하고 있다. 그러나 우리가 볼수 있듯이, 소프트웨어 자신만으로는 VMM에서 발생하는 모든 장치-제한적 기능을 제거함과 동시에 I/O 장치와 system memory같의 잘못된 DMA traffic으로부터 system을 완벽하게 보호할 수는 없다. 플랫폼에서 하드웨어의 지원으로 IOVM에 장치가 안전하게 할당되도록 지원하여 이러한 gap을 없에고 있고, 그럼으로써 잘못된 DMA 전송으로부터 완전한 보호를 제공하게 된다.