xv6 chapter1 first

Transcript

1. xv6 chapter1 first Tomoya Ishizaki
2. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
3. 本題に入る前に
4. OSは大きく分けて三つの機能が要求される 1. multiplexing（多重化） 2. isolation（独立性） 3. interaction（相互作用）
5. 1. multiplexing
6. 1. multiplexing • time-share（時分割） 一つのCPUで複数のプロセスが同時に動いているように見せる CPU時間 プロセスB プロセスA
7. 2. isolation
8. 2. isolation • それぞれのプロセスを独立させる • あるプロセスがバグなどで異常終了したとしても その他のプロセスに影響を与えない
9. 3. interaction
10. 3. interaction • パイプなど • プロセスとプロセスの間でやり取りして 複雑なタスク処理を実現する
11. オペレーティングシステムの三要求 1. multiplexing 2. isolation 3. interaction
12. では本題
13. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
14. 物理的資源の抽象化
15. OSによる抽象化がなかったら？
16. A. 「強い独立性」を保てない 各自でハードウェア資源の獲得・解放をしなければなら なず, それぞれのアプリケーションは互いを信用する必 要がある. ただし、組み込み・リアルタイムシステムではパフォーマ ンスのため採用されることも.
17. CPUの抽象化 forkなど アプリケーションは... • スイッチングを気にしなくて済む OSは... • 悪いプログラムを強制スイッチできる
18. OSによる抽象化
19. 例えば... • ハードディスクの抽象化 • CPUの抽象化 • メモリの抽象化 • 共有先の抽象化
20. open, read, write, close アプリケーションは... • パス名を用いて資源にアクセスできる OSは... • ハードディスクを管理できる ハードディスクの抽象化
21. メモリの抽象化 execなど アプリケーションは... • 簡単にイメージを保存できる OSは... • 物理メモリを管理できる
22. 共有先の抽象化 ファイルディスクリプタ • ターミナル, ファイルシステム, パイプ間での 相互的な操作が簡単に • アプリケーションは共有先の詳細を知る必要がない
23. • ハードウェアの抽象化（open, read, write, close） • CPUの抽象化（fork） • メモリの抽象化（exec） • 共有先の抽象化（ファイルディスクリプタ） 強い独立性を保つために抽象化が必要
24. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
25. ユーザーモード, カーネルモード, システムコール
26. 強い独立性のためには強い境界が必要 ハードウェア オペレーティングシステム アプリケーション ユーザー システムを利用 システムを実装
27. プロセッサのサポートによって二つのモードを実現 1. user mode（ユーザーモード） 2. kernel mode（カーネルモード） カーネルモードでは, privileged instruction（特権命令）が実行できる
28. 具体例：I/O処理 ユーザー空間 カーネル空間 ① 読み書き命令 割込み ② 命令をチェック ③ 命令を実行 ④ 終わったら戻る
29. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
30. カーネルの構成
31. どの部分をカーネルとするかで二つのタイプに分けられる https://techdifferences.com/difference-between-microkernel-and-monolithic-kernel.html
32. モノリシックカーネル • OSの操作は全てカーネルモードで実行する • fork, exec, open, close, read, writeなどは 全てカーネルコールとして実装 • システムコールがカーネルへのインターフェースとなる
33. モノリシックカーネルの利点 • OSの操作全てがハードウェアの全権限で実行される • それぞれの部分の権限範囲について考える必要がない • OSの異なる部分が協調して動作することも容易 ◦ バッファキャッシュ ◦ ファイルシステムと仮想メモリによる協調
34. モノリシックカーネルの欠点 • 異なる部分間のインターフェースは複雑であり, OS開発者はミスを生みやすい • しかしモノリシックカーネルにおいてバグは致命的 • バグによってカーネルが異常終了するとコンピュータは 動作不能となり, アプリケーションも動作不能 • コンピュータは再起動せざるを得なくなる
35. マイクロカーネル • カーネルは, I/O操作やメッセージの送信など いくつかの低レイヤの関数のみで構成 • ほとんどのオペレーティングシステムの機能は ユーザレベルのサーバーとして実装される • サーバーがマイクロカーネルを介してメッセージを やり取りすることで動作する
36. xv6はモノリシックカーネル • 古典的なUnix派生のOSはモノリシック • それに習いxv6もモノリシックで作られている • Tanenbaum–Torvalds debate ◦ “LINUX is obsolete” ◦ https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
37. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
38. プロセスの概要
39. プロセスは独立性を提供 • プロセスは抽象化された一つのマシンのように実現 • プログラムにaddress space（アドレス空間）を提供 ◦ プライベートなメモリシステムを使える • それぞれ固有のCPUを持つように動作できる
40. プロセスの恩恵 • メモリの内容を見られることを防ぐ • 他のプロセスから破壊されることを防ぐ • カーネルを破壊してしまうことを防ぐ • 悪意のあるプログラムによる攻撃を防ぐ
41. xv6でのアドレス空間の実現 • ページテーブルを利用 • 仮想アドレスを物理アドレス にマップする • プロセスが固有のアドレス 空間を持つことを可能に • 詳しくは2章
42. 仮想アドレス空間 ユーザー領域 • 0番地から ◦ 命令 ◦ グローバル変数 ◦ スタック ◦ 最後にヒープ（malloc用） カーネル領域 • 0x80100000番地から • カーネルコールはユーザーメモリ を直接参照可能
43. proc構造体 • それぞれのプロセスの状態の多くを管理する • カーネルの重要な情報 ◦ pgdir（ページテーブル） ◦ kstack（カーネルスタック） ◦ state（実行状態）
44. スレッド • プロセスはスレッドを保持する • スレッドはプロセスの命令を実行 • スレッドは停止させたり再開させたりすることが可能 • 状態の多くはスレッドのスタックに保存される ◦ ローカル変数、関数呼び出しのリターンアドレスなど
45. 具体例：プロセスの状態遷移 実行可能状態 （ready） 実行状態 （running） 終了状態 （exiting） 待ち状態 （waiting） CPUの解放 CPUの獲得 実行が終了 入出力待ち 入出力の終了 • 詳しくは5章
46. 各プロセスは二つのスタックを所持 ユーザースタック • プロセスがユーザ命令を実行した時に使用 • カーネルスタックは空 カーネルスタック • プロセスがカーネルモードにスイッチした時に使用 • ユーザスタックはデータを保持するだけ カーネルスタックは分離されており, ユーザースタックが破壊されてもカーネルコードを実行可能
47. 具体例：システムコールの実行 • 詳しくは後半と2章 1. プロセスがシステムコールを発行する 2. プロセッサがカーネルスタックにスイッチ 3. ハードウェアの権限レベルを上げる（カーネルモード） 4. カーネル命令を実行 5. 実行が完了 6. ハードウェアの権限レベルを戻す（ユーザーモード） 7. 再びユーザスタックにスイッチ
48. オペレーティングシステムの構成（前半） • 物理的資源の抽象化 • ユーザーモード, カーネルモード, システムコール • カーネルの構成 • プロセスの概要 • コード：最初のアドレス空間
49. コード：最初のアドレス空間
50. カーネルによる最初のアドレス空間の生成 • 強力な独立性のため、自身のアドレス空間を作る必要 • カーネルがアドレス空間をどのように作っていくか • entry.S ◦ 50行弱のアセンブラ ◦ https://github.com/mit-pdos/xv6-public/blob/master/entry.S
51. PCの電源を入れた時に起こること ざっくりと流れを追うと、 1. BIOSを起動 2. ブートローダ（boot loader）を実行 3. OSが動き始める
52. • 起動時に呼び出されて、OSを動かす • ブート + ローダ ◦ ブート ▪ OSを起動するために、 ◦ ローダ ▪ カーネルをハードディスクからメモリに読み込む • 詳細はAppendix B ブートローダ
53. • カーネルを物理アドレスの0x100000へロード • 0x80100000ではないの？ ◦ 小さなマシンの可能性がある • 0x0ではないの？ ◦ BIOSやブートローダで使用済 xv6のカーネルをロードする
54. • カーネルを物理アドレスの0x100000へロード • 0x80100000ではないの？ ◦ 小さなマシンの可能性がある • 0x0ではないの？ ◦ BIOSやブートローダで使用済 xv6のカーネルをロードする
55. ブートページテーブル https://github.com/mit-pdos/xv6-public/blob/master/main.c#L102
56. • entry0 (main.c 105行目) ◦ 仮想アドレスの [0x0:0x400000) を物理アドレスの [0x0:0x400000) に ◦ entryが低いアドレスで動いている間だけ使用する ◦ entryが終了すると消去 • entry512 (main.c 107行目) ◦ KERNBASE>>PDXSHIFT ◦ 仮想アドレスの [KERNBASE:KERNBASE+0x400000) を物理アドレスの [0x0:0x400000) に ◦ entry.Sが終了した後にカーネルが使用する ◦ ※ 命令やデータがブートローダより低いアドレスで実行されることを想定 ◦ → カーネルの命令やデータは、 4メガバイト以内でなけれないけない pde_t entrypgdir[NPDENTRIES] (main.c 103行目)
57. entry.S（前半） • (l.46) ページサイズの拡張 ◦ CR4_PSE（0x0000001）を レジスタ%cr4に書き込む • (l.50) ページディレクトリの設定 ◦ entrypgdrの物理アドレスを レジスタ%cr3に書き込む ◦ V2P_WO(x) ((x) - KERNBASE) • (l.54) ページングを有効化 ◦ CR0_PGをフラグをレジスタ%cr0に 設定してページングハードウェアを 有効化する
58. entry.S（後半） • (l.58) スタックポインタを設定 ◦ スタックポインタ%espを作成し、 メモリのスタック領域に設定 ◦ .comm stack, KSTACKSIZE • (l.61) main関数にジャンプ ◦ プロセッサが低いアドレスから 高いアドレスに遷移する ◦ この間接的なジャンプをするために entry.Sのようなアセンブラが必要 • main関数に遷移して実行を開始
59. 後半へ
60. ご清聴ありがとうございました