Nested VMX | Linux 6.18.37

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

nested-vmx.rst:1-244

Nested VMX가 한 단계 hardware VMX 위에서 L1 hypervisor와 L2 guest를 실행하는 원리와 설정을 설명합니다.

VMCS01·VMCS12·VMCS02의 관계와 live migration 호환성에 영향을 주는 `struct vmcs12` 전체 field layout을 구조화했습니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기

1 .. SPDX-License-Identifier: GPL-2.0

3 ==========

4 Nested VMX

5 ==========

7 Overview

8 ---------

10 On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions)

11 to easily and efficiently run guest operating systems. Normally, these guests

12 *cannot* themselves be hypervisors running their own guests, because in VMX,

13 guests cannot use VMX instructions.

15 The "Nested VMX" feature adds this missing capability - of running guest

16 hypervisors (which use VMX) with their own nested guests. It does so by

17 allowing a guest to use VMX instructions, and correctly and efficiently

18 emulating them using the single level of VMX available in the hardware.

20 We describe in much greater detail the theory behind the nested VMX feature,

21 its implementation and its performance characteristics, in the OSDI 2010 paper

22 "The Turtles Project: Design and Implementation of Nested Virtualization",

23 available at:

25 https://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf

28 Terminology

29 -----------

31 Single-level virtualization has two levels - the host (KVM) and the guests.

32 In nested virtualization, we have three levels: The host (KVM), which we call

33 L0, the guest hypervisor, which we call L1, and its nested guest, which we

34 call L2.

37 Running nested VMX

38 ------------------

40 The nested VMX feature is enabled by default since Linux kernel v4.20. For

41 older Linux kernel, it can be enabled by giving the "nested=1" option to the

42 kvm-intel module.

45 No modifications are required to user space (qemu). However, qemu's default

46 emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be

47 explicitly enabled, by giving qemu one of the following options:

49 - cpu host (emulated CPU has all features of the real CPU)

51 - cpu qemu64,+vmx (add just the vmx feature to a named CPU type)

54 ABIs

55 ----

57 Nested VMX aims to present a standard and (eventually) fully-functional VMX

58 implementation for the a guest hypervisor to use. As such, the official

59 specification of the ABI that it provides is Intel's VMX specification,

60 namely volume 3B of their "Intel 64 and IA-32 Architectures Software

61 Developer's Manual". Not all of VMX's features are currently fully supported,

62 but the goal is to eventually support them all, starting with the VMX features

63 which are used in practice by popular hypervisors (KVM and others).

65 As a VMX implementation, nested VMX presents a VMCS structure to L1.

66 As mandated by the spec, other than the two fields revision_id and abort,

67 this structure is *opaque* to its user, who is not supposed to know or care

68 about its internal structure. Rather, the structure is accessed through the

69 VMREAD and VMWRITE instructions.

70 Still, for debugging purposes, KVM developers might be interested to know the

71 internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c.

73 The name "vmcs12" refers to the VMCS that L1 builds for L2. In the code we

74 also have "vmcs01", the VMCS that L0 built for L1, and "vmcs02" is the VMCS

75 which L0 builds to actually run L2 - how this is done is explained in the

76 aforementioned paper.

78 For convenience, we repeat the content of struct vmcs12 here. If the internals

79 of this structure changes, this can break live migration across KVM versions.

80 VMCS12_REVISION (from vmx.c) should be changed if struct vmcs12 or its inner

81 struct shadow_vmcs is ever changed.

83 ::

85 typedef u64 natural_width;

