Xen - 메모리 가상화

Xen 메모리 가상화

1. 메모리 가상화

-Virtual Memory

2.1 가상 메모리

- 가상 메모리를 사용하는 이유는 독립 주소 공간, 요구 페이징 등

- 가상 메모리를 구현한다는 것은 결국 메모리 주소를 속이는 것...

- CPU가 내보내는 메모리 주소, 즉 운영체제나 어플리케이션이 사용하는 주소는 실제 메모리의 물리주소가 아닌 자상 주소이다. 가상 메모리를 구현하려는 CPU 제조 업체는 저마다 하드웨어 관점에서 가상 주소를 물리 주소로 변환하는 MMU(Memory Management Unit)_라는 것을 제공.

- 가상 주소와 물리 주소와의 매핑을 결정하는 것은 페이이 테이블(Page Table). 운영체제는 가상 주소와 물리 주소 사이의 매핑 정보를 페이지 테이블에 기록. 그런 다음 CPU의 페이지 테이블 베이스 레지스터가 페이지 테이블에 기록하 메모리 주소를 등록하면, MMU는 페이지 테이블을 검색해 CPU가 내보내는 가상 주소의 실제 물리 주소를 찾아내 변화하고, 변환된 주소를 통해 메모리에 접근. 

- 페이지 테이블 구조

- x86 아키텍처 32비트 모드의 기본적인 테이블 구조이고 CPU는 32비트 주소를 사용하고, 페이지 디렉터리의 시작 주소는 CR3레이지터에 저장. 32비트 메모리 주소 중 31~22비트 까지의 10비트는 페이지 디렉터리의 인덱스로 사용, 해당 인덱스가 가리키는 페이지 디렉터리의 엔트리는 페이지 테이블의 시작 주소를 나타 냄.

- 21~12비트까지는 페이지 테이블의 인덱스로 사용하고, 해당 인덱스가 가리키는 페이지 테이블의 엔트리는 실제 물리 메모리 한 페이지의 시작 주소가 된다. 10비트의 인덱스로 2^10인 1,024개의 엔트리를 나타낼 수 있고, 32비트 머신에서 엔트리 하나는 4바이트를 차지하므로 페이지 디렉터리나 페이지 테이블 하나는 각 4KB의 페이지 크기 만큼 메모리 공간을 차지하게 됨다. 마지막으로 남은 11~0비트까지의 12비트는 4KB 페이지 안의 오프셋을 나타내고, 찾고자하는 최종 물리 주소가 된다. 12비트로 나타낼 수 있는 주소 버무이는 2^12인 4KB가 되므로 4KB로 페이지 안의 모든 주소를 가리킬 수 있음.

- 복잡한 다단계 구조로 페이지 테이블을 구성한 까닭은 MMU 구현의 효율성과 페이지 테이블의 크기와 관련. 페이지 테이블을 하나로 구성한다면 1개의 페이지 크기가 4KB인 페이지 테이블은 2^32/2^12인 1,048,576개의 엔트리가 필요. 엔트리 하나의 크기는 4바이트이므로 총 4MB의 공간이 필요. 페이지 테이블은 프로세스마다 독립적으로 하나씩 존재하므로 모든 프로세스에 이렇게 4MB의 배열을 메모리에 할당하는 일은 매우 비효율적인 방식. 모든 프로세스는 4GB의 주소 공간 중 극히 일부분만ㅇ르 사용하므로 주소 공간이 필요한 부분만 페이지 테이블을 만들어 할당 하 수 잇는 다단계 방식을 취함.

2.2 가상화 환경의 메모리 주소 체계

- 비 가상화 환경에서 물리 주소와 가상 주소라는 두 단계 주소 체계를 가진다면, 가상화 환경에서는 가상주소, 물리주소,머신 주소라는 세 단계를 가짐.

- 가상 머신에서 동작하는 게스트 운영체제는 가상화 환경에서 동작한다는 사실을 모름. 가상 머신은 가상화 되지 않은 환경에서 동작할 때와 마찬가지로 가상 주소와 물리 주소를 그대로 사용. But 가상 머신이 아는 물리 주소는 실제 물리 주소가 아니며, 하이퍼바이저의 중재 아래 실제 물리 주소로 변환해서 사용해야 함.

