Kernel Engineer

オペレーティングシステムの低レイヤ部分の問題解析は難しい。

ハードウェアとソフトウェアの両方を大局的に把握する力と、かつ細部まで深く理解する力が必要である。
プロセッサのアーキテクチャ、命令セット、システムのアーキテクチャ、例外処理、スタック管理、割り込み管理、アドレス変換、コンテキストスイッチ、など、包括的、かつ深い理解が必須である。

オペレーティングシステムの開発は経験も必要とするが、経験だけでは解決できない問題も非常に多い。非常に困難な問題にあたると、平均レベルの人には数年与えても解決できないこともあるだろう。一方で解決できる人は見た瞬間、もしくは数時間から数日で解析できる。

オペレーティングシステムのエンジニアは能力に本当に差がでる。生産性が高いエンジニアと平均レベルのエンジニアで比較しても、数十倍は違う。生産性の高いエンジニアが2時間で解決できる問題に、平均レベルのエンジニアでは1ヶ月たっても手も足もでないケースも少なくない(平均的な人は生産性の高い人の助けを借りることになる)。本当に奇妙な挙動を見たとき、平均レベルのエンジニアでは、どうやって調べたら良いかも検討もつかないこともあるからだ。

開発中に出くわす難易度の高い問題を解決する能力が生産性に大きく影響するものだ。

新PC

最近家族にパソコンを購入した。購入のポイントは3点。

である。

最低限のスペックはほとんどのモデルがクリアしてる。値段で日本のメーカは選択肢から外れた。高い。デザインは、モデル次第。ここが差が一番出る。結局一番のポイントはデザインだ。

ちなみに、日本のメーカー製は壊れにくいという印象はあるし、恐らく多少は壊れにくいのだと思うが、所詮使ってる部品は大差ないはずで、際立って壊れにくいなんてことがあるはずがない、と思ってしまう。同じ日本製でも海外でもの凄く売れてる車とその辺は違うところ。車だけじゃなく、ほとんどの日本の家電も海外で売れてると思うし、進んでると思う(サムスンにはやられてるが)。
その辺の家電がPCと違うのは、ユーザインターフェイスだろう。テレビや他の家電は基本独自のユーザインターフェイスだが、PCはそうでない。

PCは結局部品からユーザインターフェイスまでほとんど同じ。勝負のポイントはデザインしかもはやないだろう。スマホも状況は同じ。最低限のスペック、値段、これを満たしたら、後はザインで全ては決まるだろう。
当然Appleはこの限りではないが。

書感「突き抜ける人材」

「突き抜ける人材」を読んだ。

http://www.amazon.co.jp/突き抜ける人材-PHPビジネス新書-波頭-亮/dp/4569801862

安直に言ってしまえば、閉塞感漂う日本の現状、およびそれを打破するイノベーションを起こせる人材、能力について述べている本だ。多いに同感する部分が多い。
が、結局ある程度幸せな日本を、そこまで問題だと感じることが難しい今、そういう人材はまだまだ増えにくいかなと。
本書にあった下記記述がある。


重い病気を経験したことで、生きてることの有り難さを感じましたし、その結果として
出世や金儲けの優先度がずいぶん下がったと思います。
...
私の場合に限らず、病気などで死を意識したことで、このような気持ちに目覚めた人は
少なくない気がします。

突き抜けるには、強い気持ちに目覚めないと駄目なのかなと。日本を変えないといけない!と思う必要があるのかなと。そのきっかけが病気だったりするのかなと。

何かを変えるには、それに不満を覚えることは必要。
日本に対して、一般人がそのレベルに達するにはもう少し時間が必要。まだそのレベルにない。
日本がさらに腐敗すれば、その時間は短くなるが、逆に粘ると遅くなる。

結局、本当に駄目になったら改革しようとすればいいだけで、本当に駄目にならなければ改革はいらない。その「本当に駄目になった」と感じる基準は人それぞれで、今は一部の人だけ感じ、一部で小さな変化は起きている(予想)。これが日本の半数、または大多数?を占めたら、改革が起こる(これも予想)。

改革が必要だと感じてる人、賛同する人の数によって、改革の影響範囲が決まる。それが一定数を超えたところで、第二次日本維新が起きる。

以上、本書を読んで思ったところ。

I/O 仮想化について

