4. Domain 장치 드라이버 개발

Domain의 장치 드라이버 개발 설명에 앞서 왜 장치 드라이버 개발이 필요한지 먼저 알아보자.

일반적으로 OS는 각각의 드라이버(네트워크, 블록 등등)를 통해 실제 하드웨어 장치를 제어하는 시스템을 가지고 있다.

하지만 가상화 환경에서는 하드웨어는 하나인 상태에서 여러개의 OS가 떠있다. Xen 플랫폼 내에 구동중인 여러 Domain들이 각자 하드웨어 Device들을 각자의 방식으로 제어하려 한다면 어떻게 될까? 물건은 하나인데 주인이 여러명이 생기는 엉뚱한 상황이 벌어질 것이다. 각 Domain들의 하드웨어 통제권을 정리하기 위해 Xen은 Domain0에게 하드웨어를 제어하는 독점적인 권한을 주고 나머지 DomainU 들은 Domain0의 통해서 하드웨어에 접근 할 수 있도록 규칙을 세웠다.

간단히 도식화 하면 다음과 같다.

1. DomainU가 하드웨어 제어권을 가진 Domain0에게 하드웨어에 대한 접근을 요청한다
2. Domain0는 DomainU의 요청을 받고 드라이버를 통해 하드웨어에 접근한다.
3. 드라이버에서 받은 결과값은 DomainU에게 다시 전달한다.

크게 세가지 구조로 이뤄져 있지만 실제 구현 방식은 위와 같이 간단하지 않다. 하드웨어 접근 요청을 하는 방식과 결과 값을 어떻게 전달 할 것인지를 생각하면 머리가 복잡하다. 하지만 요청과 결과값을 전달하는 방식은 이미 한 번 다룬 바 있다. Domain 간의 통신 방법에서 grant table과 ring을 이용해 요청을 전달하고 데이터를 전송 할 수 있었다.

Xen 위에서 동작하는 Domain0와 DomainU 장치드라이버들 들을 위와 같은 방식으로 구현해준다. 위 방식을 적용한 드라이버들을 Para-Virtualization(반가상화) 이름을 따서 PV드라이버라고도 한다. 크게 하드웨어 접근을 요청하는 DomainU의 PV장치드라이버를 Frontend라 하고 접근을 받아 처리하는 Domain0의 PV드라이버를 Backend로 정의한다. 

실제로 위와 같은 구현 방식으로 되었다고 PV드라이버 개발이 끝나는 것이 아니다. 각 하드웨어 장치들마다 저마다 특별한 요구사항이 있다(네트워크 드라이버인 경우에는 가상 브릿지, 스위치... 매우 복잡하다) 하지만 공통적인 드라이버 작동 방식은 위와 동일하다.

* 위와 같은 구조를 가진다면 요청 작업  + 전달 받는 작업이 있기 때문에 DomainU가 하드웨어에 접근 할 때 오버헤드가 발생한다.  오버헤드를 피하기 위해 특정 하드웨어는 Domain0에게 제어권을 주지 않고, DomainU에 제어권을 주는 Passthrough 방식도 있다고 한다. 주로 그래픽 드라이버 처럼 대용량 데이터를 처리해야 하는 경우에 적용된다고 한다. https://wiki.xen.org/wiki/Xen_VGA_Passthrough 참고