OS Awareness
Simics OS awareness は、Simics のターゲットシステムで実行されている OS のデータ構造と抽象化を理解する Simics モジュールです。 OS 意識により、Simics と Simics デバッガーはカーネル空間、ユーザー空間、プロセス、スレッド、およびタスクについて知ることができます。
Fundamentally, OS awareness perform the two tasks: live tracking of events as they happen, and investigating the instantaneous state of the operating system. イベントのライブ追跡とは、オペレーティング システムがタスクスイッチを実行したとき、ソフトウェアがシステム コールを実行したとき、または割り込みが発生したときに、OS アウェアネスが検出することを意味します。 実際、このようなイベントを検出する最も一般的な方法は、ターゲットシステムで割り込みを待つことである。割り込みが発生しない限り、同じユーザーレベルのソフトウェアが実行されていることになる。 割り込みが発生すると、オペレーティングシステムに引き継がれ、実行中のプロセスは切り替わったとみなされる。 オペレーティング・システムがユーザー空間に戻ったとき、あるプロセスがスイッチ・インされたと見なされます。
ライブ・トラッキングは、何かが起こったときに決定しますが、何が起こったかを決定するには、オペレーティング・システムの瞬間的な状態を調査する必要があります。 たとえば、割り込みがトリガーされたとき、その割り込みを受けたプロセッサ上のアクティブなスレッドは何なのか。 それを判断するために、OSアウェアネスは、実行中や待機中のプロセスのOSキューの構造、タスク構造体やプロセス制御ブロックの内容、その他のデータ構造などを知る必要があります。 これが正しく構成されていれば、OS アウェアネスはターゲット メモリ内のリストを走査して、特定のプロセッサ上で現在アクティブなプロセスの名前、すべての既存プロセス、動的にロードされたソフトウェア モジュールとその再配置アドレス、および関心のあるその他のものを判断することが可能です。 ほとんどの場合、OS ビルドからのデバッグ情報を含むシンボル・テーブルまたはカーネル・ファイルを見ることにより、OS アウェアネス用のパラメータを決定することが可能です。 しかし、実行時まで正確なパラメータを決定できないOSもあり、その場合はターゲット・システムが起動するまで設定を待つ必要があります。 いずれにせよ、一度決定したパラメーターのセットは保存でき、次に同じターゲット設定を実行するときに使用できます。
パラメーター ファイルの使用により、OS 認識設定を、それが参照する OS イメージと一緒に配布することが可能になります。 これは、プラットフォーム・チームが OS イメージを構築し、それに対して OS アウェアネスを構成し、パラメータを保存し、シンボル・ファイルまたはデバッグ情報を提供しなくても、OS とその OS アウェアネス・パラメータをユーザーに提供できることを意味します。 OS認識パラメータファイルは、単に提供されるソフトウェアスタックの一部であり、Simicsの起動に使用されるスタートアップスクリプトでアクティブ化されます。 システムのユーザーは、OS認識機能の設定方法を知る必要はなく、提供されたターゲットシステムのセットアップを開始するとすぐに動作するようになるだけです。 OS awareness パラメーターは Simics チェックポイント ファイルの内部にも保存されるので、OS awareness はチェックポイントの保存と復元操作にわたって機能し続けます。
OS awareness は、特定のプロセス内部のみに設定されるブレークポイントや、ユーザーレベルのタスクではなくカーネルによって実行されるメモリアクセスのみを追跡するなど、ソフトウェアスタックの特定のサブセットのみで動作する Simics 機能を持つことを可能にします。 ユーザーが書いたSimics拡張機能またはスクリプトは、OS認識からのイベントを聞き、ターゲットシステムで現在実行されているソフトウェアに基づいたアクションを取ることができます。 OS awareness システムに特定のプロセスだけの通知を求めることも、すべてのプロセスのすべてのアクションを見ることも可能です。
Simics の OS awareness システムは、ノードツリーの概念で動作します。 ツリーの各ノードは、OSプロセスモデルにおける抽象化レベルを表します。 通常、 トップノードはオペレーティングシステムそのものであり、 その後、 カーネルレベルとユーザーレベルのタスクに分割されます。 LinuxのようなOSでは、各ユーザーレベル・タスクは1つ以上のスレッドを含んでいます。 カーネルでは、OSの意識は通常カーネル・スレッドをアイドル・タスクと区別し、それが目標実行時間を説明するのに役立つからです。 図3.3は、ベアボーンLinuxシステムからのノードツリーの例です。
Figure 3.3。 OS awareness tree.
Simics CLIおよびデバッガーGUIでは、プロセスクエリーは関心のあるプロセスを見つけるために使用されます。 これらのクエリは、プロセス名、プロセス ID 番号、または OS アウェアネスによって利用可能になった他のプロパティに一致させることができます。 ほとんどの場合、プロセスの名前で十分識別できますが、複雑なシステムでは、”bar という名前のボード上の foo という名前のプロセス” のような、より複雑なマッチングが必要になります。 あるプログラムが何度も実行されるような長時間稼働のシステムでは、プロセス ID を使用して特定のプロセスの開始を識別することができます。
Simics OS awareness では、ハイパーバイザーを使用したシステムの OS awareness を処理するために、ネストされたオペレーティングシステムをサポートしています。 ハイパーバイザーを使用するシステムでは、ターゲット プロセッサ コアのゲスト OS のスケジューリングを追跡する必要があります。 コア上でアクティブなオペレーティングシステムが決定されると、そのオペレーティングシステムのOS認識を適用して、アクティブなプロセスまたはスレッドを決定することが可能になります。 OS 意識がターゲット ソフトウェア スタックについて追跡および発見できる内容の詳細は、ゲスト オペレーティング システムおよびそのための OS 意識の構築に費やした作業量によって異なります。 このような機能は、大きなオーバーヘッドが発生し、ハードウェア ブレークポイントの可用性を圧倒するため、ハードウェア ベースのデバッガに実装することは現実的でないことが証明されています。 瞬時状態の検査は、ハードウェアデバッガーがシステムを停止した後にシステム状態を検査するのと本質的に同じであり、実際、ハードウェアデバッガーに使用されるのと同じコードが Simics で使用されて、動的にロードされたモジュールの再配置アドレスなどの事実を決定しています。