86 struct __packed vmcs12 {

87 /* According to the Intel spec, a VMCS region must start with

88 * these two user-visible fields */

89 u32 revision_id;

90 u32 abort;

92 u32 launch_state; /* set to 0 by VMCLEAR, to 1 by VMLAUNCH */

93 u32 padding[7]; /* room for future expansion */

95 u64 io_bitmap_a;

96 u64 io_bitmap_b;

97 u64 msr_bitmap;

98 u64 vm_exit_msr_store_addr;

99 u64 vm_exit_msr_load_addr;

100 u64 vm_entry_msr_load_addr;

101 u64 tsc_offset;

102 u64 virtual_apic_page_addr;

103 u64 apic_access_addr;

104 u64 ept_pointer;

105 u64 guest_physical_address;

106 u64 vmcs_link_pointer;

107 u64 guest_ia32_debugctl;

108 u64 guest_ia32_pat;

109 u64 guest_ia32_efer;

110 u64 guest_pdptr0;

111 u64 guest_pdptr1;

112 u64 guest_pdptr2;

113 u64 guest_pdptr3;

114 u64 host_ia32_pat;

115 u64 host_ia32_efer;

116 u64 padding64[8]; /* room for future expansion */

117 natural_width cr0_guest_host_mask;

118 natural_width cr4_guest_host_mask;

119 natural_width cr0_read_shadow;

120 natural_width cr4_read_shadow;

121 natural_width dead_space[4]; /* Last remnants of cr3_target_value[0-3]. */

122 natural_width exit_qualification;

123 natural_width guest_linear_address;

124 natural_width guest_cr0;

125 natural_width guest_cr3;

126 natural_width guest_cr4;

127 natural_width guest_es_base;

128 natural_width guest_cs_base;

129 natural_width guest_ss_base;

130 natural_width guest_ds_base;

131 natural_width guest_fs_base;

132 natural_width guest_gs_base;

133 natural_width guest_ldtr_base;

134 natural_width guest_tr_base;

135 natural_width guest_gdtr_base;

136 natural_width guest_idtr_base;

137 natural_width guest_dr7;

138 natural_width guest_rsp;

139 natural_width guest_rip;

140 natural_width guest_rflags;

141 natural_width guest_pending_dbg_exceptions;

142 natural_width guest_sysenter_esp;

143 natural_width guest_sysenter_eip;

144 natural_width host_cr0;

145 natural_width host_cr3;

146 natural_width host_cr4;

147 natural_width host_fs_base;

148 natural_width host_gs_base;

149 natural_width host_tr_base;

150 natural_width host_gdtr_base;

151 natural_width host_idtr_base;

152 natural_width host_ia32_sysenter_esp;

153 natural_width host_ia32_sysenter_eip;

154 natural_width host_rsp;

155 natural_width host_rip;

156 natural_width paddingl[8]; /* room for future expansion */

157 u32 pin_based_vm_exec_control;

158 u32 cpu_based_vm_exec_control;

159 u32 exception_bitmap;

160 u32 page_fault_error_code_mask;

161 u32 page_fault_error_code_match;

162 u32 cr3_target_count;

163 u32 vm_exit_controls;

164 u32 vm_exit_msr_store_count;

165 u32 vm_exit_msr_load_count;

166 u32 vm_entry_controls;

167 u32 vm_entry_msr_load_count;

168 u32 vm_entry_intr_info_field;

169 u32 vm_entry_exception_error_code;

170 u32 vm_entry_instruction_len;

171 u32 tpr_threshold;

172 u32 secondary_vm_exec_control;

173 u32 vm_instruction_error;

174 u32 vm_exit_reason;

175 u32 vm_exit_intr_info;

176 u32 vm_exit_intr_error_code;

177 u32 idt_vectoring_info_field;

178 u32 idt_vectoring_error_code;

179 u32 vm_exit_instruction_len;

180 u32 vmx_instruction_info;

181 u32 guest_es_limit;

182 u32 guest_cs_limit;

183 u32 guest_ss_limit;

184 u32 guest_ds_limit;

185 u32 guest_fs_limit;

186 u32 guest_gs_limit;

187 u32 guest_ldtr_limit;

188 u32 guest_tr_limit;

189 u32 guest_gdtr_limit;

190 u32 guest_idtr_limit;

191 u32 guest_es_ar_bytes;

192 u32 guest_cs_ar_bytes;

193 u32 guest_ss_ar_bytes;

194 u32 guest_ds_ar_bytes;

195 u32 guest_fs_ar_bytes;

196 u32 guest_gs_ar_bytes;

197 u32 guest_ldtr_ar_bytes;

198 u32 guest_tr_ar_bytes;

199 u32 guest_interruptibility_info;

200 u32 guest_activity_state;

201 u32 guest_sysenter_cs;

202 u32 host_ia32_sysenter_cs;

203 u32 padding32[8]; /* room for future expansion */

204 u16 virtual_processor_id;

205 u16 guest_es_selector;

206 u16 guest_cs_selector;

207 u16 guest_ss_selector;

208 u16 guest_ds_selector;

209 u16 guest_fs_selector;

210 u16 guest_gs_selector;

211 u16 guest_ldtr_selector;

212 u16 guest_tr_selector;

213 u16 host_es_selector;

214 u16 host_cs_selector;

215 u16 host_ss_selector;

216 u16 host_ds_selector;

217 u16 host_fs_selector;

218 u16 host_gs_selector;

219 u16 host_tr_selector;

220 };

221

222

223 Authors

224 -------

225

226 These patches were written by:

227 - Abel Gordon, abelg <at> il.ibm.com

228 - Nadav Har'El, nyh <at> il.ibm.com

229 - Orit Wasserman, oritw <at> il.ibm.com

230 - Ben-Ami Yassor, benami <at> il.ibm.com

