Virtualization Mechanism

저번까지 다룬 CPU 가상화의 핵심은 Time Sharing이다.

Time Sharing은 여러 개의 프로세스가 CPU의 시간을 나누어 쓰는 기법을 말한다.

그렇다면 이러한 Time Sharing을 실제로 어떤 메커니즘으로 구현할 수 있을까? 지금부터는 이를 어떻게 구현했는지 살펴본다.

Time Sharing 구현 이슈는 다음과 같다.

• Performance : 가상화 구현 시 Context Switching 등의 오버헤드를 최소화해야 한다.
• Control : 운영체제가 CPU에 대한 제어권을 유지하며 프로세스를 효율적으로 동작시킬 수 있어야 한다.

Direct Execution

우선 성능 이슈를 해결하는 방법에 대해 알아본다.

프로그램을 효율적으로 실행하려면 CPU에서 프로그램을 바로 실행하는 것이 좋다. 이를 Direct Execution이라 한다.

Direct Execution의 실행 흐름

1-6 : OS가 CPU를 점유하고, 프로그램 실행을 위한 사전 작업을 수행한다.

7-8 : 프로그램의 main() 함수를 실행한다. return 명령 호출 전까지 프로그램이 CPU를 점유한다.

9-10 : 프로그램의 실행이 종료되고, OS가 다시 CPU를 점유한다.

이러한 실행 방식은 OS를 거치지 않도 CPU에서 프로그램을 바로 실행할 수 있으므로 성능이 뛰어나다. 하지만 여기에는 2가지 문제점이 존재한다.

Problem 1 : Restricted Operation

프로그램이 CPU에서 직접 실행되는 경우에도, 다음 작업들은 운영체제가 적절히 제어해 줄 필요가 있다.

1. 프로세스에 메모리 공간 등의 자원 추가 할당 요청
2. 다른 프로세스의 데이터에 대한 접근
3. 저장 공간에 대한 I/O 요청

현대 운영체제에서는 이러한 Restricted Operation 들을 OS가 중간에서 관리할 수 있도록 시스템의 실행 권한을 2가지 모드로 분리한다.

• User Mode : 사용자 어플리케이션을 실행하는 모드로, OS의 허가 없이 시스템 자원을 사용할 수 없다.
• Kernel Mode : OS가 동작하는 모드로, Disk IO 및 시스템 자원 사용에 대한 요청을 할 수 있다.

System Call

시스템 콜(System Call)

다음 작업을 수행하고 싶은 상황을 가정해 보자.

• 파일 시스템 액세스
• 프로세스 생성 및 삭제
• 프로세스 간 데이터 교환
• 메모리 추가 할당

시스템 자원에 관련된 내용이므로 User Mode에서는 수행할 수 없을 것이다. 따라서 이러한 작업을 실행해 달라고 OS에게 요청하기 위한 도구가 바로 시스템 콜(System Call)이다.

트랩 (Trap)

트랩 명령어(Trap Instruction)는 User Mode에서 Kernel Mode로 전환시켜주는 CPU 명령어이다.

User mode에서 Trap이 호출되면 현재 실행 중이던 유저 프로그램의 실행이 일시 중단되고 Kernel Mode로 전환된다.

User Mode에서 Kernel Mode로 전환해 실행할 필요가 있는 작업은 전부 Trap을 통해 이뤄진다. 시스템 콜도 OS가 처리해야 하는 작업이므로 트랩을 호출한다.

Return-from-trap instruction은 Kernel Mode에서 다시 User Mode로 되돌아가는 명령어이다.

트랩이 발생하면 트랩 테이블을 참고하여 적절한 트랩 핸들러를 실행한다.

• 트랩 테이블 : 트랩이 발생하면 OS 내의 어떤 코드를 실행해야 하는가를 기록하고 있는 자료구조
• 트랩 핸들러 : 트랩에 따라 실행되어야 하는 코드이다.

시스템 콜 번호 (System call Number)

OS 내에는 백여 가지의 시스템 콜이 존재한다. 이를 구별하기 위해 시스템 콜 넘버가 존재한다.

주의 : 시스템 콜 번호와 트랩 테이블은 서로 다른 기능이다. 모든 시스템 콜은 동일한 종류의 트랩이고, 시스템 콜에 해당하는 트랩 핸들러가 호출되면 시스템 콜 넘버를 보고 적절한 시스템 콜을 수행한다.

유저가 시스템 콜을 호출할 때는 지정된 레지스터에 시스템 콜 넘버를 넣어 호출한다.

여기까지의 내용을 반영해, 각각의 모드에서 수행 가능한 명령이 제한되어 있는 Limited Direct Execution의 실행 흐름은 다음과 같다.

사용자 프로그램은 User Mode에서 실행되며, Restricted Operation을 실행하고자 하는 경우 시스템 콜을 호출하여 프로그램의 실행을 일시 중단시키고 트랩을 발생시켜 Kernel Mode에서 요청한 작업을 수행한다.

이렇게 프로그램 실행 자체는 CPU에서 이뤄지지만, 시스템 콜을 통해 제한을 두어서 실행한다고 하여 Limited Direct Execution이라고 한다.

하드웨어 자원을 사용하고 싶으면 시스템 콜을 사용해 운영체제에 부탁하는 방식을 사용함으로써, 운영체제가 프로세스를 제어할 수 있도록 설정하였다.

Problem 2 : Switching Between Processes

여기서 두 번째 이슈였던 OS의 제어권에 관한 이슈를 해결하는 방법에 대해 알아본다.

그렇다면 프로세스 간의 Context Switching이 일어날 때 OS가 어떻게 제어권을 다시 얻을까?

OS가 한 프로세스로부터 CPU를 돌려받아 다른 프로세스에게 넘겨주어야 한다.

