VFIO, Passthrough
VFIO (Virtual Function I/O)
일반적으로 유저 애플리케이션에서 특정 장치를 이용하기 위해선 먼저 Host OS에서 해당 장치를 전담하는 유저 서비스(안드로이드는 surface flinger 같은게 있다)에게 요청하고, 유저 서비스는 커널 단의 장치 드라이버에 작업을 전달하며 장치 드라이버는 전달 받은 요청에 따라 장치를 실제로 움직이게 된다. 이러한 형태는 유저 앱의 입장에서 꽤 단순한 작업을 해도 커널 단의 장치드라이버에 불필요한 작업이 많다면 이에 비례해서 처리하는 시간이 늘어나게돼 유저앱의 성능이 저하되는 일이 발생한다.
이를 해결하고자 리눅스 커널에서는 유저 영역에서 직접 장치에 접근 할 수 있는 플랫폼을 만들었다. 간단히 말해 장치 드라이버를 커널에 두지 않고 유저 영역에 드라이버를 둘 수 있는 형태다. 이런 구조는 불필요한 커널 스택을 거치지 않고 사용 목적에 따라 드라이버를 만들 수 있기 때문에 효율적이고 최적화된 코드를 짤 수 있으며 혹시나 만든 드라이버가 죽더라도 커널 영역이 아니기 때문에 시스템 전체가 크러쉬되는 부담은 줄어드는 장점이 있다. 그리고 무엇보다 회사 입장에서는 유저 영역에서 코드를 작성하기 때문에 GPL 라이센스를 따르지 않아 코드를 공개하지 않아도 되는 메리트가 있기도 하다. (물론 오픈소스 철학과는 상반되지만)
Passthrough
애초에 Type2 하이퍼바이저를 목표로두고 설계한 구조는 아니지만 구글에 VFIO를 치면 QEMU와 연관된 자료들이 무수히 많이 나오는데 아마 VFIO를 가장 유용하게 사용할 수 있는 대표적인 예가 가상화이기 때문에 그런것 같다. QEMU에서 만들어준 장치들은 이미 VM내의 커널 드라이버를 거치고 왔기 때문에 그 이후 이뤄지는 Host 커널 영역에서 이뤄지는 작업은 어찌보면 같은 일은 두번 반복하는 불필요한 작업이기도 하다. 이때 VFIO를 사용하면 불필요한 작업 없이 에뮬레이션 장치의 결과물을 그래도 실제 장치에 전달 할 수 없어 성능을 대폭 향상 시킬 수 있다. VM이 직접 장치에 접근 할 수 있는 구조가 되는 것이다.
이처럼 Guest가 Host의 중재 없이 직접 장치에 접근 할 수 있는 구조를 Passthrough라고 한다. 여기서 VFIO는 Type2 하이퍼바이저에서 Passthrough를 할 수 있는 일종의 플랫폼 역할을 하는 것이며 Xen과 같은 Type1 하이퍼바이저에서는 장치를 front/backend의 형태로 안쓰고 Guest가 native driver를 사용할 수 있도록 변형해서 Passthrough를 사용한다.
그림 1. VFIO 개념도
간단하게 그래픽 장치에 바로 접근한다고 설명했지만 실제로 고려해야할 일들은 무수히 많다. 벤더에 따라서 해야하는 일이 천차만별.
주로 그래픽카드와 네트워크 장치에 사용한다.
참고자료
- Virtual Open System, vfio에 대해서 전반적인 소개를 하는 자료.
- Platform Device Assignment to KVM-on-ARM Virtual Machines via VFIO 논문, 그림을 가져왔다. 자세하게 설명해주고 있어 많은 도움이 됐다.