231 - Muli Ben-Yehuda, muli <at> il.ibm.com

232

233 With contributions by:

234 - Anthony Liguori, aliguori <at> us.ibm.com

235 - Mike Day, mdday <at> us.ibm.com

236 - Michael Factor, factor <at> il.ibm.com

237 - Zvi Dubitzky, dubi <at> il.ibm.com

238

239 And valuable reviews by:

240 - Avi Kivity, avi <at> redhat.com

241 - Gleb Natapov, gleb <at> redhat.com

242 - Marcelo Tosatti, mtosatti <at> redhat.com

243 - Kevin Tian, kevin.tian <at> intel.com

244 - and others.

245

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Nested VMX 개요

1-26

Intel processor에서 KVM은 VMX(Virtual-Machine eXtensions)를 사용해 guest operating system을 효율적으로 실행합니다. 일반적인 단일 단계 VMX에서는 guest가 VMX instruction을 사용할 수 없으므로 guest 자체가 hypervisor가 되어 다시 guest를 실행할 수 없습니다.

Nested VMX는 guest hypervisor에 VMX instruction 사용을 허용하고, hardware가 제공하는 단 하나의 VMX 단계 위에서 그 instruction을 정확하고 효율적으로 emulation해 이 제약을 해결합니다. 따라서 VMX를 사용하는 guest hypervisor가 자체 nested guest를 실행할 수 있습니다.

이 기능의 이론, 구현과 성능 특성은 OSDI 2010 논문 `The Turtles Project: Design and Implementation of Nested Virtualization`에 더 자세히 설명되어 있습니다. 원문에 수록된 USENIX 링크를 참고할 수 있습니다.

핵심은 L1에 두 번째 물리 VMX engine을 제공하는 것이 아니라, L1이 보는 가상 VMX 상태와 L0가 hardware에 넣는 실제 VMX 상태를 KVM이 중재한다는 점입니다. L1의 VMX instruction 결과와 L2의 VM exit도 Intel VMX 규칙에 맞게 다시 L1에 전달해야 합니다.

단일 VMX와 Nested VMX

모드Guest VMX instruction실행 가능한 계층

Single-level VMX허용되지 않음Host와 일반 guest

Nested VMXKVM이 emulationHost, guest hypervisor, nested guest

Hardware한 단계 VMX 제공KVM이 여러 논리 계층으로 구성

Guest가 VMX instruction을 사용할 수 있는지에 따른 차이입니다.

Nested VMX의 핵심

L1 guest hypervisor가 VMX instruction 실행L0 KVM이 instruction과 VMCS 동작을 포착L0가 hardware VMX 한 단계에 맞게 상태를 합성합성한 상태로 L2 nested guest 실행

한 단계 hardware VMX로 두 단계 guest 실행을 실현합니다.

.. SPDX-License-Identifier: GPL-2.0

==========
Nested VMX
==========

Overview
---------

On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions)
to easily and efficiently run guest operating systems. Normally, these guests
*cannot* themselves be hypervisors running their own guests, because in VMX,
guests cannot use VMX instructions.

The "Nested VMX" feature adds this missing capability - of running guest
hypervisors (which use VMX) with their own nested guests. It does so by
allowing a guest to use VMX instructions, and correctly and efficiently
emulating them using the single level of VMX available in the hardware.

We describe in much greater detail the theory behind the nested VMX feature,
its implementation and its performance characteristics, in the OSDI 2010 paper
"The Turtles Project: Design and Implementation of Nested Virtualization",
available at:

	https://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf

L0, L1, L2 용어

27-35

단일 단계 virtualization은 host KVM과 guest라는 두 계층으로 구성됩니다. Nested virtualization에서는 계층을 명확히 구분하기 위해 host KVM을 L0, guest hypervisor를 L1, L1이 실행하는 nested guest를 L2라고 부릅니다.

숫자는 privilege level이나 x86 ring이 아니라 virtualization 중첩 단계를 나타냅니다. L0가 실제 hardware VMX를 소유하고 L1은 L0가 제공하는 VMX ABI를 사용하며 L2는 L1이 만든 virtual machine으로 실행됩니다.

L2에서 발생한 exit 중 일부는 L0가 직접 처리하고, L1이 요청한 interception에 해당하는 것은 nested VM exit 형태로 L1에 반영됩니다. 따라서 계층 이름은 상태의 소유자와 exit의 최종 수신자를 구분할 때도 중요합니다.

Nested virtualization 계층

계층역할VMX 관점

L0Host KVM실제 hardware VMX를 제어

L1Guest hypervisorEmulated VMX ABI를 사용해 L2 구성

L2Nested guestL1이 관리하는 guest operating system

