Arm Linux Kernel Hacks

먼저 이번 절에서 분석할 XEN 하이퍼바이저에서 구현된 익셉션 핸들러의 전체 코드를 소개합니다. 

01  0x26a800 <hyp_traps_vector>:
02  0x26a800:    b    0x269800 <hyp_sync_invalid>
03  0x26a804:    nop
04  0x26a808:    nop
...
05  0x26a880:    b    0x26986c <hyp_irq_invalid>
06  0x26a884:    nop
07  0x26a888:    nop
...
08  0x26a900:    b    0x2698d8 <hyp_fiq_invalid>
09  0x26a904:    nop
10  0x26a908:    nop
...
11  0x26a980:    b    0x269944 <hyp_error_invalid>
12  0x26a984:    nop
13  0x26a988:    nop
...
14  0x26aa00:    b    0x269a1c <hyp_sync>
15  0x26aa04:    nop
16  0x26aa08:    nop
...
17  0x26aa80:    b    0x269a94 <hyp_irq>
18  0x26aa84:    nop
19  0x26aa88:    nop
...
20  0x26ab00:    b    0x2698d8 <hyp_fiq_invalid>
21  0x26ab04:    nop
22  0x26ab08:    nop
...
23  0x26ab80:    b    0x2699b0 <hyp_error>
24  0x26ab84:    nop
25  0x26ab88:    nop
...
26  0x26ac00:    b    0x0x269b14 <guest_sync>
27  0x26ac04:    nop
28  0x26ac08:    nop
...
29  0x26ac80:    b    0x269c78 <guest_irq>
30  0x26ac84:    nop
31  0x26ac88:    nop
...
32  0x26ad00:    b    0x269d4c <guest_fiq_invalid>
33  0x26ad04:    nop
34  0x26ad08:    nop
...
35  0x26ad80:    b    0x269de0 <guest_error>
36  0x26ad84:    nop
37  0x26ad88:    nop
...
38  0x26ae00:    b    0x269eb4 <guest_sync_compat>
39  0x26ae04:    nop
40  0x26ae08:    nop
...
41  0x26ae80:    b    0x269f90 <guest_irq_compat>
42  0x26ae84:    nop
43  0x26ae88:    nop
...
44  0x26af00:    b    0x26a06c <guest_fiq_invalid_compat>
45  0x26af04:    nop
46  0x26af08:    nop
...
47 0x26af80:    b    0x26a104 <guest_error_compat>

익셉션 핸들러의 코드를 분석하기 전에 "'익셉션 벡터 베이스 주소 + 오프셋 주소' 규칙으로 프로그램 카운터가 분기된다"라는 사실을 염두에 둡시다. 또한 VBAR_EL2 레지스터는 익셉션 핸들러의 시작 주소를 저장한다는 사실을 기억합시다. 이번 절에서 소개한 익셉션 핸들러의 베이스 주소와 오프셋 정보는 다음과 같습니다.

 익셉션 핸들러 베이스 주소: 0x26a800(VBAR_EL2)
 익셉션별 오프셋 주소의 간격: +0x80

EL2 익셉션 핸들러의 구조 파악

이해를 돕기 위해 다음 예제 코드를 보면서 설명하겠습니다.

01  0x26a800 <hyp_traps_vector>:
02  0x26a800:    17fffc00     b    0x269800 <hyp_sync_invalid>
03  0x26a804:    d503201f     nop
04  0x26a808:    d503201f     nop
...
05  0x26a880:    17fffbfb     b    0x26986c <hyp_irq_invalid>
06  0x26a884:    d503201f     nop
07  0x26a888:    d503201f     nop

'EL2 with SP_EL0'와 같이 스택 포인터를 익셉션 레벨과 상관없이 설정하는 조건에서 유발되는 익셉션의 오프셋 정보는 다음과 같습니다.

 Synchronous 익셉션: 0x0
 IRQ 익셉션: 0x80

만약 'EL2 with SP_EL0' 조건에서 Synchronous 익셉션이 유발되면 다음과 같은 규칙에 따라 프로그램 카운터가 0x26a800 주소로 분기됩니다.

 0x26a800 = 0x26a800(VBAR_EL2) + 0x0(오프셋)

그런데 'EL2 with SP_EL0' 조건에서 'IRQ Interrupt' 익셉션이 유발되면 프로그램 카운터가 0x26a880 주소로 분기됩니다. 프로그램 카운터가 바뀌는 공식은 다음과 같습니다.

 0x26a880 = 0x26a800(익셉션 벡터 베이스 주소) + 0x80(오프셋)

이번에는 하이퍼바이저가 실행되는 EL2에서 익셉션이 유발되면 프로그램 카운터가 어떻게 분기되는지 알아보겠습니다.

14  0x26aa00:    17fffc07     b    0x269a1c <hyp_sync>
15  0x26aa04:    d503201f     nop
16  0x26aa08:    d503201f     nop
...
17  0x26aa80:    17fffc05     b    0x269a94 <hyp_irq>
18  0x26aa84:    d503201f     nop
19  0x26aa88:    d503201f     nop

EL2에서 발생하는 익셉션의 오프셋 정보는 다음과 같습니다.

 Synchronous 익셉션: 0x200
 IRQ 익셉션: 0x280

만약 EL2에서 Synchronous 익셉션이 유발되면 다음과 같은 공식에 따라 프로그램 카운터가 0x26aa00 주소로 분기됩니다.

 0x26aa00 = 0x26a800(VBAR_EL2) + 0x200(오프셋)

이와 마찬가지로 EL2에서 'IRQ Interrupt' 익셉션이 유발되면 프로그램 카운터가 0x26aa80 주소로 분기됩니다. 규칙은 다음과 같습니다.

 0x26aa80 = 0x26a800(VBAR_EL2) + 0x280(오프셋)

이처럼 XEN 하이퍼바이저의 익셉션 벡터 테이블은 Armv8 아키텍처에서 명시된 익셉션 벡터 테이블의 스펙에 따라 구현됐다는 점을 알 수 있습니다. 

XEN 하이퍼바이저 관점에서 익셉션 핸들러 구조 정리

다음은 앞에서 설명한 익셉션 핸들러 코드에서 익셉션 종류별로 분기되는 프로그램 카운터의 정보를 정리한 표입니다.

익셉션 핸들러의 코드를 제대로 이해하려면 Arm 아키텍처에서 정의된 익셉션 벡터 테이블을 먼저 숙지해야 합니다. 

익셉션 핸들러 코드 분석

XEN 하이퍼바이저의 익셉션 핸들러를 해석하는 방법과 전체 구조를 소개했으니 익셉션 핸들러 코드를 분석하겠습니다.

