@@ -6,25 +6,25 @@ title: |
6
6
第16回 PCIパススルーその2「VT-dの詳細」
7
7
...
8
8
9
- # # はじめに
9
+ # はじめに
10
10
11
11
前回は、PCIパススルーとIOMMUの概要について解説しました。
12
12
今回は、VT-dの詳細について解説していきます。
13
13
14
- # # 前回のおさらい
14
+ # 前回のおさらい
15
15
16
16
PCIデバイスが持つメモリ空間をゲストマシンのメモリ空間にマップすることによりPCIデバイスをパススルー接続できますが、DMAを使用するときに1つ困った問題が生じます。
17
17
18
18
PCIデバイスはDMA時のアドレス指定にホスト物理アドレスを使用します。ゲストOSは、ゲストOSは自分が持つゲスト物理ページとホスト物理ページの対応情報を持っていないので正しいページ番号をドライバに与えることができません。
19
19
20
20
そこで、*物理メモリとPCIデバイスの間にMMUのような装置を置きアドレス変換を行う*方法が考え出されました。
21
21
このような装置を*IOMMU*と呼びます。
22
- DMA転送時にアドレス変換を行うことで、パススルーデバイスが正しいページへデータを書き込めるようになります(図[fig1] )。
22
+ DMA転送時にアドレス変換を行うことで、パススルーデバイスが正しいページへデータを書き込めるようになります(図1 )。
23
23
Intel VT-dは、このような機能を実現するためにチップセットへ搭載されたIOMMUです。
24
24
25
- 
25
+ 
26
26
27
- # # VT-dの提供する機能
27
+ # VT-dの提供する機能
28
28
29
29
VT-dが提供する機能には、次のようなものが挙げられます。
30
30
@@ -37,23 +37,30 @@ VT-dが提供する機能には、次のようなものが挙げられます。
37
37
38
38
なお、VT-dに関するより詳しい内容は"Intel Virtualization Technology for Directed I/O Architecture Specification"という資料にて解説されているので、こちらをご覧下さい[^2]。
39
39
40
- [^1]) より正確には、DMA remapping機能のうち"Requests-without-PASID"であるものについてのみ解説しています。
41
- [^2]) <http://www.intel.co.jp/content/www/jp/ja/intelligent-systems/intel-technology/vt-directed-io-spec.html>
40
+ [^1] : より正確には、DMA remapping機能のうち"Requests-without-PASID"であるものについてのみ解説しています。
41
+ [^2] : <http://www.intel.co.jp/content/www/jp/ja/intelligent-systems/intel-technology/vt-directed-io-spec.html>
42
42
43
- # ## アドレス変換テーブル
43
+ # # アドレス変換テーブル
44
44
45
45
VT-dでは、アドレスリマップ対象のデバイスごとにCPUのMMUと同様の多段ページテーブルを持ちます。
46
46
デバイスごとのページテーブルを管理するため、PCIデバイスを一意に識別するBus Number・Device Number・Functionの識別子から対応するページテーブルを探すための2段のテーブルを用います。
47
47
48
48
1段目はRoot Tableと呼ばれ、0から255までのBusナンバーに対応するエントリからなるテーブルです。
49
49
このテーブルはアドレス変換時にVT-dから参照するため、Root Table Address Registerへセットされます。
50
- Root Tableエントリのフォーマットを表[tab1]に示します 。
50
+ Root Tableエントリのフォーマットを表1に示します 。
51
51
52
- Table : 表1, Root table entry format
52
+ bits field description
53
+ ------ --------------------- --------------------------
54
+ 127:64 reserved 予約フィールド
55
+ 63:12 context-table pointer Context-tableのアドレス
56
+ 11:1 reserved 予約フィールド
57
+ 0 present このエントリが有効化どうか
58
+
59
+ Table : Root table entry format
53
60
54
61
Root tableエントリはcontext-table pointerフィールドで2段目のテーブルであるContext-tableのアドレスを指します。
55
62
Context-tableはRoot tableエントリで示されるBus上に存在するDevice 0-31・Function 0-7の各デバイスに対応するページテーブルを管理しています。
56
- Context-tableエントリのフォーマットを表[tab2]に示します 。
63
+ Context-tableエントリのフォーマットを表2に示します 。
57
64
58
65
----------------------------------------------------------------------------------------------------------------
59
66
bits field description
@@ -81,36 +88,36 @@ bits field description
81
88
0 present このエントリが有効化どうか
82
89
----------------------------------------------------------------------------------------------------------------
83
90
84
- Table : 表2, Context-table entry format
91
+ Table : Context-table entry format
85
92
86
93
Context-tableエントリはsecond level page translation pointerでページテーブルのアドレスを指します。
87
94
ページテーブルの段数はaddress widthフィールドで指定されます。
88
- 図[fig2]に4段ページテーブル ・4KBページを使用する場合のアドレス変換テーブルの全体図を示します。
95
+ 図2に4段ページテーブル ・4KBページを使用する場合のアドレス変換テーブルの全体図を示します。
89
96
ここで使用されるページテーブルエントリのフォーマットは通常のページテーブルエントリと若干異なるのですが、ここでは解説は割愛します。
90
97
91
- ")
98
+ ")
92
99
93
- # ## フォールト
100
+ # # フォールト
94
101
95
102
変換対象になるアドレスに対する有効なページ割り当てが存在しない場合、または対象ページへのアクセス権がない場合、VT-dはフォールトを起こします。
96
103
フォールトが発生した場合、メモリアクセスを行おうとしたPCIデバイスはアクセスエラーを受け取ります。
97
104
OSへは、MSI割り込みを使用して通知されます。
98
105
99
- # ## IOTLB
106
+ # # IOTLB
100
107
101
108
IOMMUのアドレス変換を高速に行うには、通常のMMUと同じようにアドレス変換結果のキャッシュが必要です。
102
109
通常のMMUではこのような機構のことをTLBを呼びますが、IOMMUではIOTLBと呼びます。
103
110
通常のMMUのTLBでは、TLBエントリが古くなったときにinvalidateと呼ばれる操作によりエントリを削除します。
104
- このときのinvalidateの粒度は、グローバルなinvalidate・プロセス単位のinvalidate([^3]) ・ページ単位のinvalidateなどが選べます。
111
+ このときのinvalidateの粒度は、グローバルなinvalidate・プロセス単位のinvalidate([^3]: ・ページ単位のinvalidateなどが選べます。
105
112
VT-dのIOTLBでは、グローバルなinvalidate・デバイス単位のinvalidate・VM単位(ドメインと呼ばれる)のinvalidate・ページ単位のinvalidateが行えるようになっています。
106
113
107
- [^3]) Tagged TLBの場合。
114
+ [^3] : Tagged TLBの場合。
108
115
109
- # ## Context-cache
116
+ # # Context-cache
110
117
111
118
IOTLBに類似していますが、VT-dではContext-table entryもキャッシュされています。これについても場合によってinvalidate操作が必要になります。
112
119
113
- # # DMARによるIOMMUの通知
120
+ # DMARによるIOMMUの通知
114
121
115
122
DMAリマッピング機能がハードウェア上に存在することをOSに伝えるため、ACPIはDMARと呼ばれるテーブルを用意しています。
116
123
DMARでは、いくつかの異なる種類の情報が列挙されています。
@@ -121,8 +128,8 @@ DRHDはIOMMUのレジスタベースアドレスと、IOMMUがDMAリマッピン
121
128
VT-dの設定をOS上から簡単に確認することは難しいですが、ACPIテーブルは簡単に見ることができるので、ここでその方法を説明します。
122
129
例としてUbuntu LinuxでDMARを表示するコマンドを画面1に示します。
123
130
131
+ # # 画面1 DMAR表示コマンド(Ubuntu Linux)
124
132
` ` `
125
- 画面1 DMAR表示コマンド(Ubuntu Linux)
126
133
$ sudo apt-get install iasl
127
134
$ sudo cp /sys/firmware/acpi/tables/DMAR .
128
135
$ sudo iasl -d DMAR
@@ -185,26 +192,40 @@ Hardware Unit Definitionと表示されているのがDRHDで、Reserved Memory
185
192
186
193
このテーブルの情報が誤っていると、BIOSとカーネルでVT-dを有効にしてもLinuxカーネルがエラーを起こしてPCIパススルーが正常に動作しない場合があります[^4]。
187
194
188
- [^4]) この場合、ユーザの設定ミスではなくBIOSのバグなので、対策としてはサーバベンダからBIOSアップデートを受け取るか、カーネル側でDMARを無視して強引に初期化するような方法しかありません。
195
+ [^4] : この場合、ユーザの設定ミスではなくBIOSのバグなので、対策としてはサーバベンダからBIOSアップデートを受け取るか、カーネル側でDMARを無視して強引に初期化するような方法しかありません。
189
196
190
- # ## VT-dのレジスタ
197
+ # # VT-dのレジスタ
191
198
192
199
VT-dで使用される主なレジスタを表3に示します。
193
200
VT-dのレジスタはメモリマップドでアクセスでき、ベースアドレスは前述のDMAR上のDRHDで通知されます。
194
201
195
- 表3, VT-dの主なレジスタ
202
+ offset name description
203
+ ---------- ---------------------------- ---------------------------------------
204
+ 008h capability register VT-d上の機能の有無を示す
205
+ 010h extended capability register 追加のcapabilityレジスタ
206
+ 018h global command register VT-dの操作を行う
207
+ 01ch global status register VT-dのステートを通知
208
+ 020h root table address register Root tableのアドレスを設定
209
+ 028h context command register context-cacheを操作
210
+ 034h fault status register フォールトを通知
211
+ XXXh invalidate address register IOTLB invalidate時のアドレス指定
212
+ invalidate address registerのアドレスは
213
+ extended capability registerで定義
214
+ XXXh+008h IOTLB invalidate register IOTLB invalidateを実行
215
+
216
+ Table : VT-dの主なレジスタ
196
217
197
- # ## VT-dの有効化
218
+ # # VT-dの有効化
198
219
199
220
VT-dを有効化し、DMAリマップを行うには以下のような手順で設定を行います。
200
221
201
- xxxxx設定完了までウエイトするために 、global status registerのtranslation enable statusにビットが立つまでループします。
222
+ 設定完了までウエイトするために 、global status registerのtranslation enable statusにビットが立つまでループします。
202
223
203
224
1. メモリ上にルートテーブル、コンテキストテーブルを作成
204
225
2. root table address registerにroot tableのアドレスを設定し、global command registerにset root table pointerをセット(表4)してroot tableのアドレスを設定します。
205
226
設定完了までウエイトするために、global status registerのroot table pointer statusにビットが立つまで(表5)ループします
206
227
3. IOTLB、Context-cacheをinvalidateします(細かい手順は省略します)
207
- 4. global command registerにtranslation enableをセットしてDMAリマッピングを有効化します xxxxx
228
+ 4. global command registerにtranslation enableをセットしてDMAリマッピングを有効化します
208
229
209
230
bits|field|description
210
231
-|-|-
@@ -219,7 +240,7 @@ bits|field|description
219
240
23|compatibility format interrupt|compatibility format interrupt 有効・無効化
220
241
22:00|reserved|予約フィールド
221
242
222
- Table : 表4, global command register
243
+ Table : global command register
223
244
224
245
|bits|field|description|
225
246
|-|-|-|
@@ -234,15 +255,14 @@ Table: 表4, global command register
234
255
|23|compatibility format interrupt status|compatibility format interruptの状態|
235
256
|22:00|reserved|予約フィールド|
236
257
237
- Table : 表5, global status register
258
+ Table : global status register
238
259
239
- # # まとめ
260
+ # まとめ
240
261
241
262
今回は、VT-dの詳細について解説しました。
242
263
次回からは、よりソフトウェア寄りの視点から仮想化を解説していきたいと思います。
243
264
244
- ライセンス
245
- ==========
265
+ # ライセンス
246
266
247
267
Copyright (c) 2014 Takuya ASADA. 全ての原稿データ は
248
268
クリエイティブ・コモンズ 表示 - 継承 4.0 国際
0 commit comments