IntelR Virtualization Technology for Directed I/O

の覚書。

I/O Virtualization のモデルとして、以下 4つが挙げられている。
下にいくほど、進化したモデルといえる。

  • Emulation:

VMM が物理デバイスを仮想デバイスとして VM に見せること。VMM が物理デバイスをエミュレーションする。

  • New Software Interfaces:

VM 上の OS が VMM が提供している I/F を介して物理デバイスを制御する。I/F 分多少のオーバーヘッドはあるが、エミュレーションほどではない。VM 上の OS が、その I/F をサポートしている必要がある。

  • Assignment:

VMM が物理デバイスVM に割り当て、VM 上の OS が直接物理デバイスを制御する。ただし、VM が他 VM に影響を及ぼさないよう物理デバイスの制御をするには、専用のハード機能が必要。デバイス自身にではなく、PCI Express でいうところの Root Complex に必要。オーバーヘッドはない。

  • I/O Device Sharing:

物理デバイスを複数の VM 間で共有し、VM 上の OS に直接デバイスの制御を許可する。物理デバイスは、Multiple Function をサポートしている必要あり。(PCI Express の SRIOV の VF のようなもの)


所感:
IO 仮想化の目指すところは、VM への Native IO 割り当てを、安全に、柔軟に、だろうか。後は結局性能向上が課題か(つまり問題は仮想化にはない)。
一般コンピュータはオフィス用のみとなり、他は Appliance と化すか。

FlexMigration

Intel 仮想化技術を眺めてたら Intel VT FlexMigration なるものに出くわしたので調査した。

まずはそれが何かを知るために、下記ドキュメントの 1.1 Overview と 2.1 CPUID Virtualization and a Live Migration Compatibility pool を読んだ。詳しいことはまた次回。
Intel Virtualization Technology FlexMigration (Intel VT FlexMigration) Application Note

関連技術を一通り知ってる人向けには、
「FlexMigration 機能は VMM に CPUID 命令を仮想化する機能を提供する」
で何のことか十分わかるかなと。一応もう少し具体的に以下述べる。

Intel VT FlexMigration とは名前の通り Intel VT 機能の一部(ハードウェアによる仮想化支援機能)。
Guest OS に Processor がサポートする機能を化かして見せれるようにする機能。目的は、異なる世代の Intel プロセッサ間でのライブマイグレーションを容易にすること。簡単にいうと、マイグレーション元と先で Processor がサポートする機能を同一に見せて、マイグレーションしたら元々使えてた機能が使えなくて Guest OS が発狂した、なんて状況を避けましょうという機能。

解決しようとしている問題の例はこんな。


P1 と P2 という Processor が 2つあるとする。
- P1 は機能 X をサポートする。
- P2 は機能 X をサポートしない。

P1 で機能 X を使用していた Guest OS を P2 に Migration させる。
Migration は成功した。
が、P2 に Migration 後、Guest OS は機能 X の使用しようとして、
OS が発狂した。

通常、プロセッサの機能はブート時に OS が確認する。よってライブマイグレーションだとそのチャンスがないまま動きだす(OS は自分が移動したことさえ知らない)。なのでこの例だと Guest OS は P1 上の機能 X をそのまま P2 上で使おうとする。

この機能を使うための前提としてあるのは、マイグレーション先の候補は元々わかっているはず(元と先の機能の差は事前に知っているべき)という点。この例では P1 の Guest OS を P2 に移動させる可能性は元々わかっていたはず(知っておくべき)。それなら、機能 X をそもそも P1 で使用しないようにしておく、という選択もありえる。その選択を可能にするのが FlexMigration 機能。
機能を無効にするなんて、ありえないだろ。。。っと一瞬感じたかも知れない。確かに重要な機能を無効にするのはありえない。が、その場合、その重要な機能をサポートしないプロセッサへのマイグレーションもありえない。重要じゃないが OS が勝手に使ってる Processor の機能は、使わせないようにしておこう、ということだ。

x86 CPU は CPUID 命令によってソフトはサポートされている機能知ることができる。つまり、FlexMigration 機能は VMM に CPUID 命令を仮想化する機能を提供する、ということだ(冒頭で述べた繰り返し)。

最近リンカを勉強中。

ということで、「リンカ・ローダ実践開発テクニック」*1を読んで自分の理解を綴る。