익셉션 핸들러의 앞부분에 있는 02 ~ 14번째 줄은 익셉션 레벨과 상관없이 같은 스택을 사용하도록 설정한 경우에 동작합니다. XEN 하이퍼바이저는 이 유형의 익셉션을 지원하지 않으므로 해당 익셉션 핸들러의 서브루틴에서는 디버깅 정보를 출력하고 크래시를 유발하는 루틴이 실행됩니다. 

EL2에서 발생한 익셉션에 대한 처리 루틴

이어서 14 ~ 25번째 줄을 분석하겠습니다.

14  0x26aa00:    17fffc07     b    0x269a1c <hyp_sync>
15  0x26aa04:    d503201f     nop
16  0x26aa08:    d503201f     nop
...
17  0x26aa80:    17fffc05     b    0x269a94 <hyp_irq>
18  0x26aa84:    d503201f     nop
19  0x26aa88:    d503201f     nop
...
20  0x26ab00:    17fffb76     b    0x2698d8 <hyp_fiq_invalid>
21  0x26ab04:    d503201f     nop
22  0x26ab08:    d503201f     nop
...
23  0x26ab80:    17fffb8c     b    0x2699b0 <hyp_error>
24  0x26ab84:    d503201f     nop
25  0x26ab88:    d503201f     nop

14 ~ 25번째 줄은 하이퍼바이저의 코드가 실행 중인 EL2에서 익셉션이 유발됐을때 처리되는 익셉션 핸들러입니다.

이번에는 익셉션 종류별로 처리되는 세부 코드를 분석하겠습니다. 먼저 14 ~ 16번째 줄을 봅시다.

14  0x26aa00:    17fffc07     b    0x269a1c <hyp_sync>
15  0x26aa04:    d503201f     nop
16  0x26aa08:    d503201f     nop

여기서 EL2의 Synchronous 익셉션은 어떻게 유발될까요? 이 질문에는 다음과 같이 답할 수 있습니다.

EL2에서 실행되는 하이퍼바이저에서 메모리 어보트를 유발하는 명령어가 실행된 경우에 Synchronous 익셉션이 유발된다.

Arm 아키텍처 관점에서 분석하면 EL2에서 Synchronous 익셉션이 유발될 때 14번째 줄에 보이는 0x26aa00 주소로 프로그램 카운터가 분기됩니다. 14번째 줄에 "b hyp_sync"라는 명령어가 있는데, 이 명령어가 실행되면 hyp_sync 레이블로 분기합니다.

hyp_sync 레이블의 서브루틴에서는 디버깅 정보를 출력하고 크래시를 유발하는 루틴이 처리됩니다. 

이어서 17 ~ 19번째 줄을 보겠습니다.

17  0x26aa80:    17fffc05     b    0x269a94 <hyp_irq>
18  0x26aa84:    d503201f     nop
19  0x26aa88:    d503201f     nop

EL2에서 실행되는 하이퍼바이저에서 'IRQ 인터럽트'가 발생하면 17번째 줄에 보이는 0x26aa80 주소로 프로그램 카운터가 분기됩니다. 17번째 줄의 코드는 hyp_irq 레이블로 분기하는 명령어입니다.

이어서 20 ~ 22번째 줄을 보겠습니다.

20  0x26ab00:    17fffb76     b    0x2698d8 <hyp_fiq_invalid>
21  0x26ab04:    d503201f     nop
22  0x26ab08:    d503201f     nop

하이퍼바이저가 구동되는 EL2에서 'FIQ 인터럽트'가 유발되면 20번째 줄에 보이는 0x26ab00 주소로 프로그램 카운터가 분기됩니다. 그런데 XEN 하이퍼바이저는 FIQ를 지원하지 않으므로 hyp_fiq_invalid라는 레이블로 분기되며, 이후 크래시를 유발하는 코드가 실행됩니다.

---
[정보] FIQ는 어디서 처리할까?
대부분의 운영체제에서 FIQ는 시큐어 월드의 Trusted 커널에서 받아서 처리하도록 시스템을 설정합니다.
---

이어서 SError 익셉션이 유발되면 실행되는 23 ~ 25번째 줄 코드를 분석하겠습니다.

23  0x26ab80:    17fffb8c     b    0x2699b0 <hyp_error>
24  0x26ab84:    d503201f     nop
25  0x26ab88:    d503201f     nop

EL2에서 SError 익셉션이 유발되면 23번째 줄에 보이는 주소로 프로그램 카운터가 바뀝니다. 'b    0x2699b0 <hyp_error>' 명령어가 실행되면 hyp_error 레이블로 분기되는데, hyp_error 레이블에서는 크래시를 유발하는 루틴이 실행됩니다. 

게스트 OS가 실행되는 EL1에서 발생한 익셉션에 대한 처리 루틴

이번에는 XEN 하이퍼바이저의 익셉션 핸들러 코드 중에서 가장 중요한 루틴인 26 ~ 28번째 줄을 보겠습니다.

26  0x26ac00:    17fffbc5     b    0x269b14 <guest_sync>
27  0x26ac04:    d503201f     nop
28  0x26ac08:    d503201f     nop

게스트 OS가 실행되는 EL1에서 HVC, WFI, WFE 명령어를 실행했을 때 26번째 줄에 있는 0x26ac00 주소로 프로그램 카운터가 분기됩니다. 이런 동작을 "게스트 Exit"라고 합니다. 소프트웨어적으로 EL1에서 EL2로 진입하는 시작점이 26번째 줄이라고 볼 수 있으며, 하이퍼바이저를 분석할 때 가장 많이 리뷰하는 루틴이 게스트 Exit로 실행되는 익셉션 핸들러입니다.

이번에는 29 ~ 31번째 줄을 봅시다. 

29  0x26ac80:    17fffbfe     b    0x269c78 <guest_irq>
30  0x26ac84:    d503201f     nop
31  0x26ac88:    d503201f     nop

게스트 OS에서 ‘IRQ Interrupt’ 익셉션이 유발될 때 실행되는 코드입니다. 29번째 줄과 같이 guest_irq라는 레이블로 분기합니다.
 
EL1에서 실행되는 게스트 OS에서 설정된 인터럽트가 발생하면 일반적으로 EL1(VBAR_EL1)에서 받아 처리합니다. 만약 HCR_EL2 레지스터의 VI와 IMO 비트가 1로 설정된 경우에만 EL2(VBAR_EL2)가 EL1에서 설정된 인터럽트를 받아 처리합니다. 

이어서 EL1에서 FIQ 인터럽트 익셉션이 유발되면 실행되는 32 ~ 34번째 줄을 보겠습니다.

32  0x26ad00:    17fffc13     b    0x269d4c <guest_fiq_invalid>
33  0x26ad04:    d503201f     nop
34  0x26ad08:    d503201f     nop

32번째 줄과 같이 guest_fiq_invalid 레이블로 분기됩니다. XEN 하이퍼바이저는 FIQ를 지원하지 않으므로 guest_fiq_invalid 레이블에서는 크래시를 유발하는 루틴이 실행됩니다.
 
