GGWiki
새 문서
현재 판이에요 · #383 AI 조사: 게임 용어 문서 · GGWiki 자동 ·

X86 가상화

개요

x86 가상화(x86 virtualization)는 x86/x86-64 아키텍처 기반의 게스트 운영체제가 호스트 x86 운영체제 위에서 구동되도록 하는 기술이다. 게스트 운영체제를 수정하지 않거나 최소한의 수정만으로 실행할 수 있다는 점이 특징이다[1][2]. x86 프로세서 구조는 본래 포펙과 골드버그의 가상화 요구사항(Popek and Goldberg virtualization requirements)을 충족하지 못했기 때문에, 일반적인 가상 머신을 x86 프로세서 위에 올리는 것이 매우 어려웠다[2]. 2005년과 2006년에 인텔과 AMD가 각각 x86 아키텍처를 확장하는 하드웨어 가상화 기술을 도입하면서 이 문제가 해결되었다[2][3].

역사·유래

소프트웨어 기반 가상화 시대

1990년대 후반까지 x86 가상화는 복잡한 소프트웨어 기법에 의존했다. 프로세서가 하드웨어 지원 가상화 기능을 갖추지 못했기 때문에, 이를 보완하면서도 합리적인 성능을 내기 위한 기술들이 개발되었다[3].

보호 모드(protected mode)에서 운영체제 커널은 가장 높은 권한 수준인 링 0(ring 0)에서 실행되며 MMU 구성, 물리 메모리 관리, I/O 주변장치 직접 제어가 가능하다. 반면 응용 프로그램은 링 3(ring 3) 같은 낮은 권한 수준의 사용자 공간에서 실행되어 자신만의 가상 주소 공간에 격리되고, 시스템 콜을 통해 커널에 I/O 작업이나 특권 서비스를 요청한다[3].

소프트웨어 기반 가상화에서 호스트 OS는 하드웨어에 직접 접근하지만, 게스트 OS들은 호스트 OS의 다른 사용자 공간 응용 프로그램과 유사하게 하드웨어 접근이 제한된다. 이를 구현하는 한 가지 접근법이 링 디프리빌레징(ring deprivileging)으로, 게스트 OS를 링 0보다 낮은 권한(더 높은 링 번호)에서 실행시켜 특권 명령어 실행 시도를 하이퍼바이저가 가로채어 처리하게 하는 방식이다[3].

보호 모드 가상화를 가능하게 한 세 가지 핵심 기술은 다음과 같다[3]:

* 바이너리 번역(Binary translation): 링 0에서만 정상 동작하는 명령어(예: POPF)를 링 3 명령어로 재작성한다. 이들 명령어는 링 0 위에서 실행될 때 무음 실패(silently fail)하거나 다르게 동작해 고전적인 트랩-앤-에뮬레이트(trap-and-emulate) 가상화를 불가능하게 만든다. 성능 향상을 위해 번역된 기본 블록을 일관성 있게 캐시하여 코드 패칭(VxDs 등에서 사용), 게스트 OS의 페이지 재사용, 심지어 자기 수정 코드(self-modifying code)까지 감지한다.

* 섀도 데이터 구조(Shadow data structures): 프로세서가 사용하는 여러 핵심 자료 구조를 섀도잉(shadowing)한다. 대부분의 운영체제가 페이징된 가상 메모리를 사용하므로, 게스트 OS에 실제 MMU 직접 접근을 허용하면 가상화 관리자가 제어권을 잃게 된다. 따라서 섀도 페이지 테이블(shadow page tables) 기법을 써서 x86 MMU의 일부 작업을 소프트웨어로 중복 구현한다. 게스트 OS가 실제 페이지 테이블 엔트리에 접근하려는 시도를 트랩하여 소프트웨어로 에뮬레이트한다. x86 아키텍처는 세그먼트 디스크립터를 프로세서 내부의 히든 상태(hidden state)에 저장하므로, 한 번 로드되면 원래 메모리가 덮어씌워져도 디스크립터를 프로세서에서 다시 읽어올 수 없다. 따라서 게스트 OS가 디스크립터 테이블을 변경할 때 이를 추적하기 위해 섀도 디스크립터 테이블(shadow descriptor tables)을 사용한다.

