Fixes on part20

Author: syuu1228

part20.md

@@ -1,43 +1,76 @@
-ハイパーバイザーの作り方 第２０回　bhyveにおける仮想ディスクの実装
+---
+authors:
+- 'Takuya ASADA [email protected]'
+title: |
+    ハイパーバイザの作り方～ちゃんと理解する仮想化技術～ 
+    第２０回 bhyveにおける仮想ディスクの実装
+...
 
 はじめに
+========
 前回の記事では、bhyveにおける仮想NICの実装についてTAPデバイスを用いたホストドライバの実現方法を例に挙げ解説しました。
+
 今回の記事では、bhyveにおける仮想ディスクの実装について解説していきます。
 
 bhyveにおける仮想ディスクの実装
+===============================
 bhyveがゲストマシンに提供する仮想IOデバイスは、全てユーザプロセスである/usr/sbin/bhyve上に実装されています（図１）。
+
 bhyveは実機上のディスクコントローラと異なり、ホストOSのファイルシステム上のディスクイメージファイルに対してディスクIOを行います。
+
 これを実現するために、/usr/sbin/bhyve上の仮想ディスクコントローラは、ゲストOSからのIOリクエストをディスクイメージファイルへのファイルIOへ変換します。
 
 以下に、ディスク読み込み手順と全体図（図１）を示します。
-１，ゲストOSはvirtio-blkドライバを用いて、共有メモリ上のリングバッファにIOリクエストを書き込みます。そして、IOポートアクセスによってハイパーバイザにリクエスト送出を通知する。IOポートアクセスによってVMExitが発生し、CPUの制御がホストOSのvmm.koのコードに戻る。
+
+1. ゲストOSはvirtio-blkドライバを用いて、共有メモリ上のリングバッファにIOリクエストを書き込みます。そして、IOポートアクセスによってハイパーバイザにリクエスト送出を通知する。IOポートアクセスによってVMExitが発生し、CPUの制御がホストOSのvmm.koのコードに戻る。
 bhyveの仮想ディスクコントローラのエミュレーションは、ユーザランドで行われています。vmm.koはこのVMExitを受けてioctlをreturnし/usr/sbin/bhyveへ制御を移す。
-２，ioctlのreturnを受け取った/usr/sbin/bhyveは、仮想ディスクコントローラの共有メモリ上のリングバッファからリクエストを取り出します。
-３，２で取り出したリクエストをパースし、ディスクイメージファイルにread()を行います。
-４，読み出したデータを共有メモリ上のリングバッファに乗せ、ゲストOSに割り込みを送ります。５，ゲストOSは割り込みを受け、リングバッファからデータを読み出します。
-図１，ディスク読み込み手順
+2. ioctlのreturnを受け取った/usr/sbin/bhyveは、仮想ディスクコントローラの共有メモリ上のリングバッファからリクエストを取り出します。
+3. ２で取り出したリクエストをパースし、ディスクイメージファイルにread()を行います。
+4. 読み出したデータを共有メモリ上のリングバッファに乗せ、ゲストOSに割り込みを送ります。
+5. ゲストOSは割り込みを受け、リングバッファからデータを読み出します。
+
+![ディスク読み込み手順](figures/part20_fig1)
 
 書き込み処理では、リクエストと共にデータをリングバッファを用いて送りますが、それ以外は読み込みと同様です。
 
-virtio-blkの仕組み
+virtio-blkのしくみ
+==================
 これまでに、準仮想化I/Oの仕組みとして、virtioとVirtqueue、virtio-netについて解説してきました。ここでは、ブロックデバイスを準仮想化する、virtio-blkについて解説を行います。
-virtio-netは受信キュー、送信キュー、コントロールキューの３つのVirtqueueからなっていましたが、virtio-blkでは単一のVirtqueueを用います。これは、ディスクコントローラの挙動がNICとは異なり、必ずOSからコマンド送信を行った後にデバイスからレスポンスが返るという順序になるためです。
+
+virtio-netは受信キュー、送信キュー、コントロールキューの３つのVirtqueueからなっていましたが、virtio-blkでは単一のVirtqueueを用います。これは、ディスクコントローラの挙動がNICとは異なり、必ずOSからコマンド送信を行った後にデバイスからレスポンスが返るという順序になるためです[^1]。
+
 ブロックIOのリクエストは連載第１２回の「ゲスト→ホスト方向のデータ転送方法」で解説した手順で送信されます。
-virtio-blkでは１つのブロックIOリクエストに対して、以下のようにDescriptor群を使用します。１個目のDescriptorはstruct
-virtio~b~lk~o~uthdr（表１）を指します。
-この構造体にはリクエストの種類、リクエスト優先度、アクセス先オフセットを指定します。２〜（ｎ−１）個目以降のDescriptorはリクエストに使用するバッファを指します。リクエストがreadな場合は読み込み結果を入れる空きバッファを、writeな場合は書き込むデータを含むバッファを指定します。
+
+virtio-blkでは１つのブロックIOリクエストに対して、以下のようにDescriptor[^2]群を使用します。１個目のDescriptorはstruct virtio_blk_outhdr（表１）を指します。この構造体にはリクエストの種類、リクエスト優先度、アクセス先オフセットを指定します。２〜（ｎ−１）個目以降のDescriptorはリクエストに使用するバッファを指します。リクエストがreadな場合は読み込み結果を入れる空きバッファを、writeな場合は書き込むデータを含むバッファを指定します。
+
 バッファのアドレスは物理アドレス指定になるため、仮想アドレスで連続した領域でも物理的配置がバラバラな状態な場合があります。これをサポートするためにバッファ用Descriptorを複数に別けて確保出来るようになっています。