게스트 Exit을 처리하는 루틴 분석 

이어서 게스트 Exit가 실행되면 호출되는 guest_sync 레이블의 코드를 분석하겠습니다.

출처: https://github.com/xen-project/xen/blob/stable-4.15/xen/arch/arm/arm64/entry.S
01 guest_sync:
02        /*
03         * Save x0, x1 in advance
04         */
05        stp     x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
06
07        /*
08         * x1 is used because x0 may contain the function identifier.
09         * This avoids to restore x0 from the stack.
10         */
11        mrs     x1, esr_el2
12        lsr     x1, x1, #HSR_EC_SHIFT           /* x1 = ESR_EL2.EC */
13        cmp     x1, #HSR_EC_HVC64
14        b.ne    guest_sync_slowpath             /* Not a HVC skip fastpath. */
15
16        mrs     x1, esr_el2
17        and     x1, x1, #0xffff                 /* Check the immediate [0:16] */
18        cbnz    x1, guest_sync_slowpath         /* should be 0 for HVC #0 */

먼저 11 ~ 12번째 줄을 보겠습니다.

11        mrs     x1, esr_el2
12        lsr     x1, x1, #HSR_EC_SHIFT           /* x1 = ESR_EL2.EC */

11번째 줄은 익셉션 클래스의 정보를 담고 있는 esr_el2(익셉션 신드롬 레지스터)의 값을 x1 레지스터에 로딩하는 동작입니다. 11번째 줄에서 esr_el2 레지스터의 값을 x1 레지스터에 로딩하는 이유는 무엇일까요? esr_el2 레지스터의 [31:26] 비트에 익셉션이 유발된 세부 원인을 나타내는 익셉션 클래스 비트 정보가 저장돼 있기 때문입니다.

12번째 줄은 x1 레지스터의 값을 #HSR_EC_SHIFT만큼 오른쪽으로 비트 시프트 연산한 결과를 x1 레지스터에 저장합니다. 여기서 HSR_EC_SHIFT는 다음 매크로 선언부와 같이 26입니다.

출처: https://github.com/xen-project/xen/blob/stable-4.15/xen/include/asm-arm/processor.h
#define HSR_EC_SHIFT                26

11번째 줄에서 esr_el2 레지스터의 값을 x1 레지스터에 로딩한 다음에 오른쪽으로 26만큼 비트 시프트(12번째 줄) 연산을 수행합니다. 그 결과, 익셉션 클래스를 나타내는 정숫값을 x1 레지스터가 저장합니다.

11 ~ 12번째 줄의 동작은 12번째 줄에 보이는 주석처럼 다음과 같이 표기할 수 있습니다.

 'x1 = ESR_EL2.EC'

ESR_EL2는 EL2에서 액세스하는 익셉션 신드롬 레지스터이고, EC는 익셉션 클래스를 나타냅니다.
 
이어서 13 ~ 14번째 줄을 보겠습니다.
 
13        cmp     x1, #HSR_EC_HVC64
14        b.ne    guest_sync_slowpath             /* Not a HVC skip fastpath. */
 
13번째 줄은 x1 레지스터가 담고 있는 익셉션 클래스가 #HSR_EC_HVC64인지 비교하는 명령어입니다. 13번째 줄 명령어의 실행 결과는 14번째 줄에 영향을 주는데, x1 레지스터의 값이 #HSR_EC_HVC64가 아니면 guest_sync_slowpath 함수로 분기합니다.

---
[정보] HSR_EC_HVC64 매크로의 정체는?

여기서 HSR_EC_HVC64 매크로의 정체는 무엇일까요? 다음 코드와 같이 0x16입니다.

출처: https://github.com/xen-project/xen/blob/stable-4.15/xen/include/asm-arm/processor.h
#define HSR_EC_HVC64                0x16

그렇다면 HSR_EC_HVC64를 0x16으로 설정한 근거는 무엇일까요? 의문을 풀기 위해서는 Armv8 아키텍처의 스펙 문서를 볼 필요가 있습니다. 다음은 익셉션 클래스와 관련된 Arm 스펙 문서의 내용입니다.

출처: Arm Architecture Reference Manual Armv8, for A-profile architecture https://developer.arm.com/documentation/ddi0487/gb 
D1.10.4 Exception classes and the ESR_ELx syndrome registers 
010110 HVC instruction execution in AArch64 state, when HVC is not disabled

위에 명시된 0b010110(이진수)은 익셉션 클래스를 나타내는 비트 정보로써 16진수로는 0x16입니다. 이처럼 Arm 스펙 문서에서 명시된 정보를 기반으로 어셈블리 명령어를 구현합니다.
---

여기까지 EL2에서 처리되는 익셉션 핸들러의 전반적인 구조를 알아봤습니다. EL2에 존재하는 익셉션 핸들러도 Arm 아키텍처에서 정의된 익셉션 벡터 테이블에 따라 구현됐다는 사실을 알 수 있습니다. 

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

이전 절에서 익셉션 벡터 테이블의 스펙을 간단히 리뷰했습니다. 이어서 EL2 관점에서 익셉션 벡터 테이블을 자세히 분석하겠습니다.

EL2 관점에서 분석한 익셉션 벡터 테이블

다음은 하이퍼바이저가 실행되는 EL2 기준에서 본 익셉션 벡터 테이블을 나타낸 표입니다.

먼저 'EL2 with SP_EL0' 행의 내용을 분석합시다. 'EL2 with SP_EL0'는 익셉션 레벨에 상관없이 스택을 설정하는 조건에서 실행되는 익셉션 종류별 오프셋을 나타냅니다. 그런데 대부분의 하이퍼바이저는 이와 같은 익셉션은 지원하지 않습니다.    

EL2에서 발생한 익셉션 분석

이어서 'EL2에서 발생'로 표시된 부분을 봅시다. 0x200, 0x280, 0x300, 0x380은 하이퍼바이저가 구동되는 EL2에서 익셉션이 발생했을 때 익셉션의 종류별로 분기되는 오프셋 주소를 나타냅니다. 

이 내용에 대해 조금 더 자세히 알아볼까요? 만약 EL2에서 실행되는 하이퍼바이저에서 Synchronous 익셉션이 유발되면 다음과 같이 익셉션 벡터 베이스 주소(VBAR_EL2)에 +0x200 오프셋을 더한 주소로 프로그램 카운터가 분기됩니다. 

 Synchronous 익셉션 벡터 주소: VBAR_EL2 + 0x200

만약 EL2에서 'IRQ 인터럽트' 익셉션이 유발되면 익셉션 벡터 베이스 주소인 VBAR_EL2에 +0x280 오프셋을 더한 주소로 프로그램 카운터가 다음과 같이 분기됩니다. 

 IRQ 인터럽트 익셉션 벡터 주소: VBAR_EL2 + 0x280