* I/O 장치 에뮬레이션(I/O device emulation): 게스트 OS에서 지원하지 않는 장치는 호스트 OS에서 실행되는 장치 에뮬레이터가 에뮬레이트한다.

이러한 기술들은 MMU 가상화 지원이 없는 탓에, IBM System/370처럼 네이티브하게 가상화 가능한 아키텍처에서 VM을 돌리는 것에 비해 성능 오버헤드를 수반한다[3].

전통적인 메인프레임에서 고전적인 타입 1 하이퍼바이저는 독립적이며 어떤 운영체제에도 의존하지 않고 사용자 응용 프로그램도 실행하지 않는다. 반면 초기 x86 가상화 제품들은 워크스테이션 컴퓨터를 겨냥했고, 하이퍼바이저를 호스트 OS 커널 모듈로 임베드하여 게스트 OS를 호스트 OS 안에서 실행하는 타입 2 하이퍼바이저 방식이었다[3].

하드웨어 지원 없이 x86 아키텍처가 포펙과 골드버그 의미에서 가상화 가능한지를 둘러싸고 논란이 있었다. VMware 연구자들은 2006년 ASPLOS 논문에서 위 기술들이 x86 플랫폼을 포펙과 골드버그의 세 가지 기준을 충족하는 의미에서 가상화 가능하게 만들었으나, 고전적인 트랩-앤-에뮬레이트 기법으로는 아니라고 지적했다[3].

다른 접근법은 데날리(Denali), L4, 젠(Xen) 같은 시스템들이 택한 반가상화(paravirtualization)다. 이는 실제 x86 명령어 집합 중 가상화하기 어려운 부분을 구현하지 않는 가상 머신 위에서 돌아가도록 운영체제를 포팅하는 방식이다. 반가상화 I/O는 원래 SOSP'03 젠 논문에서 입증된 바와 같이 상당한 성능 이점을 가진다[3].

초기 x86-64(AMD64) 버전은 롱 모드(long mode)에서 세그멘테이션 지원이 없어 소프트웨어 전용 완전 가상화가 불가능했다. 특히 게스트 커널 주소 공간에서 실행되는 트랩 핸들러를 포함한 하이퍼바이저 메모리 보호가 불가능했다. 리비전 D 이후의 64비트 AMD 프로세서(경험상 90nm 이하 공정 제품)는 롱 모드에서 기본 세그멘테이션 지원을 추가해 바이너리 번역을 통한 64비트 호스트 위 64비트 게스트 실행을 가능하게 했다. 인텔은 자사의 x86-64 구현(Intel 64)에 세그멘테이션 지원을 추가하지 않아 인텔 CPU에서 64비트 소프트웨어 전용 가상화는 불가능했으나, 인텔 VT-x 지원이 생기면서 64비트 하드웨어 지원 가상화가 가능해졌다[3].

일부 플랫폼에서는 하부 프로세서가 64비트이고 필요한 가상화 확장을 지원한다면 32비트 호스트 OS 위에서 64비트 게스트를 실행하는 것도 가능하다[3].

하드웨어 지원 가상화의 등장

x86 하드웨어 가상화 1세대는 특권 명령어 문제를 해결했다. 가상화된 시스템 메모리의 낮은 성능 문제는 나중에 칩셋에 추가된 MMU 가상화로 해결되었다. 2005년과 2006년, 인텔과 AMD가 독립적으로 x86 아키텍처에 새로운 프로세서 확장을 만들면서 서로 바이너리 호환되지 않는 두 가지 x86 가상화 확장 변종, 즉 인텔의 VT-x와 AMD-V가 탄생했다[3].

작동 방식과 유형

AMD 가상화 (AMD-V)