각 계층의 역할과 VMX 관점을 정리합니다.

제어 관계

L0 KVML1 guest hypervisorL2 nested guest

L2 실행 요청이 L1을 거쳐 L0 hardware 제어로 이어집니다.


Terminology
-----------

Single-level virtualization has two levels - the host (KVM) and the guests.
In nested virtualization, we have three levels: The host (KVM), which we call
L0, the guest hypervisor, which we call L1, and its nested guest, which we
call L2.

Nested VMX 실행

36-53

Nested VMX는 Linux kernel v4.20부터 기본으로 활성화됩니다. 그보다 오래된 kernel에서는 `kvm-intel` module에 `nested=1` option을 주어 활성화할 수 있습니다.

Userspace QEMU 자체를 수정할 필요는 없습니다. 다만 QEMU의 기본 emulated CPU type인 `qemu64`는 `VMX` CPU feature를 노출하지 않으므로 VMX feature를 command line에서 명시적으로 켜야 합니다.

`-cpu host`는 실제 CPU의 모든 feature를 emulated CPU에 노출합니다. `-cpu qemu64,+vmx`는 이름 있는 `qemu64` CPU model에 `vmx` feature만 추가합니다. 배포 및 migration 요구에 맞춰 둘 중 하나를 선택합니다.

Kernel module의 nested 지원과 guest CPUID의 VMX 노출은 별도 조건입니다. Host에서 nested 기능이 켜져 있어도 QEMU가 VMX feature를 L1에 보여 주지 않으면 L1 hypervisor는 VMX를 탐지하지 못하고 L2를 만들 수 없습니다.

Nested VMX 활성화

대상설정의미

Linux v4.20 이상기본 활성화별도 module option 불필요

이전 Linux kernel`kvm-intel nested=1`Nested VMX 명시적 활성화

QEMU host CPU`-cpu host`실제 CPU feature 전체 노출

QEMU named CPU`-cpu qemu64,+vmx``vmx` feature만 추가

Kernel과 QEMU 쪽의 조건입니다.

L1 시작 전 확인

Host Intel CPU와 KVM VMX 지원 확인필요한 kernel에서 nested=1 설정QEMU CPU model에 vmx feature 노출L1 hypervisor를 부팅하고 L2 생성

Kernel 기능과 guest CPU 노출을 함께 맞춥니다.


Running nested VMX
------------------

The nested VMX feature is enabled by default since Linux kernel v4.20. For
older Linux kernel, it can be enabled by giving the "nested=1" option to the
kvm-intel module.


No modifications are required to user space (qemu). However, qemu's default
emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be
explicitly enabled, by giving qemu one of the following options:

     - cpu host              (emulated CPU has all features of the real CPU)

     - cpu qemu64,+vmx       (add just the vmx feature to a named CPU type)

VMX ABI와 세 VMCS

54-76

Nested VMX의 목표는 L1 guest hypervisor에 표준적이고 궁극적으로 완전한 VMX 구현을 제공하는 것입니다. 공식 ABI specification은 `Intel 64 and IA-32 Architectures Software Developer's Manual` volume 3B의 VMX specification입니다.

현재 모든 VMX feature가 완전히 지원되는 것은 아닙니다. KVM을 비롯한 널리 쓰이는 hypervisor가 실제로 사용하는 VMX feature부터 지원 범위를 넓혀 최종적으로 전체 기능을 제공하는 것이 목표입니다.

Nested VMX는 L1에 VMCS 구조체를 제공합니다. Intel specification에 따라 `revision_id`와 `abort` 두 필드를 제외한 내부 layout은 사용자에게 opaque이며 L1은 내부 offset을 직접 해석하지 않고 `VMREAD`와 `VMWRITE` instruction으로 접근해야 합니다.

KVM 개발자가 debugging할 때 보는 실제 내부 표현은 원문이 가리키는 `arch/x86/kvm/vmx.c`의 `struct vmcs12`입니다. 이 layout은 구현 세부 사항이면서도 KVM version 사이 live migration에 영향을 주는 호환성 자료입니다.

`vmcs12`는 L1이 L2를 위해 만드는 VMCS, `vmcs01`은 L0가 L1을 위해 만든 VMCS, `vmcs02`는 L0가 실제로 L2를 실행하려고 합성하는 VMCS입니다.

L1이 보는 ABI는 VMREAD와 VMWRITE로 접근하는 architectural VMCS field이고, `struct vmcs12`의 C memory layout은 KVM이 이 상태를 보관하고 migration하는 구현 ABI입니다. 두 층을 구분해야 L1 호환성과 KVM version 간 상태 호환성을 각각 올바르게 검토할 수 있습니다.