또한 EL2에서 FIQ와 SError 익셉션이 유발되면 같은 방식으로 다음과 같은 주소로 프로그램 카운터가 분기됩니다.

 FIQ 익셉션 벡터 주소: VBAR_EL2 + 0x300
 SError 익셉션 벡터 주소: VBAR_EL2 + 0x380

---
[정보] 하이퍼바이저와 FIQ의 관계

대부분의 하이퍼바이저에서는 FIQ 익셉션을 지원하지 않습니다. FIQ는 시큐어 월드에서 실행되는 트러스트 커널에서 받아 처리하도록 시스템을 구성합니다.
---

게스트 OS가 실행되는 EL1에서 발생한 익셉션 분석

이어서 'EL1에서 발생(Aarch64)'로 표시된 부분은 게스트 OS가 구동되는 EL1에서 익셉션이 유발되면 분기되는 오프셋 주소를 나타냅니다. 

EL1에서 실행되는 게스트 OS에서 HVC, WFE, WFI 명령어를 실행하면 Synchronous 익셉션이 유발됩니다. 이때 다음과 같이 익셉션 벡터 베이스 주소(VBAR_EL2)에 +0x400 오프셋을 더한 주소로 프로그램 카운터가 분기됩니다. 

 Synchronous 익셉션 벡터 주소: VBAR_EL2 + 0x400

이 같은 동작을 “게스트 Exit 혹은 하이퍼바이저로 트랩된다”라고 설명할 수 있습니다. 

또한 게스트 OS가 실행되는 EL1에서 'IRQ 인터럽트' 익셉션이 유발되면 익셉션 벡터 베이스 주소(VBAR_EL2)에 +0x480 오프셋을 더한 주소로 프로그램 카운터가 분기됩니다.

 IRQ 인터럽트 익셉션 벡터 주소: VBAR_EL2 + 0x480

일반적으로 EL1에서 설정한 IRQ 인터럽트는 EL1에 존재하는 익셉션 핸들러에서 처리합니다. 하지만 HCR_EL2.IMO를 1로 설정하면 해당 인터럽트를 EL1에 있는 익셉션 핸들러가 아닌 EL2에 존재하는 익셉션 핸들러에서 받아 처리할 수 있습니다. 물리적인 인터럽트를 EL2가 먼저 받아 이를 EL1에서 실행되는 게스트 OS에 알려야 한다면 가상 인터럽트를 생성해 게스트 OS에 통지할 수 있습니다.  

다음으로 게스트 OS가 실행되는 EL1에서 'FIQ 인터럽트' 익셉션이 유발되면 분기되는 주소를 알아봅시다. 익셉션 벡터 베이스 주소(VBAR_EL2)에 +0x500 오프셋을 더한 주소로 다음과 같이 프로그램 카운터가 분기됩니다. 

 FIQ 인터럽트 익셉션 벡터 주소: VBAR_EL2 + 0x500

이전에 설명했지만 대부분의 하이퍼바이저는 FIQ를 지원하지 않습니다. +0x500 오프셋을 적용한 주소에는 크래시를 유발하는 *_invalid와 같은 레이블이 실행되며, 서브루틴에서 크래시를 유발하는 코드가 실행됩니다.

마지막으로 게스트 OS가 실행되는 EL1에서 'SError 인터럽트' 익셉션이 유발되면 익셉션 벡터 베이스 주소인 VBAR_EL2를 기준으로 +0x580 오프셋을 더한 주소로 프로그램 카운터가 분기됩니다. 규칙은 다음과 같습니다.

 SError 익셉션 벡터 주소: VBAR_EL2 + 0x580

일반적으로 EL1에서 설정한 'SError 인터럽트'는 EL1에서 처리되나 HCR_EL2 레지스터를 설정하면 해당 'SError 인터럽트' 익셉션을 EL2에서 받아 처리할 수 있습니다.

'EL1에서 발생(Aarch32)' 행은 EL1에서 실행되는 게스트 OS가 32비트 환경에서 실행될 때 처리되는 익셉션입니다. 최근 대부분의 게스트 OS(예: 리눅스 커널)는 64비트 모드로 실행되므로 'EL1에서 발생(Aarch32)' 행에서 정의된 익셉션은 "하위 호환성을 위해 정의됐다"라는 정도로 알아둡시다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

HCR_EL2 레지스터를 구성하는 비트 필드 정보를 파악하면 "이 비트를 어떻게 설정할 수 있을까?"라는 의문이 생깁니다. Armv8 아키텍처에서는 HCR_EL2 레지스터의 값을 읽고 쓸 수 있는 MRS, MSR 명령어를 제공합니다.

HCR_EL2 레지스터는 읽는 MRS 명령어

먼저 HCR_EL2 레지스터의 값을 읽기 위해서는 다음과 같은 형식의 MRS 명령어를 실행하면 됩니다.

 

그림 15.7 HCR_EL2 레지스터를 읽는 MRS 명령어

그림 15.7은 HCR_EL2 레지스터의 값을 Xt 레지스터로 로딩하는 명령어입니다. 위 그림에서 보이는 <Xt>는 Armv8 아키텍처에서 정의된 범용 레지스터를 뜻하며, X0 ~ X30 레지스터 중 하나가 지정됩니다. MRS 명령어를 사용하면 HCR_EL2 레지스터의 어떤 비트가 활성화돼 있는지 알 수 있습니다. 

---
[중요] MRS 명령어를 해석하는 방법

MRS 명령어를 만나면 그림 15.7의 왼쪽 윗부분에 있는 화살표와 같이 명령어의 가장 오른쪽에서 왼쪽 방향으로 분석할 필요가 있습니다. MRS 명령어의 ‘S’는 시스템 컨트롤 레지스터, ‘R’은 범용 레지스터라고 이해하면 됩니다. 가장 오른쪽에 있는 ‘S’에서 바로 왼쪽에 ‘R’이 있으니 "시스템 컨트롤 레지스터의 값을 범용 레지스터에 로딩한다"라고 해석할 수 있습니다.
---

HCR_EL2 레지스터에 값을 쓰는 MRS 명령어

이어서 HCR_EL2 레지스터에 지정된 값을 쓰는 MSR 명령어를 배워 봅시다.

그림 15.8 HCR_EL2 레지스터에 값을 써주는 MSR 명령어

그림 15.8과 같이 MSR은 <Xt> 레지스터의 값을 HCR_EL2 레지스터에 쓰는 명령어입니다. 위 그림에서 보이는 <Xt>는 Armv8 아키텍처에서 정의된 범용 레지스터를 뜻하며, X0 ~ X30 레지스터가 지정될 수 있습니다. 이 명령어로 HCR_EL2 레지스터를 구성하는 세부 비트를 설정할 수 있습니다.

---
[중요] MSR 명령어를 해석하는 방법