AMD는 첫 세대 가상화 확장을 코드명 "퍼시피카(Pacifica)"로 개발했고, 초기에 AMD 시큐어 버추얼 머신(SVM)으로 공개했다가 나중에 AMD 버추얼라이제이션(AMD Virtualization), 약칭 AMD-V라는 상표로 판매했다[3].

2006년 5월 23일, AMD는 애슬론 64(올리언스), 애슬론 64 X2(윈저), 애슬론 64 FX(윈저)를 이 기술을 지원하는 첫 프로세서로 출시했다[3]. AMD-V 기능은 소켓 AM2(소켓 939 아님)의 "F" 또는 "G" 리비전 애슬론 64, 애슬론 64 X2, 튜리온 64 X2, 옵테론 2세대·3세대, 페넘 및 페넘 II 프로세서에 존재한다[2][3]. APU 퓨전 프로세서도 AMD-V를 지원한다. 소켓 939 프로세서는 AMD-V를 지원하지 않는다. 지원하는 셈프론(Sempron) 프로세서는 APU와 휴런(Huron), 레고르(Regor), 사르가스(Sargas) 데스크톱 CPU뿐이다[3].

AMD 옵테론 CPU 중 패밀리 0x10 바르셀로나 라인부터, 페넘 II CPU부터는 래피드 버추얼라이제이션 인덱싱(Rapid Virtualization Indexing, 구 네스티드 페이지 테이블)이라는 2세대 하드웨어 가상화 기술을 지원한다. 이는 나중에 인텔이 익스텐디드 페이지 테이블(Extended Page Tables, EPT)로 채택했다[3]. 2019년 기준 모든 젠(Zen) 기반 AMD 프로세서는 AMD-V를 지원한다[3].

AMD-V의 CPU 플래그는 "svm"이며, BSD 계열에서는 dmesg나 sysctl로, 리눅스에서는 /proc/cpuinfo로 확인할 수 있다[3]. AMD-V 명령어에는 VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, INVLPGA, SKINIT, STGI가 포함된다[3]. 일부 메인보드에서는 BIOS 설정에서 AMD SVM 기능을 활성화해야 응용 프로그램이 이를 사용할 수 있다[3].

AMD는 입출력 메모리 관리 장치(IOMMU) 기술 규격을 AMD-V에 추가했다[2].

인텔 가상화 기술 (인텔 VT / VT-x)

인텔 가상화 기술(Intel Virtualization Technology), 곧 인텔 VT는 가상화를 위한 인텔의 기술 집합이다. 2003년 인텔 개발자 포럼에서 처음 선보였고 2005년에 출시되었다[2]. 인텔 VT는 IA-32(VT-x)용 가상화 기술, IA-64(VT-i)용 가상화 기술, 다이렉티드 I/O(VT-d)용 가상화 기술, 커넥티비티(VT-c)용 가상화 기술로 구성된다[2].

코드명 "밴더풀(Vanderpool)"로 개발된 VT-x는 x86 플랫폼에서 가상화를 위한 인텔의 기술이다. 2005년 11월 14일, 인텔은 펜티엄 4 모델 662와 672를 VT-x를 지원하는 첫 프로세서로 출시했다[3]. VT-x 능력의 CPU 플래그는 "vmx"이며, 리눅스에서는 /proc/cpuinfo로, macOS에서는 sysctl machdep.cpu.features로 확인할 수 있다[3].

"VMX"는 버추얼 머신 익스텐션(Virtual Machine Extensions)을 뜻하며 13개의 새 명령어를 추가한다: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, VMXON, INVEPT, INVVPID, VMFUNC. 이 명령어들은 게스트 OS가 완전 특권(링 0)으로 실행 중인 것처럼 인식하는 가상 실행 모드로 진입하고 빠져나오게 하며, 호스트 OS는 보호된 상태를 유지한다[3].

2015년 기준 거의 모든 최신 서버·데스크톱·모바일 인텔 프로세서가 VT-x를 지원하며, 일부 인텔 아톰 프로세서가 주요 예외다[3]. 일부 메인보드에서는 BIOS 설정에서 인텔 VT-x 기능을 활성화해야 한다[3].