VMCS 이름 규칙

이름작성 계층대상 / 용도

`vmcs01`L0L1 실행

`vmcs12`L1L2의 논리 VMCS

`vmcs02`L0Hardware에서 L2 실제 실행

이름의 두 숫자는 제어 주체와 실행 대상을 나타냅니다.

L2 실행용 VMCS 구성

L0가 vmcs01로 L1 실행L1이 VMREAD/VMWRITE로 vmcs12 구성L1이 L2 진입 요청L0가 vmcs01과 vmcs12 조건으로 vmcs02 합성Hardware VMX가 vmcs02로 L2 실행

L0가 L1의 의도를 hardware 상태로 합성합니다.

ABIs
----

Nested VMX aims to present a standard and (eventually) fully-functional VMX
implementation for the a guest hypervisor to use. As such, the official
specification of the ABI that it provides is Intel's VMX specification,
namely volume 3B of their "Intel 64 and IA-32 Architectures Software
Developer's Manual". Not all of VMX's features are currently fully supported,
but the goal is to eventually support them all, starting with the VMX features
which are used in practice by popular hypervisors (KVM and others).

As a VMX implementation, nested VMX presents a VMCS structure to L1.
As mandated by the spec, other than the two fields revision_id and abort,
this structure is *opaque* to its user, who is not supposed to know or care
about its internal structure. Rather, the structure is accessed through the
VMREAD and VMWRITE instructions.
Still, for debugging purposes, KVM developers might be interested to know the
internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c.

The name "vmcs12" refers to the VMCS that L1 builds for L2. In the code we
also have "vmcs01", the VMCS that L0 built for L1, and "vmcs02" is the VMCS
which L0 builds to actually run L2 - how this is done is explained in the
aforementioned paper.

VMCS12 revision과 header

77-93

원문은 편의를 위해 `struct vmcs12` 전체를 싣습니다. 이 구조체 내부가 바뀌면 서로 다른 KVM version 사이 live migration이 깨질 수 있으므로 layout 변경은 ABI 변경으로 다뤄야 합니다.

`struct vmcs12` 또는 내부 `struct shadow_vmcs`가 변경되면 `vmx.c`의 `VMCS12_REVISION`도 바꿔야 합니다. Revision 값은 저장된 VMCS12 상태를 새 구현이 호환 가능한지 판별하는 기준입니다.

Intel specification이 요구하는 대로 VMCS region은 사용자에게 보이는 `revision_id`와 `abort`로 시작합니다. `launch_state`는 `VMCLEAR`가 0으로, `VMLAUNCH`가 1로 설정하고 `padding[7]`은 미래 확장 공간입니다.

VMCS12 header

필드형식의미

`revision_id``u32`VMCS revision 식별

`abort``u32`VMCS abort indicator

`launch_state``u32`VMCLEAR=0, VMLAUNCH=1

`padding[7]``u32[7]`미래 확장 공간

사용자 노출 header와 KVM launch 상태입니다.

Layout 변경 시 호환성 처리

struct vmcs12 또는 shadow_vmcs 변경새 layout과 migration 영향 검토VMCS12_REVISION 갱신저장·복원 경로에서 revision 검증

Migration ABI가 오래된 상태를 잘못 해석하지 않게 합니다.


For convenience, we repeat the content of struct vmcs12 here. If the internals
of this structure changes, this can break live migration across KVM versions.
VMCS12_REVISION (from vmx.c) should be changed if struct vmcs12 or its inner
struct shadow_vmcs is ever changed.