まず基本的なことから書いておく。ELF の構造は以下になっている。


ELF のフォーマット
+--------------------------+
| ELF Header |
+--------------------------+
| Program Header | --> Segment に関する情報
| ------------------------ |
| |------+
| ------------------------ | |
| |----+ |
| ------------------------ | | |
| ... | | |
| ------------------------ | | |
| | | |
+--------------------------+ | |
| Segment |<-----+
|+------------------------+| |
+--->|| Section || |
| |+------------------------+| |
| |+------------------------+| |
|+-->|| Section || |
|| |+------------------------+| |
|| | ... | |
|| +--------------------------+ |
|| | Segment |<---+
|| | ... |
|| +--------------------------+
|| | Section Header | --> Section に関する情報
|| | ------------------------ |
+----| |
| | ------------------------ |
+---| |
| ------------------------ |
| ... |
| ------------------------ |
+--------------------------+



ELF はいくつかのヘッダ情報と、Section の塊からなる。
さらに、1 つ以上の Section の集合として、Segment なるものも存在する(Section は必ずしも Segment に属するわけではない)。

Segment

  • Segment に関する情報は Program Header に格納されている。
  • Segment は Section から構成される。
  • Segment はローダによってロードされるときに利用される。

Section

  • Section に関する情報は Section Header に格納されている。
  • Section は必ずしも Segment に含まれている必要はない。
  • Section はリンカによってリンクされるときに利用される。


今日の一番の収穫は、Segment はロード用、Section はリンク用であるということ。

*1:http://www.amazon.co.jp/リンカ・ローダ実践開発テクニック―実行ファイルを作成するために必須の技術-COMPUTER-TECHNOLOGY-坂井-弘亮/sim/4789838072/2

ベクター割り込みの仮想化について

説明も自分の理解もまだイマイチだが、現時点でのベクター割り込みの仮想化の理解を綴る。逐次改善予定。
VMX operation により、ゲストドメインはそれぞれ自分の IDT を操作できる。仮想化という視点から考えると、ゲストドメインが受ける割り込みには下記 2種類ある。

  • Interrupt from virtual device

名前の通り。仮想デバイスから受ける割り込み。VMM が割り込みを受信し、VMM 上のデバイスドライバが仮想デバイスをエミュレートする。必要に応じて(?)、ゲストに割り込みを VM Entry としてあげ、ゲストドメインに存在する仮想デバイスドライバがそれを処理する。


-------------------------------------------------------------------
VM
+---------------------------+
| ドライバ for 仮想デバイス |
+---------------------------+
^
|
| Guest IDT からベクタを使用して ISR を選択
|
+-----------------+
| 割り込みを受信 |
+-----------------+
^
|
----------------------|-------------------------------------------
VMM | 割り込みを inject (VM entry)
+-------------------------------+
| ドライバ for デバイス A |
|(仮想デバイスをエミュレート) |
+-------------------------------+
^
|
| Host IDT からベクタを使用して ISR を選択
|
+-----------------+
| 割り込みを受信 |
+-----------------+
^
|
----------------------|--------------------------------------------
HardWare | 割り込み発生
+-----------------+
| Device A |
+-----------------+

-------------------------------------------------------------------

  • Interrupt from assigned physical device

物理デバイスから受ける割り込み。VMM が割り込みを受信し、そのままゲストに割り込みをあげる。VMM ハンドラと便宜上呼んでいるが正式になんと言うべきか不明。


-------------------------------------------------------------------
VM
+---------------------------+
| ドライバ for デバイス B |
+---------------------------+
^
|
| Guest IDT からベクタを使用して ISR を選択
|
+-----------------+
| 割り込みを受信 |
+-----------------+
^
|
----------------------|-------------------------------------------
VMM | 割り込みを inject (VM entry)
+-------------------------------+
| VMM ハンドラ |
+-------------------------------+
^
|
| Host IDT からベクタを使用して ISR を選択
|
+-----------------+
| 割り込みを受信 |
+-----------------+
^
|
----------------------|--------------------------------------------
HardWare | 割り込み発生
+-----------------+
| Device B |
+-----------------+

-------------------------------------------------------------------

つまり違いは、本当のデバイスのドライバが、ホストにいるか、ゲストにいるか。