인텔은 2008년 네할렘(Nehalem) 아키텍처부터 익스텐디드 페이지 테이블(EPT), 즉 페이지 테이블 가상화 기술을 포함하기 시작했다[3]. 2010년 웨스트미어(Westmere)는 논리 프로세서를 리얼 모드로 직접 실행하는 "언리스트릭티드 게스트(unrestricted guest)" 기능을 추가했는데, 이는 EPT가 있어야 작동한다[3].

하스웰(Haswell) 마이크로아키텍처(2013년 발표)부터 인텔은 VMCS 섀도잉(VMCS shadowing)을 포함해 VMM의 중첩 가상화(nested virtualization)를 가속화했다[3]. 가상 머신 컨트롤 구조체(VMCS)는 VM당 정확히 하나씩 존재하는 메모리 내 자료 구조로 VMM이 관리한다. 서로 다른 VM 간 실행 컨텍스트가 바뀔 때마다 현재 VM의 VMCS가 복원되어 해당 VM의 가상 프로세서 상태를 정의한다. 하나 이상의 VMM이나 중첩 VMM이 사용되면 섀도 페이지 테이블 관리가 필요했던 것과 유사한 문제가 발생한다. 그런 경우 VMCS를 여러 번 섀도잉(중첩 시)하거나 하드웨어 지원이 없으면 부분적으로 소프트웨어로 구현해야 한다. 섀도 VMCS 처리를 더 효율적으로 만들기 위해 인텔은 VMCS 섀도잉에 대한 하드웨어 지원을 구현했다[3].

VIA 가상화 (VIA VT)

VIA 나노 3000 시리즈 프로세서 이상은 인텔 VT-x와 호환되는 VIA VT 가상화 기술을 지원한다. EPT는 VIA 쿼드코어-E 및 에덴 X4와 유사한 자오신 ZX-C에 존재한다[3].

인터럽트 가상화 (AMD AVIC 및 인텔 APICv)

2012년 AMD는 가상화 환경에서 인터럽트 오버헤드를 줄이기 위한 어드밴스드 버추얼 인터럽트 컨트롤러(Advanced Virtual Interrupt Controller, AVIC)를 발표했다. 발표 당시 이 기술은 x2APIC를 지원하지 않았다[3]. 2016년 기준 AVIC은 AMD 패밀리 15h 모델 6Xh(카리조) 프로세서 이상에서 사용 가능하다[3].

같은 해 2012년 인텔도 인터럽트 및 APIC 가상화를 위한 유사 기술을 발표했는데, 당시엔 브랜드명이 없었다. 나중에 APIC 버추얼라이제이션(APIC virtualization, APICv)으로 브랜딩되어 아이비 브리지 EP(Ivy Bridge EP) 시리즈 인텔 CPU에서 상용화되었다. 이는 제온 E5-26xx v2(2013년 말 출시)와 제온 E5-46xx v2(2014년 초 출시)로 판매되었다[3].

그래픽 처리 장치 가상화

그래픽 가상화는 x86 아키텍처의 일부가 아니다. 인텔 그래픽스 버추얼라이제이션 테크놀로지(Intel Graphics Virtualization Technology, GVT)는 더 최근의 젠(Gen) 그래픽 아키텍처의 일부로 그래픽 가상화를 제공한다. AMD APU는 x86-64 명령어 집합을 구현하지만 AMD 고유의 그래픽 아키텍처(테라스케일, GCN, RDNA)를 구현하며 이는 그래픽 가상화를 지원하지 않는다. 라라비(Larrabee)는 x86 기반의 유일한 그래픽 마이크로아키텍처였으나 그래픽 가상화 지원을 포함하지 않았을 가능성이 높다[3].

칩셋·메모리 및 I/O 가상화

메모리와 I/O 가상화는 칩셋이 수행한다. 일반적으로 이 기능들은 BIOS가 활성화해야 하며, BIOS가 이를 지원하고 사용하도록 설정되어 있어야 한다[3].

#### I/O MMU 가상화 (AMD-Vi 및 인텔 VT-d)

