게스트의 시스템 호출은 어디로 갑니까?

게스트 커널 진입과 호스트 복귀를 나누어 봅니다

가상 머신에서 프로그램이 getpid를 호출하면 보통 그 가상 머신의 Linux 커널이 처리합니다. 시스템 호출마다 호스트 커널이나 QEMU가 대신 getpid를 실행하는 구조가 아닙니다. 게스트 안에서 사용자 모드와 커널 모드가 바뀌는 사건과, 게스트 실행을 멈추고 호스트가 개입하는 사건을 구분해야 합니다.

이 글은 중첩 가상화와 보호 VM을 제외하고, ARM64 Linux를 실행하는 일반 VM을 설명합니다. 예제의 SVC에는 추가 trap·debug 설정이 없으며, 신호나 추적 도구가 시스템 호출의 결과를 바꾸지 않는다고 가정합니다. 게스트가 VM을 다시 실행하는 중첩 가상화에서는 SVC를 가로채는 경로도 있습니다. v6.18.37의 KVM handle_svc도 그 경우를 처리합니다. KVM의 SVC·예외 처리

세 줄로 getpid를 요청해 봅니다

아래는 게스트의 64비트 사용자 프로그램 안에 있다고 가정한 설명용 코드입니다. 앞의 주소는 각 명령의 위치를 보이기 위한 값이며 어셈블리 문법의 일부가 아닙니다. 실제 프로그램의 배치 주소와 PID는 실행할 때 달라집니다.

0x00400000:  mov x8, #172
0x00400004:  svc #0
0x00400008:  mov x19, x0

getpid는 이 예에서 x0~x5의 인자를 요구하지 않습니다. 따라서 호출 전 x0의 값은 이 서비스의 입력으로 사용하지 않습니다. 다른 시스템 호출은 x0~x5를 인자로 사용할 수 있으므로 같은 결론을 모든 호출에 적용하면 안 됩니다. getpid의 결과는 게스트의 PID namespace에서 보이는 프로세스 ID이며, 호스트 QEMU 프로세스나 vCPU thread의 ID가 아닙니다. getpid 번호 정의 x8을 읽는 do_el0_svc getpid의 반환값

명령을 실행하면서 무엇이 바뀝니까?

v6.18.37의 entry-common.c는 SVC64를 el0_svc로 연결합니다. syscall.c는 저장된 x8로 호출을 선택하고, syscall_set_return_value는 저장된 사용자 x0를 갱신합니다. entry.S는 복귀 주소·상태와 레지스터를 복원합니다. 따라서 “예외가 생겼다”는 말만 보고 EL2 또는 QEMU로 갔다고 판단하지 않습니다. 게스트 커널의 SVC 진입 사용자 x0에 반환값 저장 예외 진입·복귀 어셈블리

호스트 커널이 EL2에 있으면 무엇이 다릅니까?

같은 EL1이라는 이름을 써도 nVHE의 호스트 커널과 게스트 커널이 같은 문맥을 공유하는 것은 아닙니다. KVM은 실행 대상을 바꿀 때 레지스터·주소 변환·예외 처리 상태를 전환합니다. 반대로 호스트가 VHE로 EL2에서 실행한다고 해서 게스트의 모든 커널 코드까지 EL2에서 실행되는 것도 아닙니다. nVHE 문맥 전환 VHE 문맥 전환

VHE에서 HCR_EL2의 E2H와 TGE는 호스트용 실행 환경과 EL0 예외 경로를 구분하는 데 관여합니다. Linux의 HCR_HOST_VHE_FLAGS에는 두 비트가 포함됩니다. 이 매크로는 빌드할 때 정해지는 비트 조합이고, 실제 상태 변화는 실행 중 그 값을 HCR_EL2에 기록할 때 일어납니다. 게스트로 들어갈 때와 호스트로 돌아올 때의 설정을 같은 것으로 읽으면 안 됩니다. HCR host·guest 값 trap 활성화·해제

예전 EL2 설명에서 “가상 주소 영역이 하나뿐”이라고 읽었다면 VHE 적용 전후를 확인해야 합니다. VHE는 호스트 커널을 EL2에서 실행하기 위해 두 영역과 ASID 지원을 추가합니다. ASID는 주소 공간을 구별하는 식별자입니다. Arm의 해당 입문 문서 8절도 이 차이를 따로 설명합니다. Arm의 VHE 설명 · 8절

EL2로 나온 뒤에도 QEMU로 돌아오지 않을 수 있습니다

QEMU의 vCPU thread가 KVM_RUN을 호출하면 호스트 커널 안에서 게스트를 실행합니다. 실행 도중 EL2 처리가 필요해져도 KVM이 해결한 뒤 같은 KVM_RUN 안에서 게스트로 다시 들어갈 수 있습니다. 따라서 guest exit 횟수와 사용자 공간으로 돌아온 횟수는 같지 않습니다.

/* v6.18.37 arm.c의 반복 조건과 handler 호출입니다.
 * 사이의 준비·진입·복원 코드는 생략했습니다. */
