Windows system >> Windowsの知識 >  >> Linuxシステムチュートリアル >> Linuxチュートリアル >> 仮想マシンのGUEST OSクロック(TIMEKEEP)の問題についての説明

仮想マシンのGUEST OSクロック(TIMEKEEP)の問題についての説明

  

従来のオペレーティングシステムにおけるクロック同期の概念の説明

システムのハードウェアにRTC /PIT /HPET /ACPI PM TIMERがあることがわかりました。 /TSCと他の多くのクロック、これらのクロックはその特性に従って2つのカテゴリに分けることができます:RTC /PIT /HPETのような割り込みの形の周期的なクロック;もう一方はCOUNTERカウンターを持つワンステップインクリメンタルクロック。 TSCなど。両者の違いは、周期的なクロックがハートビート周波数などの割り込みを定期的に送信することによって実現されることです。シングルステップインクリメンタルクロックは割り込みを送信しませんが、ソフトウェアは時間を取得するためにCOUNTERレジスタをアクティブに読み取る必要があります。
したがって、オペレーティングシステムは、定期的なクロックを選択してタイムキーピング用のクロックソースとして使用し、シングルステップの増分クロックをタイムキャリブレーションまたはパフォーマンス統計用に使用します。これはLinuxシステムのウィンドウシステムにも当てはまります。
ここでいうクロック同期とは、システム内の周期的なクロックを、たとえばシングルステップの増分クロックと同期させる必要があるということです。オペレーティングシステムがTIMEKEEPの周期クロックソースとしてRTCクロックを使用し、周波数が100HZ、システムCPU周波数が3000MH、TSC周波数がCPU周波数に等しい場合、すべてのRTC割り込みが発生します(システム時間は1/100秒進みます)。 TSC COUNTERも1/100 * 3000 M増加する必要があります。上記の関係が安定している場合は、システムクロックを同期したと呼びます。
では、なぜTSCとRTCの同期が必要なのでしょうか。オペレーティングシステムのTIMEKEEPプロセスは、頻繁に(少なくともLinuxシステムでは実行されているが、ウィンドウは実行していないかもしれないが)RTCメンテナンス時間を修正するためにTSC時間を使用します。 (例えば、割り込みマスキングなど)失われ、TSCカウンタは時間を失うことなく安定して動作するので、RTCによって維持されるシステムタイミングはTSCタイミングより遅れるので、常にRTCタイミングを較正する必要がある。 TSCのタイミングは一致しています(特定のキャリブレーションアクションについては、Linuxシステムの timer_interrupt
のcur_timerが指す関数timer_tscを参照してください)。

ハードウェアが安定している限り、TSCとRTCのどちらがハードウェアの動作を担当するかにかかわらず、従来の環境におけるオペレーティングシステムは、TSCとRTCは独立して動作しますが、同期する必要があります。 。したがって、同期の問題は従来の環境では問題になりません。

仮想マシンのアナログクロック間の同期
従来の環境でクロック同期が問題にならない場合、仮想環境でのクロック同期の問題は何ですか。
仮想環境と従来の環境で時計によって生成される条件が変わりました。 RTCなどの周期的なクロックは対応するハードウェアによって生成されませんが、ソフトウェアタイマーによってシミュレートされます(前の記事を参照)が、TSCの取得はシミュレーション、またはTSC値を取得するハードウェアのTSC COUNTERレジスタに合格しません。ソフトウェアでは安定したシングルステップTSC COUNTERをシミュレートすることはできないので、シミュレーションはありません。ハードウェアTSCを直接読むのがより簡単で合理的です。仮想環境では、ソフトウェアエミュレーションRTCなどの定期的なクロック割り込みを正確にトリガーしてGOSに送信することはできず(仮想環境に遅延が生じ、トリガー間隔が不安定になる)、RTCタイミングとTSC時間が同期しなくなります(TSC速く走りなさい)。 Linuxシステムでは、出力には「ティックを失いすぎた!」という多くの情報が出力されます(対応するコードは timer_tsc
にあります)。

TSCで周期的なクロックタイミングを修正する必要があるLinuxシステムでは、TSCとRTCを同期させる方法を見つける必要があります。 GOSがTSCを読み取ると(x86システムには特別な命令rdtscがあります)、結果は元の結果(ハードウェアTSC COUNTER)の変更になります。構成可能なオフセット値tsc_offsetの合計なので、GOSから見たTSCのタイミングとそのRTCメンテナンスを同期させるためにtsc_offset値を設定できます。具体的な方法は、各クロック割り込みインジェクション時間(xenのvpt.cのpt_intr_postのステートメントhvm_set_guest_time)でGOSタイミング(RTCメンテナンス)のタイミングに従って新しいtsc_offsetを設定することです(pt-> vcpu、pt- > last_plt_gtime)は作業を完了し、仮想環境でのクロック同期を確実にすることです。

SMP環境での同期
上記の同期はシングルコアシステム用であり、マルチコアSMP環境の同期には、上記の要件に加えて、複数のコアと時間が必要です。同期 - 各コアのTSCは同期する必要があり(各コアには独自のTSCがあります)、TSCとシステムの周期的なクロックは同期する必要があります。
仮想環境でのマルチコア同期には多くの困難があり、コア同期スケジューリングを完全に同期させる必要があります(同時にスケジュールまたは呼び出される)、そうでなければ、定期的なクロック割り込みをコアに送信することが可能です。呼び出されると、明らかにクロック割り込みが失われ、システム時刻が遅れます。 Xenコードに関する限り、現在のところ、システム全体のパフォーマンスを向上させるために、各コアは独立してスケジュールされているので、上述のロストインタラプトの可能性は確かに保存されています。
このxenでは、周期クロックはBSPコアにバインドされています。 APコアはクロック割り込みを受信しないため、Apコアは計時動作を実行しません(計時はクロック割り込みを受信した後に実行されます)ので、システムタイミング動作および校正時間動作は実行されず、エラーは報告されません。ただし、APコアのTSCは実際にはRTCのタイミングと同期していません。
しかし、仮想デュアルコアは2つのコアのTSCの同期を保証できません。多くのパフォーマンステストツール(pcmark、winsatなど)はパフォーマンス測定にTSCを使用するため、多くのパフォーマンステストツールの通常の動作に影響します。これらの攻撃は、仮想デュアルコアの下では低いか使用不可能であることがわかります。この問題は解決されていないか、xenによって深刻な問題と見なされていません。
マルチコアクロックの問題を完全に解決したい場合は、定期的なクロックが中断されたときにipi割り込みをトリガーして対応する同期処理を実行するように通知するなど、多くの補助的な作業が必要です。それはまた凍結するべきです。

概要:
2つの記事では、仮想環境におけるクロックの問題を検討し改善するためのさまざまな場所があります。仮想クロックの実装は、仮想化テクノロジにおける重要なテクノロジポイントであり、システムの全体的なパフォーマンスと安定性に大きな影響を与えます。現在のxenコードにはまだ時計の仮想化に多くの脆弱性があり、興味のある読者が研究を続けることができることを願っています。

Copyright © Windowsの知識 All Rights Reserved