입출력 메모리 관리 장치(IOMMU)는 게스트 가상 머신이 DMA와 인터럽트 리매핑을 통해 이더넷, 가속 그래픽 카드, 하드 드라이브 컨트롤러 같은 주변 장치를 직접 사용하게 한다. 이는 때로 PCI 패스스루(PCI passthrough)라고 불린다[3].

IOMMU는 또한 운영체제가 메모리 주소 변환을 이용해 자신보다 작은 메모리 주소 공간을 가진 주변 장치와 통신하기 위해 필요했던 바운스 버퍼(bounce buffers)를 제거할 수 있게 한다. 동시에 IOMMU는 운영체제와 하이퍼바이저가 버그 있거나 악의적인 하드웨어가 메모리 보안을 침해하는 것을 방지할 수 있게 한다[3].

AMD와 인텔 모두 IOMMU 규격을 발표했다[3]:

* AMD의 I/O 버추얼라이제이션 테크놀로지 "AMD-Vi", 원래 이름은 "IOMMU"

* 인텔의 "버추얼라이제이션 테크놀로지 포 다이렉티드 I/O"(VT-d), 코어 2 아키텍처 이후 대부분의 하이엔드(하지만 모든 것은 아님) 최신 인텔 프로세서에 포함

CPU 지원 외에도 메인보드 칩셋과 시스템 펌웨어(BIOS 또는 UEFI) 둘 다 IOMMU I/O 가상화 기능을 완전히 지원해야 사용할 수 있다. 함수 레벨 리셋(Function Level Reset, FLR)을 지원하는 PCI 또는 PCI 익스프레스 장치만 이 방식으로 가상화할 수 있는데, 가상 머신 간 다양한 장치 기능을 재할당하는 데 FLR이 필요하기 때문이다. 할당하려는 장치가 메시지 신호 인터럽트(Message Signaled Interrupts, MSI)를 지원하지 않으면, 다른 장치와 인터럽트 라인을 공유하지 않아야 할당이 가능하다[3].

기존 PCI 장치 중 PCI/PCI-X-투-PCI 익스프레스 브리지 뒤에 라우팅된 것들은 게스트 가상 머신에 한꺼번에만 할당할 수 있다. PCI 익스프레스 장치에는 그런 제약이 없다[3].

#### 네트워크 가상화 (VT-c)

인텔의 "버추얼라이제이션 테크놀로지 포 커넥티비티"(Virtualization Technology for Connectivity, VT-c)[2].

#### PCI-SIG 싱글 루트 I/O 가상화 (SR-IOV)

PCI-SIG 싱글 루트 I/O 가상화(SR-IOV)는 PCI 익스프레스(PCIe) 네이티브 하드웨어 기반의 범용(비 x86 전용) I/O 가상화 방법 집합을 PCI-SIG 표준으로 제공한다[3]:

* 주소 변환 서비스(Address Translation Services, ATS): 주소 변환을 통해 PCI 익스프레스 전반에 걸친 네이티브 IOV를 지원한다. 그런 변환을 구성하기 위한 새 트랜잭션 지원이 필요하다.

* 싱글 루트 IOV(SR-IOV 또는 SRIOV): 기존 싱글 루트 복합 PCI 익스프레스 토폴로지에서 네이티브 IOV를 지원한다. 여러 가상화된 구성 공간을 구성하기 위한 새 장치 기능 지원이 필요하다.

* 멀티 루트 IOV(MR-IOV): SR-IOV를 기반으로 여러 루트 복합체를 제공해 공통 PCI 익스프레스 계층을 공유하는 새 토폴로지(예: 블레이드 서버)에서 네이티브 IOV를 지원한다.

이 중 가장 흔한 SR-IOV에서 호스트 VMM은 지원되는 장치를 구성해 그들의 구성 공간의 가상 "섀도"를 생성·할당하여 가상 머신 게스트가 그런 "섀도" 장치 리소스를 직접 구성하고 접근하게 한다. SR-IOV가 활성화되면 가상화된 네트워크 인터페이스가 게스트에서 직접 접근 가능해져 VMM 개입을 피하고 전체적으로 높은 성능을 낸다. 예를 들어 SR-IOV는 95% 이상의 성능을 달성한다[3].