하지만 운영체제도 프로그램의 일종이므로, CPU를 점유하지 못하면 아무 작업도 할 수 없다.

Direct Execution 방식으로 프로그램을 실행하면, Restricted Operation의 실행을 위해 잠시 실행 권한을 받아오는 것은 가능하다. 하지만 Context Switching을 위해 OS가 CPU 점유권을 다시 받아올 수 있다는 것은 보장할 수 없다!

이를 해결하기 위한 2가지 방법이 존재한다.

• 협조적인 방법 : 프로세스가 자발적으로 시스템 콜을 통해 CPU를 반납하는 것을 기다린다.
• 비협조적인 방법 : 프로세스의 자발적 반납을 기다리지 않고 운영체제가 모든 작업을 제어한다.

협조적인 방법

프로세스가 CPU 점유권을 OS에게 반납하는 방법은 다음과 같다.

• 프로세스의 CPU 점유권을 OS에게 반납하는 yield 라는 시스템 콜을 사용한다.
• 허용되지 않은 작업을 수행한다.
  • 0으로 나눗셈을 수행한다(Divide by zero).
  • 접근이 금지된 메모리 영역에 접근을 시도한다.

초기 운영체제에서는 이런 방식을 사용하였지만, 여기에는 치명적인 단점이 있다.

의도하든 의도하지 않았든, 프로세스가 무한루프(Ininite loop)에 빠지게 되면 프로세스로부터 CPU를 다시 가져올 수 있는 방법이 사라지게 된다. 시스템을 재가동하는 것만이 유일한 해결책이 된다.

비협조적인 방법

Timer Interrupt를 이용하는 방법이다.

1. 부팅 과정 중에 OS는 일종의 타이머를 작동시킨다.
2. 이 타이머는 일정 주기로 인터럽트(interrupt)를 발생시킨다.
   • 인터럽트(interrupt)는 일종의 트랩(trap)이다.
3. 인터럽트 핸들러가 호출된다.
4. 현재 프로세스에서 CPU의 제어권을 뺏아 OS에게 돌려 준다.

그리고 OS는 다시 CPU의 제어권을 돌려 받아 방금까지 실행하고 있던 프로그램을 다시 실행시킬지, 새로운 프로그램을 실행할 지를 결정한다.

새로운 프로그램을 실행하기로 결정한 경우에 Context Switching이 일어난다.

Context Switch가 일어나는 동안 이러한 작업들이 수행된다.

1. 현재 프로세스의 상태를 나타내는 다음 레지스터 값들을 저장한다.
   • General Purpose Register에 저장된 값들
   • 프로그램 카운터 (현재 프로세스가 실행 중인 코드 위치를 가리킴)
   • 커널 스택 포인터
2. 다음에 실행할 프로세스의 커널 스택으로부터 레지스터 값들을 불러온다.
   • 주의 : 1번과 2번의 커널 스택은 서로 다른 커널 스택 (각 프로세스마다 커널 스택이 존재함)
3. 커널 스택을 다음에 수행할 프로세스의 커널 스택으로 전환한다.

이 작업들은 Assembly Code로 작성되어 매우 빠르게 수행된다.

여기까지의 내용이 반영된 Limited Direct Execution의 실행 흐름은 다음과 같다.

프로세스 A가 CPU를 OS에게 자발적으로 돌려주지 않더라도 정기적으로 Timer Interrupt가 발생하여 OS에게 CPU 제어권이 반환되며, Context Switching이 일어나 프로세스 간의 전환이 일어나는 것을 볼 수 있다.

여기서 주의할 점은, 위 실행 흐름을 자세히 보면 Kernel Mode와 Hardware에서 모두 Register 값을 저장하고 복구하는 것을 볼 수 있다. 이 두 값은 서로 다른 Register에 저장된 값을 의미한다.

• Hardware의 Register 값은 User Mode의 Register를 의미하며, Kernel Stack을 통해 저장하고 복구한다.
• OS의 Register 값은 Kernel Mode의 Register에 저장된 값을 의미한다. Process의 PCB에 저장하고 복구한다.

Concurrency Problem

추가로, 동시성 문제도 반드시 고려해야 한다. 트랩 실행 중에 다른 트랩(혹은 인터럽트)가 발생하는 경우가 문제가 될 수 있기 때문이다.

OS는 다음과 같은 방법으로 이러한 문제를 해결한다.

• 인터럽트가 처리되는 도중에는 다른 인터럽트를 무효화(Disable Interrupt)한다.
• 다양한 Locking Mechanism을 활용해 동일한 자료구조에 대한 접근을 방지한다.

Locking Mechanism에 관련된 내용은 Virtualization에 관한 내용을 모두 다룬 후, Concurrency 관련 내용을 다루며 학습하게 될 것이다.

정리

Limited Direct Execution을 활용해 Time Sharing을 구현하는 방법에 대해 살펴보았다. 크게 2가지 방법을 사용하여 구현하였다.

• 성능을 고려하여, User Mode와 Kernel Mode를 분리하여 Direct Execution을 한다.
  • Restricted Operation은 System Call을 사용하여 Kernel Mode에서 OS가 수행한다.
• OS의 CPU 제어권을 고려하여, 하드웨어의 Timer Interrupt 기능을 이용해 주기적으로 Trap을 발생시킨다.
  • Direct Execution을 수행하더라도 OS에게 주기적으로 CPU 사용 권한이 돌아간다.

여기까지 CPU 가상화를 위한 Virtualization Mechanism에 대해 알아보았다.

다음 시간부터는 Virtualization Policies로서, Context Switching이 일어나는 순간에 어떤 프로세스를 수행할지를 결정하는 알고리즘인 Scheduling Algorithm에 대해 알아본다.