-struct
-virtio~b~lk~o~uthdrにはバッファ長のフィールドがありませんが、これはDescriptorのlenフィールドを用いてホストへ通知されます。ｎ個目のDescriptorは1byteのステータスコード（表２）のアドレスを指します。このフィールドはホスト側がリクエストの実行結果を返すために使われます。
 
-表１，struct virtio~b~lk~o~uthdr
+struct virtio_blk_outhdrにはバッファ長のフィールドがありませんが、これはDescriptorのlenフィールドを用いてホストへ通知されます。ｎ個目のDescriptorは1byteのステータスコード（表２）のアドレスを指します。このフィールドはホスト側がリクエストの実行結果を返すために使われます。
+
+  type  member  description
+  ----- ------- --------------------------------------------------
+  u32   type    リクエストの種類（read=0x0, write=0x1, ident=0x8)
+  u32   ioprio  リクエスト優先度
+  u64   sector  セクタ番号（オフセット値）
+
+ Table: struct virtio_blk_outhdr
+
+  type  member  description
+  ----- ------- ---------------------------
+  0     OK      正常終了
+  1     IOERR   IOエラー
+  2     UNSUPP  サポートされないリクエスト
 
-表２，ステータスコード
+ Table: ステータスコード
 
 ディスクイメージへのIO
-/usr/sbin/bhyveはvirtio-blkを通じてゲストOSからディスクIOリクエストを受け取り、ディスクイメージへ読み書きを行います。bhyveが対応するディスクイメージはRAW形式のみなので、ディスクイメージへの読み書きはとても単純です。ゲストOSから指定されたオフセット値とバッファ長をそのまま用いてディスクイメージへ読み書きを行えばよいだけです。
+======================
+/usr/sbin/bhyveはvirtio-blkを通じてゲストOSからディスクIOリクエストを受け取り、ディスクイメージへ読み書きを行います。bhyveが対応するディスクイメージはRAW形式のみなので、ディスクイメージへの読み書きはとても単純です。ゲストOSから指定されたオフセット値とバッファ長をそのまま用いてディスクイメージへ読み書きを行えばよいだけです[^3]。
+
 それでは、このディスクイメージへのIOの部分についてbhyveのコードを実際に確認してみましょう。/usr/sbin/bhyveの仮想ディスクIO処理のコードをコードリスト１に示します。
 
+コードリスト１，/usr/sbin/bhyveの仮想ディスクIO処理
+---------------------------------------------------
 ```
 /* ゲストOSからIO要求があった時に呼ばれる */
 static void
@@ -54,11 +87,14 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq)
 	uint16_t flags[VTBLK_MAXSEGS + 2];
 	/* iovに１リクエスト分のDescriptorを取り出し */
 	n = vq_getchain(vq, iov, VTBLK_MAXSEGS + 2, flags);
-					〜 略 〜
	/* 一つ目のDescriptorはstruct virtio_blk_outhdr */
-	vbh = iov[0].iov_base;
	/* 最後のDescriptorはステータスコード */
+					〜 略 〜
+        /* 一つ目のDescriptorはstruct virtio_blk_outhdr */
+	vbh = iov[0].iov_base;
+        /* 最後のDescriptorはステータスコード */
 	status = iov[--n].iov_base;
 					〜 略 〜
-	/* リクエストの種類 */
	type = vbh->vbh_type;
+	/* リクエストの種類 */
+        type = vbh->vbh_type;
 	writeop = (type == VBH_OP_WRITE);
 	/* オフセットをsectorからbyteに変換 */
 	offset = vbh->vbh_sector * DEV_BSIZE;
@@ -104,12 +140,12 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq)
 	vq_relchain(vq, 1);
 }
 ```
-コードリスト１，/usr/sbin/bhyveの仮想ディスクIO処理
 
-(1) NICではOSから何もリクエストを送らなくてもネットワーク上の他のノードからパケットが届くのでデータが送られてきます。このため、必ずOSからリクエストを送ってから届くというような処理にはなりません。
-(2) Virtqueue上でデータ転送をおこなうための構造体。第１２回のVirtqueueの項目を参照。
-(3) QCOW2形式などのより複雑なフォーマットでは未使用領域を圧縮するため、ゲスト・ホスト間でオフセット値が一致しなくなり、またメタデータを持つ必要が出てくるのでRAWイメージと比較して複雑な実装になります。
+[^1]: NICではOSから何もリクエストを送らなくてもネットワーク上の他のノードからパケットが届くのでデータが送られてきます。このため、必ずOSからリクエストを送ってから届くというような処理にはなりません。
+[^2]: Virtqueue上でデータ転送をおこなうための構造体。第１２回のVirtqueueの項目を参照。
+[^3]: QCOW2形式などのより複雑なフォーマットでは未使用領域を圧縮するため、ゲスト・ホスト間でオフセット値が一致しなくなり、またメタデータを持つ必要が出てくるのでRAWイメージと比較して複雑な実装になります。
 
-## まとめ
+まとめ
+======
 今回は仮想マシンのストレージデバイスについて解説しました。
 次回は、仮想マシンのコンソールデバイスについて解説します。