::

	typedef u64 natural_width;
	struct __packed vmcs12 {
		/* According to the Intel spec, a VMCS region must start with
		 * these two user-visible fields */
		u32 revision_id;
		u32 abort;

		u32 launch_state; /* set to 0 by VMCLEAR, to 1 by VMLAUNCH */
		u32 padding[7]; /* room for future expansion */

VMCS12 64-bit field

94-116

첫 번째 큰 필드군은 I/O·MSR bitmap 주소, VM-exit와 VM-entry MSR list 주소, TSC offset, virtual APIC와 APIC-access page, EPT pointer 같은 64-bit VMX 상태를 담습니다.

`guest_physical_address`와 `vmcs_link_pointer`는 guest memory 및 linked VMCS 상태를 기록하고, guest·host의 IA32 PAT와 EFER, guest debug control 및 네 개 PDPTR도 이 영역에 포함됩니다.

`padding64[8]`은 미래 확장을 위한 자리입니다. 필드를 추가하거나 재배치할 때는 단순 C 내부 변경이 아니라 VMCS12 migration layout 변경이라는 점을 고려해야 합니다.

이 주소들은 L1이 생각하는 L2 제어 자료를 표현하므로 L0는 이를 그대로 hardware physical address로 사용할 수 없습니다. KVM은 guest memory 접근 가능성과 control 유효성을 검사하고 필요한 host 쪽 backing 및 translation으로 연결합니다.

64-bit VMCS12 필드군

분류대표 필드역할

Interception`io_bitmap_a`, `io_bitmap_b`, `msr_bitmap`I/O와 MSR 접근 bitmap

MSR transition`vm_exit_msr_*`, `vm_entry_msr_load_addr`VM exit/entry MSR list

Time`tsc_offset`L2 TSC virtualization

APIC`virtual_apic_page_addr`, `apic_access_addr`Virtual APIC backing

Paging`ept_pointer`, `guest_physical_address`EPT와 exit GPA

Guest state`guest_ia32_debugctl`, `guest_ia32_pat`, `guest_ia32_efer`Guest IA32 MSR 상태

PAE paging`guest_pdptr0-3`네 PDPTR

Host state`host_ia32_pat`, `host_ia32_efer`L1 host 복귀 상태

관련 기능별로 원문 선언을 묶었습니다.


		u64 io_bitmap_a;
		u64 io_bitmap_b;
		u64 msr_bitmap;
		u64 vm_exit_msr_store_addr;
		u64 vm_exit_msr_load_addr;
		u64 vm_entry_msr_load_addr;
		u64 tsc_offset;
		u64 virtual_apic_page_addr;
		u64 apic_access_addr;
		u64 ept_pointer;
		u64 guest_physical_address;
		u64 vmcs_link_pointer;
		u64 guest_ia32_debugctl;
		u64 guest_ia32_pat;
		u64 guest_ia32_efer;
		u64 guest_pdptr0;
		u64 guest_pdptr1;
		u64 guest_pdptr2;
		u64 guest_pdptr3;
		u64 host_ia32_pat;
		u64 host_ia32_efer;
		u64 padding64[8]; /* room for future expansion */

VMCS12 natural-width field

117-156

`natural_width` 필드군은 CR0·CR4 guest/host mask와 read shadow, VM exit qualification, guest linear address, guest control register와 segment·descriptor-table base를 보관합니다.

`dead_space[4]`는 제거된 `cr3_target_value[0-3]`의 마지막 흔적이며 새 의미를 부여하는 일반 padding이 아닙니다. 기존 layout을 유지하기 위한 호환성 공간으로 남아 있습니다.

Guest 실행 상태에는 DR7, RSP, RIP, RFLAGS, pending debug exception과 SYSENTER ESP/EIP가 포함됩니다. Host 복귀 상태에는 CR0·CR3·CR4, FS·GS·TR·GDTR·IDTR base, SYSENTER ESP/EIP, RSP와 RIP가 포함됩니다.

마지막 `paddingl[8]`도 미래 확장 공간입니다. Natural-width는 VMX field의 architectural width를 반영하므로 migration serialization에서 host C ABI에 맡기지 말고 정의된 VMCS12 layout을 유지해야 합니다.

Guest field는 L2가 실행될 때의 processor state이고 host field는 nested VM exit 뒤 L1로 돌아갈 때 복원할 state입니다. L0 자신의 host state와 L1이 VMCS12에 적은 host state는 서로 다른 계층의 자료이므로 vmcs02를 만들 때 구분해 합성합니다.

Natural-width 필드군

분류대표 필드역할

CR mask`cr0_guest_host_mask`, `cr4_guest_host_mask`L1이 소유하는 CR bit 구분

CR shadow`cr0_read_shadow`, `cr4_read_shadow`L2가 읽는 CR 값

Legacy slot`dead_space[4]`이전 CR3 target field 자리 보존

Exit data`exit_qualification`, `guest_linear_address`VM exit 원인 보조 정보

Guest control`guest_cr0`, `guest_cr3`, `guest_cr4`L2 control register

Guest bases`guest_*_base`Segment와 descriptor-table base

Guest execution`guest_rsp`, `guest_rip`, `guest_rflags`L2 실행 위치와 flags

Host control`host_cr0`, `host_cr3`, `host_cr4`L2 exit 후 L1 상태

Host execution`host_rsp`, `host_rip`L1 복귀 위치

Mask, guest state와 host state를 구분합니다.

		natural_width cr0_guest_host_mask;
		natural_width cr4_guest_host_mask;
		natural_width cr0_read_shadow;
		natural_width cr4_read_shadow;
		natural_width dead_space[4]; /* Last remnants of cr3_target_value[0-3]. */
		natural_width exit_qualification;
		natural_width guest_linear_address;
		natural_width guest_cr0;
		natural_width guest_cr3;
		natural_width guest_cr4;
		natural_width guest_es_base;
		natural_width guest_cs_base;
		natural_width guest_ss_base;
		natural_width guest_ds_base;
		natural_width guest_fs_base;
		natural_width guest_gs_base;
		natural_width guest_ldtr_base;
		natural_width guest_tr_base;
		natural_width guest_gdtr_base;
		natural_width guest_idtr_base;
		natural_width guest_dr7;
		natural_width guest_rsp;
		natural_width guest_rip;
		natural_width guest_rflags;
		natural_width guest_pending_dbg_exceptions;
		natural_width guest_sysenter_esp;
		natural_width guest_sysenter_eip;
		natural_width host_cr0;
		natural_width host_cr3;
		natural_width host_cr4;
		natural_width host_fs_base;
		natural_width host_gs_base;
		natural_width host_tr_base;
		natural_width host_gdtr_base;
		natural_width host_idtr_base;
		natural_width host_ia32_sysenter_esp;
		natural_width host_ia32_sysenter_eip;
		natural_width host_rsp;
		natural_width host_rip;
		natural_width paddingl[8]; /* room for future expansion */

VMCS12 32-bit field

157-203

32-bit 영역 앞부분은 pin-based·primary CPU-based·secondary execution control, exception bitmap과 page-fault error-code filter, CR3 target count를 포함합니다. 이 값들은 L2 실행 중 어떤 event가 L1로 exit할지 결정합니다.

VM-exit와 VM-entry control 및 MSR list count, entry interrupt 정보와 exception error code, instruction length는 L2 진입과 퇴출 시 hardware 동작을 기술합니다.

`vm_instruction_error`, `vm_exit_reason`, interrupt와 IDT-vectoring 정보, exit instruction length와 `vmx_instruction_info`는 VMX instruction과 exit 결과를 L1에 보고합니다.

나머지 32-bit 필드는 guest segment와 descriptor-table limit, access-rights bytes, interruptibility와 activity state, guest·host SYSENTER CS를 담습니다. `padding32[8]`은 미래 확장 공간입니다.

Control field는 L1이 요청한 정책이지만 L0가 실제 hardware capability와 보안 조건을 적용해야 합니다. 반대로 result field는 L2 실행 결과를 L1이 표준 VMX software처럼 해석할 수 있도록 architectural 형식으로 되돌려 주는 통로입니다.

32-bit execution·transition control

분류대표 필드의미

Execution`pin_based_vm_exec_control`Pin 기반 실행 제어

Execution`cpu_based_vm_exec_control`Primary CPU 기반 제어

Execution`secondary_vm_exec_control`Secondary CPU 기반 제어

Exceptions`exception_bitmap`Exit할 exception 선택

Page fault`page_fault_error_code_mask/match`#PF exit filter

VM exit`vm_exit_controls`, `vm_exit_msr_*_count`Exit 동작과 MSR list 길이

VM entry`vm_entry_controls`, `vm_entry_msr_load_count`Entry 동작과 MSR load 수

Event injection`vm_entry_intr_info_field`L2 진입 시 주입 event

L2 실행과 entry/exit를 제어하는 필드입니다.

32-bit result·guest state

분류대표 필드의미

Instruction result`vm_instruction_error`VMX instruction 오류

Exit result`vm_exit_reason`, `exit_intr_info`L2 exit 원인

Vectoring`idt_vectoring_info_field`Exit 도중 event 전달 상태

Instruction`vm_exit_instruction_len`, `vmx_instruction_info`Exit instruction 정보

Limits`guest_*_limit`Segment와 GDTR/IDTR limit

Access rights`guest_*_ar_bytes`Guest segment 속성

Activity`guest_interruptibility_info`, `guest_activity_state`L2 interruptibility와 실행 상태

SYSENTER`guest_sysenter_cs`, `host_ia32_sysenter_cs`Guest와 L1 SYSENTER selector

VMX 결과와 segment 상태를 묶었습니다.

		u32 pin_based_vm_exec_control;
		u32 cpu_based_vm_exec_control;
		u32 exception_bitmap;
		u32 page_fault_error_code_mask;
		u32 page_fault_error_code_match;
		u32 cr3_target_count;
		u32 vm_exit_controls;
		u32 vm_exit_msr_store_count;
		u32 vm_exit_msr_load_count;
		u32 vm_entry_controls;
		u32 vm_entry_msr_load_count;
		u32 vm_entry_intr_info_field;
		u32 vm_entry_exception_error_code;
		u32 vm_entry_instruction_len;
		u32 tpr_threshold;
		u32 secondary_vm_exec_control;
		u32 vm_instruction_error;
		u32 vm_exit_reason;
		u32 vm_exit_intr_info;
		u32 vm_exit_intr_error_code;
		u32 idt_vectoring_info_field;
		u32 idt_vectoring_error_code;
		u32 vm_exit_instruction_len;
		u32 vmx_instruction_info;
		u32 guest_es_limit;
		u32 guest_cs_limit;
		u32 guest_ss_limit;
		u32 guest_ds_limit;
		u32 guest_fs_limit;
		u32 guest_gs_limit;
		u32 guest_ldtr_limit;
		u32 guest_tr_limit;
		u32 guest_gdtr_limit;
		u32 guest_idtr_limit;
		u32 guest_es_ar_bytes;
		u32 guest_cs_ar_bytes;
		u32 guest_ss_ar_bytes;
		u32 guest_ds_ar_bytes;
		u32 guest_fs_ar_bytes;
		u32 guest_gs_ar_bytes;
		u32 guest_ldtr_ar_bytes;
		u32 guest_tr_ar_bytes;
		u32 guest_interruptibility_info;
		u32 guest_activity_state;
		u32 guest_sysenter_cs;
		u32 host_ia32_sysenter_cs;
		u32 padding32[8]; /* room for future expansion */

VMCS12 16-bit selector

204-220

마지막 16-bit 영역에는 `virtual_processor_id`와 guest의 ES·CS·SS·DS·FS·GS·LDTR·TR selector, host의 ES·CS·SS·DS·FS·GS·TR selector가 들어갑니다.

이 선언까지 포함한 구조체 전체 순서가 VMCS12 migration ABI입니다. Field 의미는 Intel VMX specification을 따르지만 KVM 내부 memory layout은 `VMREAD`/`VMWRITE` 사용자가 직접 의존해서는 안 됩니다.

16-bit VMCS12 field

분류필드대상

VPID`virtual_processor_id`L2 translation context

Guest data`guest_es/ds/fs/gs_selector`L2 data segment

Guest code/stack`guest_cs/ss_selector`L2 code와 stack

Guest system`guest_ldtr/tr_selector`L2 LDTR와 task register

Host data`host_es/ds/fs/gs_selector`L1 복귀 segment

Host code/stack`host_cs/ss_selector`L1 code와 stack

Host task`host_tr_selector`L1 task register

VPID와 guest·host selector 영역입니다.

		u16 virtual_processor_id;
		u16 guest_es_selector;
		u16 guest_cs_selector;
		u16 guest_ss_selector;
		u16 guest_ds_selector;
		u16 guest_fs_selector;
		u16 guest_gs_selector;
		u16 guest_ldtr_selector;
		u16 guest_tr_selector;
		u16 host_es_selector;
		u16 host_cs_selector;
		u16 host_ss_selector;
		u16 host_ds_selector;
		u16 host_fs_selector;
		u16 host_gs_selector;
		u16 host_tr_selector;
	};