MSR 명령어는 그림 15.8의 왼쪽 윗부분에 있는 화살표와 같이 명령어의 가장 오른쪽에서 왼쪽 방향으로 분석할 필요가 있습니다. MSR 명령어의 ‘R’을 범용 레지스터, 바로 왼쪽에 있는 ‘S’를 시스템 컨트롤 레지스터라고 이해하면 됩니다. 가장 오른쪽에 ‘R’이 있고, 왼쪽에 ‘S’가 있으니 "범용 레지스터의 값을 시스템 컨트롤 레지스터에 써준다"라고 해석할 수 있습니다.

---

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

HCR_EL2는 ‘Hypervisor Configuration Register, EL2’의 약자로서 하이퍼바이저의 세부 동작을 설정하는 가장 중요한 레지스터 중 하나입니다. HCR_EL2는 EL1에서 EL2로 진입(트랩)하는 방식을 설정하는 비트 필드로 구성돼 있습니다. HCR_EL2 레지스터의 접미사에 있는 EL2는 이 레지스터에 접근할 수 있는 최소 익셉션 레벨이므로 EL2 혹은 EL3에서만 접근할 수 있습니다.  

다음 그림은 HCR_EL2 레지스터의 비트 필드 정보입니다.

그림 15.6 HCR_EL2 레지스터의 비트 필드 

다른 레지스터와 같이 레지스터를 구성하는 비트를 1로 설정하면 해당 비트 필드와 관련된 동작이 수행됩니다. HCR_EL2 레지스터를 구성하는 비트 필드 중에 중요한 내용을 소개하겠습니다.
 
FMO, bit [3]

물리적인 FIQ 라우팅 방식을 설정하는 비트 필드입니다. 각 비트에 따라 다음과 같이 설정됩니다.

 0b0: 가상 FIQ 인터럽트를 비활성화하므로 물리적인 FIQ가 EL2로 라우팅되지 않음
 0b1: 물리적인 FIQ가 유발되면 EL2로 라우팅됨

일반적으로 FIQ는 시큐어 인터럽트로 처리되므로 EL3 모니터 혹은 시큐어 EL1에서 받아 처리합니다.
 
IMO, bit [4]

IMO는 물리적인 IRQ 라우팅 방식을 설정하는 비트 필드입니다. 각 비트에 따라 다음과 같이 설정됩니다.

 0b0: 가상 IRQ 인터럽트를 비활성화하므로 물리적인 IRQ가 EL2로 라우팅되지 않음
 0b1: 물리적인 IRQ가 유발되면 EL2로 라우팅됨. EL2나 EL1에서 인터럽트가 유발되면 EL2에 존재하는 익셉션 핸들러(VBAR_EL2)가 받아 처리

만약 SCR_EL3.IRQ 비트가 1로 설정되면 EL3에 존재하는 익셉션 핸들러(VAR_EL3)가 받아 인터럽트를 처리합니다. 만약 IMO 비트가 0으로 설정되면 EL2보다 낮은 익셉션 레벨에서 설정된 인터럽트를 EL2가 받아 처리하지 않습니다.

AMO, bit [5]

이 비트는 EL1에서 발생한 Asynchronous 익셉션을 EL2에 위치한 익셉션 핸들러가 받아 처리하기 위한 용도로 사용됩니다. AMO 비트가 1로 설정됐으면 EL2나 EL2보다 낮은 익셉션 레벨에서 Asynchronous 혹은 SError 인터럽트가 발생하면 EL2로 트랩됩니다. 

TWI, bit [13]

WFI 명령어에 대한 트랩을 설정하는 비트 필드로, 각 비트에 따라 다음과 같이 설정됩니다.

 0b0: WFI 명령어를 실행하면 EL2로 트랩되지 않고 Arm 코어가 저전력 모드로 진입
 0b1: EL0 혹은 EL1에서 WFI 명령어를 실행하면 트랩이 발생하면서 EL2로 익셉션 레벨이 변경 

TWE, bit [14]

TWI 비트와 비슷한 용도로 WFE 명령어에 대한 트랩을 설정하는 비트 필드입니다. 각 비트에 따라 다음과 같이 설정됩니다.

 0b0: WFE 명령어를 실행하면 EL2로 트랩되지 않고 Arm 코어가 저전력 모드로 진입
 0b1: EL0 혹은 EL1에서 WFE 명령어를 실행하면 트랩이 발생하면서 EL2로 익셉션 레벨이 변경 

TSC, bit [19]

SMC 명령어와 관련된 트랩 방식을 설정하는 비트 필드입니다.

 0b0: EL1에서 SMC 명령어를 실행하면 EL3에 존재하는 모니터 모드로 진입
 0b1: EL1에서 SMC 명령어를 실행하면 EL2로 트랩

여러 게스트 OS에서 SMC 명령어를 실행하면 동시다발적으로 EL3에 진입할 수 있어 누군가 이를 받아 처리해야 합니다. 이때 TSC 비트 필드를 1로 설정하면 여러 게스트 OS에서 SMC 명령어를 통해 EL2에서 실행되는 하이퍼바이저에 존재하는 익셉션 핸들러로 트랩됩니다. 이를 SMC 명령어 후킹이라고 합니다.

TVM, bit [26]

가상 메모리를 제어하기 위한 트랩을 설정하는 비트입니다. TVM 비트가 1로 설정될 경우 EL1에서 다음과 같은 메모리를 제어하는 레지스터에 어떤 값을 쓰면 EL2로 트랩됩니다. 

 SCTLR_EL1
 TTBR0_EL1
 TTBR1_EL1
 TCR_EL1
 ESR_EL1
 FAR_EL1
 AFSR0_EL1
 AFSR1_EL1
 MAIR_EL1
 AMAIR_EL1
 CONTEXTIDR_EL1

EL2로 트랩될 때 Arm 코어는 하드웨어적으로 ESR_EL2(익셉션 신드롬 레지스터)의 [31:26] 비트에 0x18 값을 씁니다.
 
TGE, bit [27]

TGE 비트 필드는 EL1에서 발생한 익셉션을 EL2로 라우팅할 때 설정합니다. 비트에 따라 다음과 같이 설정됩니다.

 0b0: EL1에서 발생한 익셉션이 EL2로 라우팅되지 않음. EL1에서 익셉션이 발생하면 EL1에 존재하는 익셉션 벡터 주소(VBAR_EL1 기준)로 프로그램 카운터가 분기
 0b1: EL1에서 발생한 익셉션이 EL2로 라우팅됨  

운영체제의 커널에서 실행되는 시스템 정보를 EL2에서 실행되는 하이퍼바이저가 후킹할 때도 사용됩니다. 

HCD, bit [29]