-  ex) 가상 머신이 사용하는 물리 주소를 그대로 사용한다면 기본적으로 운영체제는 할당된 메모리가 0번지 부터 시작한다고 생각하고 동작. 그러면 모든 가상 머신은 너도나도 0번지부터 시작하는 메모리를 사용할 것이고, 모두 같은 영역의 메모리를 사용하므로 충돌이 일어나서 정상적으로 작동할 수 없음. 하이퍼바이저가 적절히 중재를 해야함.     512MB의 메모리를 가진 가상 머신 두 개를 동작시킨다고 하면 첫 번째 가상 머신에는 실제 메모리의 0~512MB영역을 할당하고, 두 번째 가상 머신에는 513~1,024MB 영역을 할당.

2.3 섀도 페이지 테이블

- 가상화 환경의 메모리 주소 체계에서는 게스트 운영체제가 생각하는 물리 주소를 실제 머신 주소로 변환해서 사용해야 하는데, 이때 일반적으로 하이퍼바이저에서는  Shadow Page Table이라는 가상의 페이지 테이블을 사용. 운영체제가 사용하는 페이지 테이블이 가상 주소에서 물리 주소로 변환하는 정보를 저장한다면, 섀도 페이지 테이블은 가상 주소에서 머신 주소로 변환하는 정보를 저장하는 테이블 페이지. 하이퍼바이저는 머신 주소 정보를 가지므로, 섀도 테이블을 구축하고 페이지 테이블 베이스 레지스터에 섀도 페이지 테이블의 시작 주소를 등록. 그러면 MMU가 참조하는 페이지 테이블은 섀도 페이지 테이블이 되고, CPU가 생성하는 가상 주소를 머신 주소로 변경해 사용.

2.4 직접 페이지 테이블 접근

- 섀도 페이지 테이블은 메모리 가상화에 아주 적합해 보이는 방법이지만 어쩔 수 없이 오버헤드를 가짐. 게스트 운영체제 모든 프로세스의 페이지 테이블을 중복해서 가지며, 항상 게스트 운영체제의 페이지 테이블과 동기화해야 하는 등 성능 저하를 발생시키는 요인이 있음.

- 반 가상화 기법을 사용하면 게스트 운영체제의 소스 코드를 수정할 수 있으므로 섀도 페이지 테이블을 사용하지 않고도 메모리 가상화를 할 수 있음. Xen에서는 게스트 운영체제를 수정해 게스트 운영체제가 직접 페이지 테이블을 올바르게 수정하도록 변경할 수 있음.

- 가상 주소와 머신 주소사이의 주소 변환은? 게스트 운영체제는 물리주소와 머신주소 사이의 매핑 정보를 가짐. 직접 페이지 테이블에 주소를 저장할 때, 물리 주소가 아닌 머신 주소를 저장. Xen의 경우에는 하이퍼 콜을 통해서 하이퍼바이저에 테이블 수정을 요청. 하이퍼바이저는 유효한 요청인지 검사한 후 요청을 수락.

- 게스트 운영체제의 페이지 테이블은 가상 주소와 물리 주소 사이의 변환 테이블이 아니라 가상 주소와 머신 주소 사이의 변환 테이블을 가짐. MMU가 직접 게스트 운영체제의 페이지 테이블을 참조해도 정상적으로 동작하는 것. 이는 직접 소스코드를 수정해야 하는 번거로움이 있지만 섀도 페이지 테이블과 같이 중복해서 페이지 테이블을 유지할 필요가 없기 때문에 성능상의 이점.

2.5 중첩 페이지 테이즐

- 중첨 페이지 페이블은 AMD가 관련 기능을 먼저 지원. AMD-Nested Page Table/인텔-Extended Page Table.

- 기존의 가상 메모리가 가상 주소에서 물리주소로 변환하는 기능을 하드웨어적으로 구현한 것이라면, 중첩 테이블은 물리 주소에서 머신 주소로 변환하는 기능을 하드웨어적으로 구현한 것.

- CPU가 내보내는 가상 조소는 게스틍 운영체제가 구축한 페이지 테이블을 통해서 물리 주소로 변경하고, 변경한 물리 주소는 다시 하이퍼바이저가 구축한 중첩 페이지 테이블을 통해서 머신 주소로 변경해 메모리에 접근. 게스트 운영체제는 페이지 테이블을 구축할 때 섀도 페이지 테이블이나 직접 접근 방식에서 발생하던 페이지 폴트 같은 부가적인 오버헤드 없이 페이지 테이블을 구축할 수 있음. 하이퍼바이저가 게스트 운영체제를 생성할 때 할당해준 메모리의 머신 주소 정보만 중첩 페이지 테이블에 적어주면 쉽게 메모리 가상화를 할 수 있음.