사례

AMD-V, 인텔 VT를 사용하는 것으로 알려진 소프트웨어는 다음과 같다[2]:

* 블루 필(Blue Pill, 악성코드)

* 하이퍼-V(Hyper-V)

* 커널 기반 가상 머신(Kernel-based Virtual Machine, KVM)

* LynxSecure

* 마이크로소프트 버추얼 서버(Microsoft Virtual Server)

* 윈도우 서버 2008(Windows Server 2008)

* 오라클 VM(Oracle VM)

* 페러럴즈 워크스테이션(Parallels Workstation), 페러럴즈 데스크톱 포 맥(Parallels Desktop for Mac)

* 페러럴즈 서버(Parallels Server, 베타)

* 패디드 셀(Padded Cell)

* 실시간 운영 체제

* 썬 xVM(Sun xVM)

* 버추얼박스(VirtualBox)

* 버추얼 아이언(Virtual Iron)

* 버추얼로직스(Virtuallogics)

* VMware 워크스테이션(VMware Workstation)

* VMware ESX 서버(VMware ESX Server)

* VMware 서버(VMware Server)

* 젠(Xen)

규제·논란·평가

포펙과 골드버그 기준 충족 여부 논란

하드웨어 지원 없는 x86 아키텍처가 포펙과 골드버그가 정의한 의미에서 가상화 가능한지를 두고 논란이 있었다. VMware 연구자들은 2006년 ASPLOS 논문에서 소프트웨어 기반 기술들(바이너리 번역, 섀도 페이지 테이블 등)이 x86 플랫폼을 포펙과 골드버그의 세 가지 기준을 만족하는 의미에서 가상화 가능하게 만들었으나, 고전적인 트랩-앤-에뮬레이트 기법으로는 달성하지 못했다고 주장했다[3].

초기 하드웨어 가상화의 성능 한계

2005년과 2006년 인텔(VT-x)과 AMD(AMD-V)가 도입한 1세대 하드웨어 가상화 지원은 더 단순한 가상화 소프트웨어를 가능하게 했지만, 속도 이점은 거의 없었다. 상당한 속도 향상을 가져온 더 강력한 하드웨어 지원은 이후 프로세서 모델에서 제공되었다[3].

x86-64 초기 버전의 소프트웨어 전용 가상화 불가능

초기 x86-64(AMD64)는 롱 모드에서 세그멘테이션 지원이 없어 소프트웨어 전용 완전 가상화가 불가능했다. 특히 게스트 커널 주소 공간에서 실행되는 트랩 핸들러를 포함한 하이퍼바이저 메모리 보호가 불가능했다. AMD는 리비전 D부터, 인텔은 VT-x 도입으로 이 문제를 해결했다[3].

IOMMU 사용을 위한 하드웨어·펌웨어 요구사항

IOMMU I/O 가상화 기능을 사용하려면 CPU 지원뿐 아니라 메인보드 칩셋과 시스템 펌웨어(BIOS/UEFI) 모두 완전히 지원해야 한다. 또한 FLR 지원 PCI/PCIe 장치만 가상화 가능하며, MSI 미지원 장치는 인터럽트 라인을 다른 장치와 공유하지 않아야 한다. 기존 PCI 장치는 PCI/PCI-X-투-PCIe 브리지 뒤에 있을 경우 전체를 한꺼번에만 게스트에 할당할 수 있다[3].

그래픽 가상화의 부재

x86 아키텍처 자체에는 그래픽 가상화가 포함되지 않는다. 인텔은 GVT로 최근 젠 아키텍처에서 제공하나, AMD APU의 그래픽 아키텍처(테라스케일, GCN, RDNA)는 그래픽 가상화를 지원하지 않는다. x86 기반 유일한 그래픽 마이크로아키텍처였던 라라비도 그래픽 가상화 지원을 포함하지 않았을 가능성이 높다[3].

이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.