HCD 비트는 HVC 명령어인 하이퍼바이저 콜에 대한 마스킹(비활성화)을 설정하는 기능입니다. HCD 비트가 0으로 설정되면 HVC 명령어가 활성화됩니다. HCD 비트가 1으로 설정되면 HVC 명령어는 비활성화됩니다. 이 조건에서 HVC 명령어를 실행하면 정의되지 않은 명령어(Undefined Instruction)로 간주되어 익셉션이 유발됩니다.

이번 절에서는 HCR_EL2 시스템 레지스터를 이루는 비트 필드에 대해 알아봤습니다. HCR_EL2 시스템 레지스터를 통해 하이퍼바이저의 세부 동작을 설정할 수 있어 하이퍼바이저를 초기화할 때 HCR_EL2는 반드시 체크해야 합니다. 

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

많은 개발자들은 “HVC 명령어를 통해서만 EL1에서 EL2로 진입할 수 있다”라고 알고 있습니다. 사실 그렇지는 않습니다. WFE와 WFI 명령어를 실행해도 EL1에서 실행되는 게스트 OS에서 EL2로 진입할 수 있습니다. 

---
[정보] WFI와 WFE 명령어

WFI와 WFE 명령어는 Arm 아키텍처에서 지원하는 저전력 기능 중 하나입니다. 리눅스 커널이나 RTOS 관점에서 루틴을 분석하면 "함수가 동시다발적으로 아주 빠르게 실행된다"라고 느끼지만 이를 실행하는 Arm 코어 입장에서는 여러 함수에서 특정 루프(예: while)를 반복하면서 데이터가 특정 조건을 만족할 때까지 기다리는 동작을 자주 수행합니다.

이 상황에서 Arm 코어가 저전력 모드(스탠바이)에 진입하면 전력을 최적화해 Arm 코어를 실행할 수 있습니다. 시스템에 하나의 운영체제만 존재하는 환경에서는 WFE, WFI 명령어가 저전력 모드용으로 사용됩니다. 

가상화 관점에서는 게스트 OS에서 WFI 혹은 WFE 명령어가 실행되면 익셉션이 유발되어 EL2(하이퍼바이저 구동)로 진입한다고 볼 수 있습니다. 하이퍼바이저와 같이 시스템에 2개 이상의 운영체제가 실행되는 환경에서 HCR_EL2 레지스터의 TWE 혹은 TWI 비트를 1로 설정한 다음에 WFE, WFI 명령어를 실행하면 HVC 명령어처럼 EL2로 진입합니다.  
---

Arm 스펙 문서에서 WFE, WFI 명령어 알아보기

이어서 Arm 아키텍처 문서를 보면서 WFE, WFI 명령어에 대해 더 자세히 알아봅시다.

EL2 provides the following traps for WFE and WFI instructions:

• HCR_EL2.TWE:
1: Any attempt to execute a WFE instruction at Non-secure EL1 or EL0 is trapped to 
EL2, if the instruction would otherwise have caused the PE to enter a low-power 
state.
  0: Non-secure EL1 or EL0 execution of WFE instructions is not trapped to EL2.

• HCR_EL2.TWI
1: Any attempt to execute a WFI instruction at Non-secure EL1 or EL0 is trapped to 
EL2, if the instruction would otherwise have caused the PE to enter a low-power 
state.
  0: Non-secure EL1 or EL0 execution of WFI instructions is not trapped to EL2.

스펙 문서의 내용을 다음과 같이 해석할 수 있습니다.

 EL2는 WFE와 WFI 명령어에 대한 트랩을 지원한다. 
 HCR_EL2 레지스터의 TWE와 TWI 비트가 1로 설정된 경우 WFE 혹은 WFI 명령어를 실행하면 EL2로 트랩된다.
 만약 HCR_EL2 레지스터의 TWE와 TWI 비트가 0으로 설정됐으면 기존의 저전력 모드로 진입하는 동작을 수행한다.

이어서 HVC, WFE, WFI 명령어를 실행하면 어떤 방식으로 EL2에 진입하는지 알아봅시다. 

HVC, WFE, WFI 명령어와 Synchronization 익셉션

지금까지 설명한 내용을 정리하면 HCR_EL2.TWE와 HCR_EL2.TWE가 1인 조건에서 HVC, WFE, WFI와 같은 명령어를 실행하면 EL1에서 EL2로 진입됩니다. 이 부분까지 읽으면 다음과 같은 의문이 생길 수 있습니다.

    "HVC, WFE, WFI와 같은 명령어를 실행하면 어떻게 EL2에 진입할까?"

HVC, WFE, WFI와 같은 명령어를 실행하면 Arm 코어는 Synchronous 익셉션을 유발하며, 다음과 같은 규칙에 따라 프로그램 카운터를 업데이트합니다.

 프로그램 카운터: VBAR_EL2 + 0x400

여기서 VBAR_EL2는 EL2에 정의된 익셉션 벡터 테이블의 베이스 주소이고 0x400은 Synchronous 익셉션의 오프셋 정보입니다.

---
[정보] EL2 관점에서 해석한 익셉션 벡터 테이블

하이퍼바이저가 실행되는 EL2 관점에서 해석한 익셉션 벡터 테이블의 세부 내용은 15.4절 ‘가상화와 익셉션 벡터 테이블’을 참고하세요.
---

HVC, WFE, WFI 명령어와 익셉션 클래스

HVC, WFE, WFI 같은 명령어를 실행하면 EL2에 존재하는 같은 익셉션 핸들러에서 처리된다고 볼 수 있습니다. 그렇다면 EL1에서 HVC 명령어가 실행되어 EL2에 진입했는지 혹은 WFE/WFI와 같은 명령어를 실행해 EL2에 진입했는지 어떻게 알 수 있을까요? 

Arm 코어는 HVC, WFE 와 WFI 같은 명령어를 실행하면 Synchronous 익셉션을 유발하면서 다음 표와 같은 익셉션 클래스를 ESR_EL2의 [36:21] 비트에 업데이트합니다.

표 15.1 HVC, WFE, WFI 명령어와 익셉션 클래스

HVC, WFE, WFI 명령어를 실행하면 분기되는 같은 익셉션 핸들러에서 표 15.1에서 소개한 익셉션 클래스 비트 정보는 ESR_EL2 레지스터의 [31:26] 비트에서 읽어 HVC, WFE, WFI 명령어에 따라 다른 방식으로 처리할 수 있습니다.

이어지는 절에서 Arm 아키텍처 관점에서 하이퍼바이저의 세부 동작을 설정할 수 있는 HCR_EL2 레지스터에 대해 알아봅시다. 

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

HVC는 하이퍼바이저 콜(Hypervisor Call)이라고 하며, EL1에서 HVC 명령어를 실행하면 EL2로 진입합니다. 

Arm 스펙 문서에서 HVC 명령어 알아보기

먼저 Arm 스펙 문서에서 HVC 명령어를 설명한 부분을 소개합니다. 

