세 번째 프로젝트의 절반이 지났다.
짧게나마 구현하면서 알게된 것을 남겨둔다.

나중에 자세히 정리하겠지만, 가상메모리(VM)는 운영체제의 핵심 design인 protection, isolation, sharing(space)을 위해 필수적으로 사용되는 추상화이다. 모든 유저 프로세스는 (심지어 커널 코드 자체까지도) 이 가상메모리 환경의 가상주소(virtual address) 상에서 동작하며, 이에 대한 실제 물리주소로의 번역은 MMU(memory management unit)라는 하드웨어가 지원해준다. 단 MMU가 이를 위해 '페이지 테이블'을 walking하는데, 이 페이지 테이블을 구성하는 것은 여전히 소프트웨어 즉, 커널의 몫이다. 커널은 자신의 주소공간에 프로세스별 페이지 테이블을 구성해 놓고, 각 프로세스가 실행될 때 마다 CR3 레지스터에 해당 페이지 테이블 주소를 적어줌으로써 MMU가 그 페이지 테이블을 walking할 수 있도록 해준다. walking 한다는 의미는 페이지 테이블의 엔트리들을 타고타고 들어가서 최하단 페이지 테이블의 PTE(Page Table Entry)를 찾아 물리주소를 알아낸다는 것이다. 주의할 점은 페이지 테이블의 엔트리에는 '물리주소'가 적혀야 한다는 점이다. 하드웨어인 MMU는 가상주소라는 개념을 이해하지 못한다. 단지 그 PTE에 적힌 어떤 값(물리주소)를 참고해서 자신의 임무를 수행할 뿐이다. 잘 생각해보면 페이지 테이블 자체가 가상주소 지원을 위한 것인데, 그곳에 가상주소를 적는다는 것이 사실 어불성설이다.

32bit 컴퓨터를 위해서는 페이지 테이블이 딱 2단계만 있으면 충분했다. 각 페이지 테이블의 크기 자체도 페이지 하나의 크기를 가져야 하는데, 주소값 자료의 크기 (즉, 포인터의 크기) 가 4 Byte ( $2^2$ ) 인 32 bit 컴퓨터에서 하나의 페이지 테이블에 들어갈 수 있는 엔트리의 개수는 1024개 ( $2^{10}$ ) 이다. ( $2^{2} * 2^{10} = 2^{12}$ 즉, 페이지 하나의 크기인 4 KiB가 된다.)
상위 페이지 테이블인 Page-Directory는 1024개의 엔트리를 가질 수 있고, 각 엔트리는 하위 페이지 테이블의 시작주소를 담고 있을 것이다. 하위 페이지 테이블인 Page-Table 또한 1024개의 PTE를 가질 수 있다. 그렇다면 총 가능한 PTE의 개수가 $2^{20}$개가 되고, 이 PTE에 해당하는 페이지 안에서의 오프셋 또한 페이지의 바이트 크기(4 KiB = 4096 Byte = $2^{12}$) 만큼 가능하기 때문에 결국 가능한 주소의 개수는 $2^{20} * 2^{12} = 2^{32}$개가 된다.

하지만 64bit 컴퓨터의 등장으로 페이지 테이블 개수가 증가할 수 밖에 없었다. 이 중 48bit만 사용한다고 해도 페이지 테이블이 4단계의 구성을 지녀야 한다. 이유는, bit의 개수 자체도 늘었을 뿐만 아니라 64bit에서는 주소값 자료의 크기가 8 Byte 이므로 페이지 테이블 당 엔트리 개수가 512개 ( $2^{9}$ )로 줄어들기 때문이다. 결국 4단계의 페이지 테이블 구성을 통해 총 가능한 PTE의 개수가 $2^{9} * 2^{9} * 2^{9} * 2^{9} = 2^{36}$ 개가 되고, 페이지 오프셋 개수 $2^{12}$ 를 곱해주면 가능한 주소의 개수는 정확히 $2^{36} * 2^{12} = 2^{48}$ 개가 된다.
그래서 4단계의 페이지 테이블 구성을 통해 64bit 컴퓨터의 가상 주소가 동작한다. 각 단계별로 페이지 테이블 이름이 존재한다.

PML4(page-map level 4) - PDP(page-directory pointer) - PD(page-directory) - PT(page-table)

이렇게 페이지 테이블이 구성되어 있을 때, MMU는 어떻게 이 페이지 테이블을 walking 하면서 주소를 번역하는 것일까. 가상 주소 '값'에 그 해답이 있다. 사실 가상 주소는 위에서 언급한 단계별 페이지 테이블의 인덱스 정보를 가진 어떤 값이다.

