Mechanism : Limited Direct Execution

How to efficiently virtualize the CPU with control?

CPU 가상화를 하기 위해서는 OS가 물리적인 CPU를 이용해 여러 process를 동시에 실행해야 한다. 

어떻게 CPU 가상화를 효율적으로 할 것 인가?

>>> OS는 time sharing을 통해 물리 CPU를 공유

 

문제가 발생한다.

1. Performance : 어떻게 시스템에 과도한 overhead 없이 가상화를 구현하는가?
2. Control : 어떻게 CPU 제어를 유지하면서 process를 효율적으로 control 할 것 인가?

---

Direct Execution

프로그램을 CPU 위에 직접 실행한다. 

수행 과정

• 프로그램이 돌아가는 동안 OS가 아무것도 못하게 된다.
• 문제가 발생했을 때 개입을 못하기 때문에, 그저 library에 불과하게 된다.
  • OS도 CPU자원을 할당 받아야하는데, process가 CPU를 계속 가지고 있다. >>> OS가 개입을 하지 못함
  • process 중간에 OS가 간섭할 수 있는 장치를 마련해야 함 >>> Direct Execution으로 CPU에서 process를 바로 실행시키면 간섭없이 빠르게 작업을 처리할 수는 있음

---

Problem 1 : Restricted Operation 

만약 process가 I/O request가 발생하거나, CPU와 memory 같은 resource를 접근하려 한다면 보안과 안정성에 큰 문제가 생길 수 있음 

• solution : user mode과 kernel mode로 구분
  
  • user mode : 허용된 CPU instruction만 수행하도록 함. restricted operation 실행 불가, HW resources에 마음대로 접근할 수 없도록 제한
  • kernel mode : HW에 대한 모든 접근 권한을 가짐, restricted operation 실행 가능 
• user mode에서 restricted operation 사용 가능한가? 
  • System call을 사용하면 된다. 
  • user mode에서 지정된 Trap instruction 사용해 kerner mode로 진입하고 필요한 작업을 처리할 수 있음
  • 처리 후에는 Return-from-trap instruction으로 다시 user mode로 돌아옴

---

System Call

kernel로 하여금 user program에 주요 기능을 제공해 주는 것

(file system 접근, process 생성 및 소멸, 다른 process와의 communication, memory 할당 등)

• file system 접근
• 프로세스 생성 및 제거
• 다른 프로세스와 communication
• 더 많은 메모리 할당

Trap instruction

사용자 프로그램이 처리할 수 없는, OS가 처리해야 할 특정 이벤트가 발생 

user mode에서 kernel mode로 진입하게 된다.

• kernel로 jump
• privilege level을 kernel mode로 올림

Return-from-trap instruction

해당 system call을 하였던 user program으로 돌아오는 것

kernel mode에서 user mode가 된다. 

• user program 호출로 돌아옴
• privilege level도 user mode로 낮춤

어떻게 trap은 OS에서 어떤 code를 수행해야 할지 알 수 있을까?

여기서 trap table과 trap handler, system-call number라는 개념이 등장

모든 system call들은 각자 할당된 고유의 number가 있음

user code에서는 해당 system-call number를 register에 올려야 함

System-call number

어떤 System Call인지를 구분

• 각 system call에 할당됨
• user code는 원하는 system-call number를 레지스터에 배치함

---

Limited Direction Execution Protocol 

실행 순서

trap으로 syscall을 호출하면 register를 kernel stack에 저장하고 trap handler로 jump 한다.

이후 syscall이 끝나면 return-from-trap으로 kernel stack에서 register를 가져오고 user mode로 돌아간다. 

• User stack : user function 호출할 때 사용
• Kernel stack : kernel function 호출할 때 사용
  • Kernel stack의 역할 : user mode에서 시스템 콜을 통해 kernel function들을 사용할 때 필요한 자료구조, 프로그램 실행에 필요한 지역 변수들을 저장하기 위한 공간
• system call number : 어떤 system call인지 구분
• trap table : trap handler 함수에 대한 정보 저장 

---

Problem 2 : Switching Between Processes 

process 간 switching 방법 >>> 어떻게 OS가 CPU를 통제할 것인가?

• cooperative approach : system calls을 기다림 (process가 자발적으로 cpu를 반납할 때까지 기다림)
• Non-cooperative approach : OS가 cpu 강제로 가져오기 

---

A cooperative Approach : Wait for system calls

yield syscall로 process가 주기적으로 CPU를 포기함 

• 구식, process가 무한 루프에 빠지게 되면 컴퓨터를 reboot 해야함 

---

A Non-Cooperative Approach : OS Takes Control

timer interrupt 발생 >>> 주기적으로 timer interrupt를 발생시킴 

• booting 과정에서는 OS는 timer를 시작, 일정 시간마다 interrupt 발생
• interrupt 발생
  • 현재 실행중인 process가 halt
  • interrupt handler 실행 
  • 현대의 OS 방식 

---

Saving and Restoring Context

• Scheduler가 결정함
  
  • 현재의 process를 계속 실행할지, 아니면 다른 process로의 context를 할지 결정 
  • 만약, scheduler의 decision이 switch를 한다는 것이면 OS는 context switch 함

---

Context Switch

low-level의 assembly code로 되어있음 

• 현재 process의 register값들을 kernel stack에 저장해둠
• 바로 다음에 수행할 process의 값들을 kernel stack에 복원함
• 다음에 수행할 process의 kernel stack으로 switch 함

---

Limited Direction Execution Protocol (Timer interrupt)

수행 과정

OS가 trap을 handle함 >>> Process B를 주겠다고 결정 >>> 현재 register A (regs(A))를 proc-struct(A)에 저장

• Kernel에 저장한 register와 무엇이 다른가?
  • 앞은 user code를 수행 중일 때 CPU의 상태, Process A로 돌아갈 때 필요
  • 뒤는 kernel code를 수행 중일 때 상태를 저장해둠 
• 실제로는 이때 Process A의 동작을 멈춤
• register 값을 두 번 저장한다는 것 

---

The xv6 Context Switch Code 

xv6 context switch code

---

Worried About Concurrency?

Concurrency : interrupt나 trap handling이 실행중일 때 또 다른 interrupt가 발생하면??

• interrupt 과정에서는 interrupts disable 시킴 
• Use a number of sophisticate locking schemes to protect concurrent access to internal data structures. (내부 데이터 구조에 대한 동시 access를 보호하기 위해 여러 가지 정교한 잠금 체계를 사용)

---

 

부산대학교 안성용 교수님의 강의를 복습하기 위한 글입니다.
복습용 글이기에 정확하지 않을 수 있다는 점 유의하시길 바랍니다.