출처: Arm Architecture Reference Manual Armv8, for A-profile architecture https://developer.arm.com/documentation/ddi0487/gb 
C6.2.94 HVC
Hypervisor Call causes an exception to EL2. Software executing at EL1 can use this instruction to call the hypervisor to request a service.

스펙 문서의 내용은 다음과 같이 해석할 수 있습니다.

 하이퍼바이저 콜은 EL2로 익셉션을 유발한다.
 EL1에서 실행되는 소프트웨어는 HVC 명령어를 사용해 하이퍼바이저에게 어떤 서비스를 요청한다.

EL1에서 HVC 명령어를 실행해 하이퍼바이저가 구동되는 EL2로 진입하는 동작을 하이퍼바이저 콜이라고 합니다. 여기서 HVC 명령어를 실행해 하이퍼바이저 콜을 유발하는 소프트웨어는 EL1에서 실행되는 리눅스 커널이나 RTOS 커널입니다.

EL2에서 실행되는 하이퍼바이저 위에서 구동되는 여러 게스트 OS(EL1)가 있는데, 하이퍼바이저에게 어떤 서비스를 요청하기 위해 HVC 명령어를 실행합니다. 이런 동작을 게스트 Exit라고 합니다.

---
[정보] EL1에서 EL2로 진입하는 이유는 무엇일까?

EL1에서 실행되는 다수의 게스트 OS의 리소스를 제어하고 관리하는 권한이 EL2에 있는데, EL2에서 실행되는 하이퍼바이저에게 어떤 서비스를 요청하기 위해 EL1에서 EL2로 진입합니다. 이를 위해서는 EL1에서 HVC, WFE, WFI 명령어를 실행해야 하는데, 이 과정에서 트랩이 유발됩니다. 여기서 트랩은 익셉션 관점에서 소프트웨어로 유발되는 Synchronous 익셉션으로 볼 수 있습니다. 
---

HVC 명령어의 형식

이어서 HVC 명령어의 형식을 알아봅시다.

그림 15.5 HVC 명령어의 형식

대부분 어셈블리 명령어가 실행될 때 범용 레지스터를 사용해 명령어의 입력 값이 전달되거나 실행 결과가 업데이트됩니다. 그런데 HVC 명령어의 형식을 보면 범용 레지스터는 보이지 않습니다. HVC 명령어 다음에 #imm과 같이 상수형 인자를 지정할 수 있는데 #imm의 범위는 0 ~ 65535입니다. 

HVC 명령어를 실행하기 전에 X0 ~ X7 레지스터에 아규먼트를 저장해 전달하는 방식을 HVC calling convention이라고 합니다.

HVC 명령어가 실행되기 위한 조건

그런데 HVC 명령어를 실행하면 항상 EL2로 진입할까요? 항상 그렇지는 않습니다. HVC 명령어가 실행되려면 HCR_EL2를 구성하는 비트 필드가 설정돼야 하는데, 이를 Arm 스펙 문서에서 확인할 수 있습니다. 

The HVC instruction is UNDEFINED:

 When EL3 is implemented and SCR_EL3.HCE is set to 0.
 When EL3 is not implemented and HCR_EL2.HCD is set to 1.
 When EL2 is not implemented.
 At EL1 if EL2 is not enabled in the current Security state.
 At EL0.

출처: Arm Architecture Reference Manual Armv8, for A-profile architecture https://developer.arm.com/documentation/ddi0487/gb 

위 내용은 다음과 같이 요약할 수 있습니다.

HVC 명령어는 다음과 같은 조건에서 Undefined(정의되지 않는) 명령어로 간주된다.

 EL3가 구현됐는데 SCR_EL3 레지스터의 HCE 비트가 0으로 설정된 경우
 EL3가 구현돼 있지 않고 HCR_EL2 레지스터의 HCD 비트가 1로 설정된 경우
 EL2(하이퍼바이저)가 구현되지 않은 경우
 현재 Security 상태에서 EL2가 활성화되지 않은 경우에 실행되는 EL1
 EL0 익셉션 레벨

따라서 HVC 명령어를 실행했는데 EL2로 진입하지 못하면 위에 명시된 조건을 확인합시다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

하이퍼바이저가 무엇인지 알고 나면 "하이퍼바이저를 왜 알아야 할까?"라는 의문이 생길 것입니다. 사실 하이퍼바이저는 x86 기반 CPU에서 VMware나 IBM과 같은 기업에서 20 ~ 30년전 부터 꾸준히 개발해 왔습니다. x86 CPU 기반의 데스크톱이나 서버에서 개발됐던 기술인데, Armv8 아키텍처에서 하이퍼바이저를 왜 알아야 하는지 궁금할 것입니다.

클라우드 서버에서의 하이퍼바이저 활용

이미 유닉스 기반으로 서버를 개발했던 주요 기업(예: 썬마이크로시스템즈, HP, IBM)에서는 2000년 이전부터 하이퍼바이저 기반으로 구동되는 서버를 개발했습니다. 2022년 이후 소프트웨어 업계를 이끌 기술은 AI와 빅데이터와 클라우드인데, 이 세 가지 기술들이 다양한 제품군의 생태계에 영향을 끼치고 있습니다. 그중 클라우드 분야에서 하이퍼바이저가 활발히 활용되고 있습니다.

전기자동차(인포테인먼트, 자율 주행) 분야에서의 하이퍼바이저 활용

전기자동차 업계에서도 하이퍼바이저가 많이 활용되고 있습니다. 2020년 이후 미래를 이끈 제품군으로 떠오르고 있는 전기자동차(자율 주행, 인포테인먼트)에 Armv8 기반 Arm 프로세서가 많이 사용되고 있는데, 전기자동차의 인포테인트먼트 분야에서는 Armv8 기반 프로세서 위에서 하이퍼바이저가 많이 활용됩니다.

그렇다면 하이퍼바이저는 인포테인먼트 분야에서 어떻게 활용될까요? 다음 그림과 같이 운전자 입장에서 높은 안정성이 요구되는 계기판에 보안성이 높은 RTOS를 실행하고, 내비게이션은 범용적인 안드로이드나 네이티브 리눅스를 실행할 수 있습니다.

기존의 하이퍼바이저는 인텔의 x86 CPU 위에서 실행됐으나, 전기 자동차 분야의 하이퍼바이저는 Armv8 아키텍처 기반 CPU에서 실행됩니다.

---
[정보] 전기자동차 시스템에서의 하이퍼바이저

다양한 시장조사 보고서에서 "자동차용 하이퍼바이저 시장의 저변이 확대될 것이다"라고 예측하고 있습니다.

* 출처: 세계의 자동차용 하이퍼바이저 시장 2020-2027
https://www.globalresearch.kr/report/global-automotive-hypervisor-market-size-bzw20oc140 
---