따라서 MMU는 어떤 가상 주소를 가지고, 그 안에 포함된 인덱스 정보를 활용하여 walking한 후, 해당하는 PTE를 찾을 수 있다. 자세한 예시는 pintos의 구현을 살펴보면서 정리해보려고 한다.

LOADER_KERN_BASE

pintos 에서 가상 주소공간은 2가지로 나뉜다 : 커널 가상 주소 (kernel virtual address) 와 유저 가상 주소 (user virtual address). 그 둘 사이의 구분은 LOADER_KERN_BASE 라는 매크로를 통해 정의하는 데 그 값은 0x8004000000 이다. 즉, 커널 가상 주소는 LOADER_KERN_BASE 값보다 같거나 큰 주소를 의미하게 된다.

앞서 말했듯이 가상 주소는 단계별 페이지 테이블의 인덱스 정보를 담고 있다.
LOADER_KERN_BASE 또한 마찬가지이다.

그림에서 보이듯 0x8004000000 라는 가상 주소는 pml4 의 offset이 (i.e. 테이블에서의 인덱스가) 1로 설정되어 있는 주소이다. 또한 PD의 offset이 32로 설정되어 있는 주소이다. 그래서 커널 가상 주소를 이용한다는 말은 곧 MMU가 위의 offset에 해당하는 walking을 하면서 PTE를 찾게된다는 말과 같게된다. 물론 주소 값이 증가함에 따라 offset이 변할 수 있겠으나, pml4의 offset 1의 증가는 512 GiB 만큼의 메모리 증가와 동일하기 때문에(pml4의 엔트리 하나가 cover하는 메모리의 크기가 512 GiB 이다.) pml4의 offset은 변하지 않는다고 봐도 무방하다.

그렇다면 이 LOADER_KERN_BASE = 0x8004000000 보다 작은 주소에 해당하는 유저 가상 주소의 인덱스 정보는 어떨까. LOADER_KERN_BASE - 1 = 0x8003FFFFFF 에 해당하는 주소의 인덱스 정보를 살펴보자.

pml4의 offset은 여전히 1 이지만, PD의 offset이 31로 감소한 것을 알 수 있다. 물론 주소가 더 감소한다면 PD offset과 PT offset 둘다 감소하게 될 것이다. 결론은 LOADER_KERN_BASE 라는 기준점에 따라서 페이지 테이블을 walking하는 '경로' 또한 구분될 수 있다는 것이다.

base_pml4

이렇게까지 자세히 들여다 본 이유는 각 프로세스가 고유로 가지는 pml4의 생성 과정을 파악하기 위해서였다. 결론부터 먼저 말하자면, 커널은 base_pml4라는 기본 바탕이 되는 pml4를 부팅 시에 만들어 전역변수로 등록해두었다가, 각 프로세스가 자신의 pml4를 생성하고자 할 때, 빈 페이지에 base_pml4의 값을 복사해준 후 그 페이지를 프로세스의 고유 pml4로 등록해준다. (금속 활자처럼 복사를 뜬 종이를 넘겨준 후 자유롭게 쓰게하는 것이라고 이해하면 쉬울지도 모르겠다.)

base_pml4에는 커널 가상 주소에 대한 PTE들이 작성된다. 왜 이것이 페이지 테이블의 '기본 양식'이 되는것인가 하면, 커널 가상 주소에 대한 페이지 테이블 정보는 모든 프로세스가 같기 때문이다. 커널은 프로세스와 다르게 자신의 개별적인 pml4를 가질 필요가 없다. 단지 각 프로세스의 pml4에서 LOADER_KERN_BASE 이상인 주소에 해당하는 PTE가 커널 가상 주소에 맞게 작성이 되어있으면 된다. 그렇다면 왜 커널이 자신의 pml4를 기억하면서 사용하지 않고, 굳이 프로세스 별로 커널 가상 주소 정보를 복사하면서 프로세스의 pml4를 만들어 주는 것인가 의문이 생길 수 있다. 이는 뒤에서 자세히 설명하겠다.

그렇다면 가장 먼저, 커널이 base_pml4 를 만드는 과정을 살펴보자.

palloc_get_page()와 PAL_ZERO 플래그를 통해 0으로 초기화된 빈 페이지를 할당받고 그것을 base_pml4로 삼아서 페이지 테이블 작성을 시작한다. pintos는 커널 가상 주소와 물리 메모리가 (물리 메모리의 크기만큼만) 1대1로 대응되는 identical mapping 방식으로 구현되어 있기 때문에 위 코드에서 보이는 반복문을 통해 페이지 테이블을 쭉 작성하게 된다. 즉, LOADER_KERN_BASE ~ LOADER_KERN_BASE + mem_end 범위 내의 커널 가상 주소에 대한 entry가 base_pml4에 적히게 된다.pml4e_walk() 함수는 va를 인자로 받아 방금전까지 설명했던 'walking'을 진행한다. LOADER_KERN_BASE에 해당하는 pml4 offset : 1 과 PD offset : 32 에 해당하는 엔트리 '경로'를 시작으로, 증가하는 주소에 따라 offset이 증가하면서 walking을 하게 될 것이다.

