찾아보다가 개념이 정리된 거 같아서 직접 끄적여 봤습니다ㅠ__ㅠ*

일단 들어가기 전에 먼저, 우리가 잘못 생각한게 하나 있습니다.

먼저, Full Virtualization을 수행할 때 방식이, VCPU를 생성하고 Mgtm의 Control Domain 0과 Guest OS가 통신하면서 하이퍼바이저를 거쳐 INTEL VT-x나 AMD-V같은 하드웨어에서 실제 명령을 처리하는 식입니다, 정확히 말하면 Binary Translation같은 기능들을 INTEL VT-x나 AMD-V에서 제공해준다고 보면 됩니다.

그래서 Hardware Emulation(ISA Emulation이라 보면 될라나요 :d)와 달리 Full Virtualization은 INTEL VT-x나 AMD-V가 없이는 동작할 수 없습니다. Control Domain을 만들수 없기 때문이죠 :D,

그래서 열심히 토론했었던 INTEL VT-x과 AMD-V가 없는 환경에서의 Hardware Emulation과 Full Virtualization의 속도 차이...는 아예 일어날수가 없는 상황이었습니다 -____-!

** 물론, INTEL VTx나 AMD-V가 없는 환경에서 Full Virtualization을 수행하는 방법이 없는 것은 아닙니다, 단지, Binary translation등을 직접 구현해야 하는데 차라리 Para를 하겠어요.ㅋㅋㅋ

** 물론, INTEL VTx나 AMD-V 이전의 환경에서는 Software적으로 Binary Translation을 수행함으로써 Full Virtualization을 사용했을 것입니다. 그런데 소프트웨어적으로 Binary Translation을 구현하면 속도가 좀 많이 느립니다. 그래서 차라리 Paravirtualization을 수행하는게 속도 면으론 더 좋았지요. 그러다 INTEL VTx나 AMD-V에서 Hardware적으로 Binary Translation을 지원해 주면서 속도가 향상되어서 Paravirtualization의 이점이었던 속도 문제가 이젠 이점으로 작용하지 않고 있습니다.

Hardware Emulation(좀 더 정확히 말하면 ISA Emulation)은 게임 에뮬레이트를 하는 방식과 유사합니다.

즉, if(!strcmp(instruction[0], "MOV"))

// TODO: Write here routine of Virtualized MOV

뭐 이런 식인데요, 그렇기 때문에 엄청 느립니다.... 대신 하드웨어 의존적이지 않기 때문에, 모든 기종을 가상으로 생성해 내면 모든 기종을 에뮬레이트 할 수 있습니다. 예를 들어, Bochs같은 경우 x86 머신을 아예 가상으로 만들어 버리죠.

그에 반해 Full virtualization은, VCPU를 생성하고, Mgtm단의 Control Domain (DOM 0)과 Guest OS가 통신하고, 그것이 하이퍼바이저를 거쳐서 실제 하드웨어에 도달하고 이 하드웨어는 INTEL VT-x와 AMD-V를 지원합니다. INTEL VT-x와 AMD-V에서 Binary Translation같은 기능들을 지원해 주기 때문에 하드웨어 의존적으로 실제 처리되어야 할 ISA 등은 하드웨어단에서 처리됩니다. 따라서 하드웨어 의존적인 에뮬레이팅을 하게 되고, CPU단에서 ISA가 처리되기 떄문에 엄청 빨라지는거죠 :D

물론 단점은 있습니다. 그 CPU단에서 처리되기 때문에 CPU의 종류에 따라, 즉 에뮬레이트 할 수 있는 기종이 한정되어 있다는 점입니다. 어제 알아봤던 대로 "동일 기종"만 돌릴수 있다는 것이 그 이유 때문입니다.

이왕 말 나온 김에 Paravirtualization까지 한번 달려보죠!

Para-Virtualization은 근본적으로 Full Virtualization과 구성이 다르고, 그 다른 구성에 의해 속도차이가 납니다.  Full Virtualization이 Mgtm의 Control Domain (DOM 0)과 Guest OS 상호간의 통신을 한다면, Para-Virtualization은 Bare H/W가 직접 Hypervisor과 통신을 합니다. 그리고 그 Hypervisor가 OS와 상호간 통신을 하죠. 여기서 OS가 직접 하이퍼바이저를 이용할 때 사용하는게 바로 Hyper Call입니다. Hyper Call은 일종의 시스템 콜과 비슷한 개념이라 생각하시면 됩니다(대상이 커널이 아니라 하이퍼바이저로 이동했다고 생각하시면 편합니다).

그런데 여기서 성능의 문제가 발생합니다. 모든 리소스를 하이퍼바이저가 처리하고 이런 식으로 통신하다 보면 하이퍼바이저의 덩치가 커지고 그럼 오히려 역으로 성능이 저하될 수 있습니다. 따라서 사용이 빈번한 자원들(CPU나 램)만 하이퍼바이저가 컨트롤 하는데, 이것 때문에 Guest OS의 수정이 필요합니다. 자원을 구분해서 CPU나 램 같은 것들은 하이퍼바이저로 들어가도록이요.

나머지 불필요한 자원들은 전가상화와 똑같이 Mgmt의 DOM0을 통해서 통신하게 됩니다 :D

** 추가 **

한글이 문맥이 조금 이상해서 혼동되는 부분이 있는데

Paravirtualization에서요 하이퍼바이저에게 빈번히 사용되는 CPU나 램 따위의 리소스를 넘겨주려면 Guest OS의 소스를 수정해야 하니까 Para와 Full을 구분하는 방법은 Guest OS의 수정 유무입니다 :)

혹시 궁금하신 점 있으시면 언제든지 물어봐 주세요! ㅠ__ㅠ

전 그럼 Control Domain의 역할에 대해 공부하고 여기 다시 글을 쓰도록 하겠습니다..^^

수고하세요! ^^