전기자동차를 개발하는 시스템 소프트웨어 개발자는 Armv8 아키텍처에서 어떤 방식으로 하이퍼바이저가 실행되는지 반드시 알아야 합니다. 

2020년 이후부터 시스템 반도체 분야에 100조 이상의 연구개발 투자를 한다는 기사를 쉽게 볼 수 있습니다. 시스템 반도체 업계를 이끄는 주요 제품군은 전기자동차(자율주행, 인포테인먼트)인데 전기자동차에 Arm 프로세서가 많이 사용되고 있습니다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

앞에서 2개 이상의 운영체제를 동시다발적으로 실행할 수 있는 플랫폼이나 아키텍처를 하이퍼바이저라고 소개했습니다. 이어서 다음 그림을 보면서 하이퍼바이저 아키텍처를 구성하는 주요 기능에 대해 알아봅시다. 

그림 15.3 하이퍼바이저 아키텍처의 전체 구조

위 그림의 가운데 윗부분에 표시된 게스트 OS 1, 게스트 OS 2는 하이퍼바이저에서 실행되는 운영체제입니다. 게스트 OS 1이 안드로이드, 게스트 OS 2는 리눅스가 될 수 있습니다. 

그런데 게스트 OS 1와 게스트 OS 2에서 실행되는 운영체제는 각각 독립적인 EL0와 EL1에서 실행됩니다. 게스트 OS 1의 커널은 EL1, 게스트 OS 1의 애플리케이션은 EL0에서 실행됩니다. 마찬가지로 게스트 OS 2의 커널은 EL1, 게스트 OS 2의 애플리케이션은 EL0에서 실행됩니다.

---
[정보] 가상 머신과 게스트 OS 

하이퍼바이저를 설명하는 다른 기술 문서에서는 가상 머신으로 표기하는데, Arm 스펙 문서에서는 주로 게스트 OS라고 표기합니다. 둘 다 같은 의미입니다.
---

이어서 그림의 아래에 ‘하이퍼바이저’라고 표시된 부분은 하이퍼바이저를 나타내며 EL2에서 실행됩니다. 하이퍼바이저는 여러 게스트 OS가 동시다발적으로 실행될 수 있도록 다음과 같은 역할을 수행합니다. 

 각각 게스트 OS를 로딩(부팅 과정)
 게스트 OS와의 통신
 게스트 OS의 리소스(가상 CPU, 가상 인터럽트) 관리

이어서 그림에서 ②로 표시된 부분을 보겠습니다. 게스트 OS의 EL1에서 실행되는 커널에서 HVC 명령어를 실행하는 것은 EL1에서 EL2로 진입하는 동작을 나타내며, 이는 ①로 표시된 "EL0에서 SVC 명령어를 실행해 EL1으로 진입하는 과정"과 유사합니다.

누군가 "게스트 OS(가상 머신)와 하이퍼바이저는 어떻게 통신할까?"라고 질문하면 다음과 같이 답할 수 있습니다.  

EL0에서 SVC 명령어를 실행하면 슈퍼바이저 콜을 통해 EL1으로 진입하듯이, EL1에서 HVC 명령어를 실행하면 하이퍼바이저 콜을 통해 하이퍼바이저가 구동되는 EL2로 진입한다.

사실 ②로 표시된 부분이 하이퍼바이저를 이해하기 위해 가장 먼저 알아야 하는 동작입니다. 

여기까지 하이퍼바이저를 구성하는 요소를 소개했습니다. 이어서 하이퍼바이저를 왜 알아야 하는지 설명하겠습니다.

---
[정보] 하이퍼바이저가 실행하는 게스트 OS의 개수

그림 15.3은 하이퍼바이저의 예시 중 하나입니다. 하이퍼바이저에는 하나의 시스템에 2개 이상의 게스트 OS가 구동될 수 있는데, 개발하려는 제품의 스펙에 따라 3 ~ 5개의 운영체제가 게스트 OS로 실행될 수 있습니다.

---

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

하이퍼바이저의 타입은 다양하나 크게 두 가지 타입으로 분류됩니다. 

 타입1: 스탠드얼론(standalone), 베어메탈(bare metal)
 타입2: 호스티드(hosted)

타입1 하이퍼바이저란?

‘타입1’ 하이퍼바이저에는 "스탠드얼론" 혹은 "배어메탈" 타입이 있습니다. 먼저 다음 그림을 보면서 ‘타입 1’ 하이퍼바이저에 대해 알아봅시다.

그림의 아랫부분을 보면 하드웨어 계층 바로 위에 하이퍼바이저가 실행됩니다. 하이퍼바이저의 윗부분에는 게스트 OS들이 있는데, 하이퍼바이저가 게스트 OS를 직접 제어하는 구조입니다. 타입1 하이퍼바이저는 하드웨어 위에서 실행되면서 게스트 OS를 직접 제어하므로 시스템의 컨트롤 타워와 같은 기능을 수행합니다. 

---
[정보] 소프트웨어 관점에서 본 하이퍼바이저

소프트웨어 관점에서 하이퍼바이저는 게스트 OS를 관리하는 RTOS로 볼 수 있습니다. 다른 RTOS와 마찬가지로 하이퍼바이저를 이루는 RTOS는 스케줄링와 메모리 매니지먼트 및 인터럽트를 제어하는 기능으로 구성되어 있습니다. 
---

타입2 하이퍼바이저란?

이번에는 다음 그림을 보면서 ‘타입2’ 하이퍼바이저에 대해 알아봅시다.

타입2 하이퍼바이저는 "호스티드"라고 불리며, 기존 운영체제에서 호스트로 실행되는 하이퍼바이저입니다. 리눅스나 윈도우 같은 기존 운영체제의 기능을 활용해 하이퍼바이저를 실행할 수 있어 많은 업체가 타입2 하이퍼바이저를 활용해 소프트웨어 스택을 구현합니다.

< '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리' 저자>

Hypervisors have been introduced and developed for decades, primarily used in server products. Recently, hypervisors are being utilized not only in data servers but also in mobile phones and the infotainment and ADAS (autonomous driving) system of electric cars.

In this section, we will introduce hypervisors and explain why it is important to learn about them.

What operating system is installed on your desktop PC? Most likely, it's Windows or macOS. So, why do we install operating systems like Windows or Linux? The answer would be, 'To use applications like Word or StarCraft that run on top of the operating system.' That's why sometimes people install both Windows and Linux on two separate desktop PCs.

What if you could run applications from both Windows and Linux on a single desktop PC? It would be much more convenient since you could run programs from both Windows and Linux on one desktop PC. This ability to use two operating systems on one desktop PC is possible because of the introduction of hypervisor technology.

To sum it up, hypervisor can be defined as follows:

     A hypervisor is an architecture or platform that allows you to run two or more operating systems        simultaneously on a desktop PC, just like using Windows and Linux.

In the following section, let's learn about the types of hypervisors.