작성자와 기여자

221-244

Nested VMX patch는 Abel Gordon, Nadav Har'El, Orit Wasserman, Ben-Ami Yassor와 Muli Ben-Yehuda가 작성했습니다.

Anthony Liguori, Mike Day, Michael Factor와 Zvi Dubitzky가 기여했으며 Avi Kivity, Gleb Natapov, Marcelo Tosatti, Kevin Tian 외 여러 사람이 중요한 review를 제공했습니다.

Nested VMX 참여

역할이름

작성Abel Gordon; Nadav Har'El; Orit Wasserman; Ben-Ami Yassor; Muli Ben-Yehuda

기여Anthony Liguori; Mike Day; Michael Factor; Zvi Dubitzky

검토Avi Kivity; Gleb Natapov; Marcelo Tosatti; Kevin Tian; others

원문에 기록된 역할별 명단입니다.



Authors
-------

These patches were written by:
    - Abel Gordon, abelg <at> il.ibm.com
    - Nadav Har'El, nyh <at> il.ibm.com
    - Orit Wasserman, oritw <at> il.ibm.com
    - Ben-Ami Yassor, benami <at> il.ibm.com
    - Muli Ben-Yehuda, muli <at> il.ibm.com

With contributions by:
    - Anthony Liguori, aliguori <at> us.ibm.com
    - Mike Day, mdday <at> us.ibm.com
    - Michael Factor, factor <at> il.ibm.com
    - Zvi Dubitzky, dubi <at> il.ibm.com

And valuable reviews by:
    - Avi Kivity, avi <at> redhat.com
    - Gleb Natapov, gleb <at> redhat.com
    - Marcelo Tosatti, mtosatti <at> redhat.com
    - Kevin Tian, kevin.tian <at> intel.com
    - and others.