이렇게 만들어진 base_pml4는, process 별 pml4를 생성하는 함수 pml4_create() 에서 활용된다.
커널 pool에서 빈 페이지 하나를 할당 받고 (페이지 테이블 자체는 커널 영역에 저장되어야 한다), 그 페이지 하나를 새로운 pml4로 삼는다. 그리고 pml4의 기본 틀 base_pml4를 그대로 그 페이지에 memcpy() (복사) 해준다. 하위 페이지 테이블인 PDP나 PD를 복사하지 않아도 되는 이유는, 최상단인 pml4의 엔트리만 거치면, base_pml4를 만들때 이미 물리적으로 존재하게 된 PDP나 PD 같은 하위 페이지 테이블에 접근할 수 있기 때문이다. 그러니 그 페이지 테이블까지 복사할 필요가 없다.

위 그림은 pml4의 생성과정에서 base_pml4 의 활용에 대한 이해를 돕기위해 만들어졌다. 실제로는 pml4의 인덱스 0과 1로 유저와 커널의 엔트리가 정확하게 나뉘지 않는다. pintos에서는 LOADER_KERN_BASE 미만의 주소는 모두 유저의 가상 주소라는 정의가 있기 때문에, 아래와 같은 offset에 해당하는 주소 이하의 엔트리에 대해 모두 유저 가상 주소라고 할 수 있을 것이다.

어쨌든 이렇게 pml4_create()를 통해 프로세스의 pml4를 만들수 있다. pml4_create()는 load()과정에서 또는 do_fork()루틴에서 호출된다.

호출된 이후 pml4의 시작주소는 그 프로세스의 PCB인 스레드 구조체의 멤버 pml4에 등록한다. 이 pml4는 pml4_create()이 반환된 이후 남은 과정을 통해, 유저가 사용할 부분에 해당하는 엔트리 정보들로 채워질 것이다. 물론 이것 또한 페이지 테이블을 구성하는 작업이기에 커널이 담당한다. 유저는 페이지 테이블에 절대 접근할 수 없다는 점을 명심해야 한다.

그리고 프로세스별로 pml4를 생성했으니, 특정 프로세스가 실행될 때는 그 프로세스의 pml4를 CR3 레지스터에 load해줘야 할 것이다. 이것을 위한 함수가 pml4_activate()이다. (process_activate() 함수 내에서 호출 된다.)

load()과정에서 또는 do_fork()루틴에서 pml4_create() 이후 바로 process_activate()를 통해 해당 pml4를 사용하는 것을 알 수 있다. 그리고 특정 프로세스가 실행되는 경우가 한 가지 더 있다. 스케줄링에 의해 실행 프로세스가 바뀔 때이다. 그래서 schedule() 함수를 살펴보면 process_activate(next) 호출을 통해 다음으로 실행될 프로세스 next가 가진 pml4를 activate 해준다는 것을 알 수 있다.

이제 남은건 앞서 남겨둔 하나의 의문이다.

비록 최상위 페이지 테이블인 pml4만 복사하긴 하지만,
왜 굳이 프로세스 별로 커널 가상 주소 정보를 복사하는 것인가.

시스템 콜(system call) 때문이다. 지체없이 write() 시스템 콜을 살펴보자.

커널은 write() 라는 유저의 요청에 대하여, 유저 buffer의 내용을 fd에 해당하는 open file에 'write' 함으로써 요청을 처리한다. 여기서 유저 buffer의 내용을 읽기 위해서는 buffer 주소를 알아야 할 것이다. 그런데 유저가 넘겨주는 buffer의 주소는 유저 가상 주소이다. 만약 커널모드에 진입할 때 마다 커널만이 사용할 수 있는 특별한 pml4를 사용하게 된다면 이러한 시스템 콜을 처리하는 동작이 불필요하게 복잡해질 수 있다. 따라서 각 프로세스가 소유한 pml4마다 커널 가상 주소에 대한 엔트리를 복사해줌으로써, 어떤 프로세스의 실행 과정에 유저 모드에서든 커널 모드에서든 같은 pml4를 사용할 수 있게 한다. 이렇게 하면 시스템 콜이 'make sense' 해진다.