while (ret > 0) {
    /* ... */
    ret = handle_exit(vcpu, ret);
}

이 ret 규칙은 handle_exit와 실행 loop 사이의 내부 반환 규칙입니다. 사용자 프로그램에서 ioctl(KVM_RUN)이 1을 돌려주면 계속 실행된다는 뜻이 아닙니다. 사용자 공간은 ioctl의 성공·실패를 먼저 확인해야 합니다. 또한 kvm_io_bus_read 같은 helper의 성공값 0도 위 handler의 0과 역할이 다릅니다. 실행 loop handler 반환 규칙

같은 load라도 어느 주소 변환에서 막혔는지 봅니다

일반 RAM 읽기를 예로 들어 보겠습니다. 두 변환 모두 4 KiB 페이지를 사용하고, 권한·메모리 속성·정렬 조건이 맞으며, 필요한 페이지 표도 접근 가능하다고 가정합니다. 게스트 가상 페이지 0x00400000은 IPA 페이지 0x80000000에, 그 IPA는 호스트 물리 페이지 0x120000000에 대응한다고 정했습니다. IPA는 이 VM이 물리 주소로 취급하는 주소입니다.

게스트 페이지 테이블 자체도 메모리에 있으므로, Stage-1 표를 읽는 도중 Stage-2 fault가 생기는 경우도 있습니다. 위 그림은 최종 데이터 주소를 이해하기 위한 단순한 예입니다. “Stage-2 fault이면 Stage-1은 언제나 완전히 끝났다”는 일반 규칙으로 읽지 않습니다. v6.18.37의 kvm_handle_guest_abort도 표 탐색 중 fault인지를 별도로 검사합니다. 게스트 abort와 S1PTW 처리

memslot은 KVM에 등록한 게스트 물리 메모리 범위입니다. 일반 사용자 메모리 기반 VM에서는 그 범위와 호스트 사용자 주소 HVA를 연결합니다. HVA는 KVM이 RAM의 backing page를 찾는 데 쓰며, 게스트의 하드웨어 변환을 VA → IPA → HVA → PA라는 세 단계로 만드는 것은 아닙니다. 실제 AArch64 구현 경로도 v6.18.37에서는 arch/arm64/kvm/mmu.c입니다.

가상 장치에서 읽은 값은 언제 x2에 들어갑니까?

이번에는 게스트 커널이 가상 장치의 32비트 상태 register를 읽는다고 가정합니다. 게스트와 호스트는 little-endian이고, 단일 AArch64 LDR의 정상 MMIO 처리를 예로 듭니다. x1은 장치로 매핑된 게스트 VA이며, 대응하는 IPA는 0x09000000입니다. 이 주소는 사용자 공간의 설명용 장치 모델이 담당합니다. 실제 보드의 register 주소나 장치 기능을 지정한 것이 아닙니다.

ldr w2, [x1]

x1의 숫자를 w2에 복사하는 mov가 아닙니다. x1을 주소로 사용해 4바이트를 읽고 결과를 w2에 넣으려는 명령입니다. 완료되면 x2의 상위 32비트는 0이 됩니다. 이 예에서 접근 전 x2는 0xa5, 장치 모델이 돌려줄 값은 0x12345678이라고 정했습니다.

io_mem_abort는 먼저 커널 안의 MMIO 처리 가능 여부를 확인합니다. 성공하면 커널 안에서 결과를 완료하고 계속 실행할 수 있습니다. 사용자 공간 처리가 필요한 경우에만 KVM_EXIT_MMIO를 준비합니다. 따라서 “MMIO는 항상 QEMU가 처리한다”도 맞지 않습니다. MMIO 해석·커널 처리·사용자 공간 반환

다시 KVM_RUN을 호출하면 arm.c의 시작 부분에서 kvm_handle_mmio_return을 먼저 처리합니다. 읽기 값의 폭과 확장 규칙을 적용하고 게스트 register에 반영한 뒤 PC를 조정합니다. KVM API 문서도 MMIO 같은 요청은 재진입하여 남은 처리를 끝내야 게스트 상태가 일관된다고 설명합니다. MMIO 완료를 먼저 처리하는 위치 KVM_RUN과 MMIO 완료 규칙

관찰한 현상을 어디에 연결해야 합니까?

기존 KVM·Stage-2 글에서는 함수 연결과 매핑 코드를 이어서 읽으실 수 있습니다. 이 글의 숫자는 그 코드가 바꾸는 상태를 설명하기 위해 정한 예이며, 실제 KVM을 실행하거나 trace를 수집한 측정 결과는 아닙니다.

이어서 읽기

• 메모리 배리어에서 구분해야 할 관찰자
• DMA 주소와 buffer 소유권
• blog/kernel/arch-kvm-virtualization-6-18-lts.html
• blog/kernel/armv9-kvm-stage2.html
• ARM64 KVM vCPU와 Stage-2 fault 소스 분석
• blog/kernel/armv9-virtualization-platform.html