서울대학교 컴퓨터공학과 김진수 교수님의 "고급 운영체제" 강의를 필기한 내용입니다.
다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.
정리되지 않은 필기록 원본입니다.
VM
- VM 은 native speed 가 나오도록 하는 것이 목표
- VM 을 가능하게 해주는 것 - VM Monitor (VMM) == Hypervisor
- 60’ 70’ 년대부터 시작된 아주 오래된 분야이다
- 이것은 당시 IBM Mainframe 컴퓨터가 준나게 바싸서 좀 잘게 쪼개서 쓰자는 요구사항때문
- 하지만 이후에는 PC 가 나오며 인기가 좀 시들해졌다가
- 90’ 년대에 와서 다시 조금 활발해지기 시작
- VM 사용 이유는
- 자원 분할
- 옛날 OS 가 필요한 경우
- Server consolidation - 클라우드, VM 팔이소년
- OS 개발 편의
- Type
- type 1 (Bare-metal VM): 부팅시에 VMM 이 먼저 올라오고, 그 뒤에 각각의 VM 이 실행되는 식
- type 2 (Hosted hypervisor): OS 가 먼저 뜨고, 그 위에 VMM 을 올려 VM 을 실행시키는 식
- KVM 의 경우에는 linux kernel 자체가 VMM 이 되기 때문에 좀 애매한 위치
- 관련 기술
- Machine level simulator (emulator): QEMU 같은 애들
- CPU, MEM 같은 HW 를 simulate 하다가 machine 전체를 simulate 하는 레벨까지
- Guest 의 instruction 을 적절하게 interprete 해서 host 에서 돌려주기
- 다만 느리당
- ABI/API emulator
- Linux 진영의 WINE - Windows OS 의 syscall 을 emulate 하기
- Machine level simulator (emulator): QEMU 같은 애들
Popek Goldberg Theorem
- CPU virtualization
- 조건1) sensitive inst 은 privileged inst 의 subset 이어야 한다
- sensitive inst 의 종류
- controller sensitive: register, page table 와 같은 system 의 상태를 바꾸는
- behavior sensitive: system 상태에 따라 다르게 작동하는
- Intel 의 IA-32 inst set 에는 위의 조건을 위반하는 inst 가 있다
- 즉, sensitive 한데 unprevileged 인
- 예를 들어 user level 에서 실행했을 때 trap 이 안걸리도록
- VMWare 에서는 이러한 문제가 있는 inst 에 대해 적절히 trap 이 걸리도록 했다 하고
- Xen project 에서는 저런 inst 를 안쓰도록 windows 를 고쳤다?
- 이것은 guest os 가 뭔가를 고쳤는데 hypervisor 가 그것을 알 방법이 없기 때문에 문제가 된다
- guest os 는 vCPU 를 고쳤는데, trap 이 안걸리니까 hypervisor 는 모르는
- Intel 은 2005 년에 VT-x 를 발표하며 이러한 문제를 종식했다 - 이걸 키면 이제 문제있는 inst 에 대해서는 trap 이 걸린다
- 이전에는
- Hypervisor 를 ring 0 (kernel mode) 에서 돌리고
- Guest OS 는 ring 1-2 (semi-kernel mode)
- User 는 ring 3 (user mode) 에서 돌린다
- 근데 이렇게 하면 user 가 보낸 syscall 이 hypervisor 로 왔다가 guest 로 가는 문제
- 왜냐면 guest 가 ring 1-2 니까 처리못하는 inst 가 있을 수 있으니
- 지금은 (VMX 기능)
- 이 ring0-3 을 한 pair 더 사용한다
- Hypervisor 의 ring0-3 가 있어서 여기에는 더 많은 권한이 있고 → 이걸 root mode
- Guest OS, user 만의 ring0-3 이 있고 → 이걸 non-root mode
- 그래서 Hypervisor 가 없을 떄는 그냥 non-root mode 로 쓰다가 hypervisor 를 키면 root mode 가 활성화되고
- mode 전환은 VM entry, VM exit 을 통해 한다
- 그래서 이 mode 전환을 빠르게 할 수 있는 방법이 연구되고 있다더라
- vm 간의 scheduling 을 해야 하기 때문에 VM entry 후 돌리다가 VM exit 후 다른 VM 을 entry 해서 돌리고
- Guest OS 의 physical mem addr 은 Hypervisor 의 vitual mem addr 이고, Gest OS 의 CPU 는 Hypervisor 의 process thread 들이다
- Disco 에서는 VM 이 HW speed 를 내게 하기 위해
- guest process 의 virtual addr (virtual-virtual addr) 를 바로 hyphervisor 의 physical addr 로 TLB 에 들어가게 한다
- Page table 의 경우에는 guest os 이 관리하고 있는 page table 의 shadow page table 를 hypervisor 가 갖고 있어서 이 gues-os-page-table 이 변경되면 hypervisor-shadow 에도 변경하되 그에 맞게 machine addr 로 채워넣고, guest process 가 cpu 를 받아 실행하게 되면 cr3 register 를 hypervisor 가 슬쩍 건드려 guest os 의 page table 이 아닌 hypervisor 의 page table 을 사용하게 한다
- page table 이 변경될때, 그리고 guest process 가 cpu 를 할당받을때 hypervisor 가 호출된다
- guest os 는 자기의 page table 을 cpu 에 줬다고 생각하지만 hypervisor 가 몰래 끼어들어서 이것을 hypervisor 의 page table 의 주소로 바꿔치기한다 - 그래서 cr3 에는 shadow page table 이 들어감
- TLB miss 가 났을 때 뒤지는 page table 이 shadow 가 되게 하기 위해서..?
- Intel 의 memory emulation…#draft Record
2024-06-11:46’
- sensitive inst 의 종류
- 조건1) sensitive inst 은 privileged inst 의 subset 이어야 한다
- VT-x QEMU
- IO emulation 은 실제 hw 를 register 단위로 emulate 하는 것은 불가능해서
- VM 에 driver 를 찔러 넣어서 거기로 요청이 들어오면 qemu 가 받아서 처리하는
- VM 생성할 때는 QEMU 가 /dev/kvm 에 ioctl() 를 때려 KVM 에서 VM entry 를 해서 non-root mode 를 만들어서 VM 생성
- VM 내에서 IO 는 KVM 을 거쳐 QEMU 로 가고
- inst interprete 는 더이상 binary translation 은 안하고 VT-x 를 쓴다
Disco
- virtual cpu: 위에서 설명한 것이랑 비슷하다 - 그냥 thread 를 VM 에 줘서 VM 에서는 이것을 진짜 CPU 라고 생각하고 host 는 이 thread 를 schedulign
- disco 는 cpu 를 위해 다음의 자료구조 유지
- saved register
- tlb
- previleged inst
- disco 는 cpu 를 위해 다음의 자료구조 유지
- virtual mem
- physical mem 상에 pmap 이라는 것이 있는데 여기에 physical addr 에 대한 machine addr 가 매핑된 tlb entry 가 있다
- 그래서 tlb miss 가 났을 때 이 pmap 의 tlb entry 를 vcpu 에 찔러넣어서 machine addr 를 찾게 한다?
- 즉 virtual addr → machine addr 이 tlb 에 찔러넣어졌다?
- #draft Record
2024-06-11:1h06m’, PPT15p - VM 에서 disk 를 share 하는 것은 NFS 를 사용하도록?
여기부터는
2024-06-04강의
- ccNUMA:
- core 마다 memory 를 사용하고, 다른 core 의 memory 에 접근하는 것은 느리나 interconnect 가 되어있어서 cache cohernce 는 되는
- shared memory multi processor (SMP) 를 위한 기존의 OS 를 이 ccNUMA 위에서 돌리기 위함
- lock contention? 의 문제?
- 그래서 이 ccNUMA 구조를 잘 쪼개서 기존의 OS 나 SMP-OS 각각이 하나의 core 를 잡고 움직이는 마치 VM 과 같이 작동하게 하는 것
- 가상화는 기본적으로
- os 입장에서 core 는 그냥 몇개의 특별한 register 를 가지고 있는 무언가이고 os 가 하는 것은 이 register 에 적당한 시기에 적절하게 값을 넣어주는 것
- process 의 thread 가 자기가 core 인 것 처럼 boot code 실행하고 북치고 장구치고 하며 core 를 emulation 하고
- process 의 virtual memory 공간을 physical memory 인 것처럼 사용
- VM 의 user process 가 syscall 을 걸면 이것은 일단 host 의 kernel mode 에서 돌고 있는 hypervisor 로 가고 이놈이 VM 의 OS 에게 이것을 토스하거나 내가 대신 처리해주거나?
- 메모리 virtualize 는 어렵댄다 - 깊게 설명 안함
- device io 를 emulation 해준다?