Mechanism: LDE(Limited Direct Execution)
- Purpose
CPU를 가상화하기 위해 OS는 물리적인 CPU를 이용해 여러 프로세스를 동시에 실행해야 한다.
기본 아이디어는 간단하다. 한 프로세스를 잠시 실행하고, 다른 프로세스를 다시 실행하는 것을 반복하는 time sharing을 이용하는 것이다.
이때 performance(추가적인 overhead를 줄이면서 virtualize)와 control(OS가 process를 어떻게 control 할 것인가)을 고려해야 한다.
- LDE(Limited Direct Execution)
프로그램을 초대한 빠르게 실행하기 위한 방법 중 하나가 LDE이다.
direct execution은 프로그램을 CPU 위에 직접 실행하는 것을 의미한다.
위 Timeline처럼 단순해 보이지만 몇 가지 문제가 있다.
Problem #1: Restricted Operations
Direct execution은 빨라서 좋다. 하지만 I/O request가 발생한다면 어떻게 될까?
아무 프로세스나 I/O control을 하면서 H/W에 접근하면 protection을 보장할 수 없게 된다.
- user mode & kernel mode
프로세스는 보안을 위해 user mode와 kernel mode로 구분된다.
kernel mode에서는 hardware resources를 완전히 사용할 수 있고, user mode에서는 불가능하다.
user mode에서 trap이라는 instruction을 이용해 kernel mode로 들어갈 수 있으며, 사용이 다 끝나면 return-from-trap(IRET instruction 등)으로 다시 user mode로 돌아온다. (디버깅에 사용하는 int instruction이 trap의 일종)
user mode에서 system call을 호출해 kernel mode의 권한으로 명령을 수행할 수 있다.
system call을 실행하기 위해서, 프로그램은 trap instruction을 실행해야 한다. 그러면 커널에 들어가 kernel mode로 권한 상승을 한다.
- kernel stack
x86을 예로 들면 kernel mode로 들어갈 때 여러 date를 저장하기 위해 프로세스마다 kernel stack이 존재한다.
trap이 발생하면 PC, flag 그리고 다른 register를 kernel stack에 올린다. 그리고 다시 user mode로 돌아올 때 kernel stack에서 data를 다시 가져온다.
- trap table & trap handle
당연히 trap table의 접근은 privileged operation이다. 따라서 user mode에서 trap table로 바로 접근할 수 없다.
커널은 부팅 시 trap table을 초기화하고, CPU는 그 주소를 기억한다. OS는 user의 trap을 다룰 수 있도록 trap handler를 가지고 있다.
위 과정을 나타내는 그림이다.
trap으로 syscall을 호출하면 register를 kernel stack에 저장하고 trap handler로 jump 한다. 이후 syscall이 끝나면 return-from-trap으로 kernel stack에서 register를 가져오고 user mode로 돌아간다.
Problem #2: Switching Between Processes
프로세스를 스위칭하는 경우를 고려해보자.
- A Cooperative Approach
process가 협력적인 행동만 한다고 가정하는 접근법이다.
프로세스가 실행하다가 trap을 사용하는 경우(알아서 넘겨주거나 zero division trap) control을 가져와 다른 프로세스로 스위칭한다.
하지만 프로세스가 trap을 한 번도 실행하지 않고 무한히 loop을 돌면 control을 어떻게 다시 돌려놓을 수 있을까?
- A Non-Cooperative Approach: The OS Takes Control
OS가 프로세스들을 믿지 않고 강제로 control을 가져올 수 있도록 하는 접근법이다.
보통은 timer interrupt를 이용한다. 프로세스가 돌다가 timer이 일정 주기로 interrupt를 발생시킨다. 그러면 OS가 interrupt handler를 위해 control을 가져올 수 있다.
- Context Switching
Timer interrupt를 이용해 프로세스 A에서 프로세스 B로 context가 스위치 되는 과정이다.
부팅 시 CPU가 syscall handler와 timer handler의 주소를 기억해둔다. 이후 OS가 timer를 실행한다.
프로세스 A가 실행 중에 timer interrupt가 발생했다고 가정하자. 그럼 A의 register들을 A의 kernel stack에 저장한다. 이후 A는 kenrel mode가 되고, trap handler로 점프한다.
(여기서 레지스터를 저장하는 것은 H/W 스위치다.)
trap을 handle 하는 OS가 어떤 policy에 의해 A에서 B로 switch() 하기로 결정했다고 가정하자. 그럼 A의 register를 A의 프로세스 구조체(PCB 등을 포함)에 저장한다. 이후 B의 proc-struct에서 register를 가져와 return-from-trap을 실행한다.
(여기서 수행한 switch()는 S/W적인 동작이다.)
return-from-trap을 실행하면 H/W는 B의 kernel stack에서 register들을 가져오고, user mode로 들어간다.
이후 B의 Program counter가 가리키는 곳으로 jump 하고, 프로세스 B가 동작한다.
trap/return from trap: CPU <--> 커널스택
switch(): CPU <--> PCB.context- assebmly
스택 상태: [ old.RET(esp) | old(esp+4) | new(esp+8) ]
// old 저장
line 8: old(esp+4)를 eax가 가리키는 주소에 저장(old의 PCB 내부의 context)
line 9: RET(esp)를 pop 해서 eax에 넣음(eax가 가리키는 곳에 RET가 저장)
이후 eax 밑에 나머지 register들 저장(context)
스택 상태: [ old(esp) | new(esp+4) ] (RET는 line 9에서 pop)
// new 가져오기
line 19: eax가 new(esp+4)의 context를 가리키게함(eax에 저장)
이후 eax 근처에 저장한 나머지 register의 값들을 복구(new의 context 가져옴)
line 27: new의 RET 가져옴
스택 상태: [ new.RET(esp) | old(esp+4) | new(esp+8) ] (RET는 line 27에서 push)메모
엄밀한 구분은 필요 없어 보이지만 예전에 궁금해서 찾아보았다.
trap의 원인: exception과 interrupt
- exception
internal interrupt예) zero division, page fault
(CPU+Memory 내부가 internal, HDD부터 외부는 external)
- interrupt
external interrupt(H/W가 처리)
Uploaded by Notion2Tistory v1.1.0