前回は、システム仮想マシンを実現するための条件、その古典的な実装方法を紹介しました。また、それらのアプローチをx86システムに適用する場合、どのような障壁があるかについて説明しました。 今回は、従来のx86プロセッサにおける仮想化の問題点を解決するために追加された“⁠仮想化支援機能⁠”がどのようなものであるかを紹介します。 仮想化支援機能の概要 x86プロセッサの仮想マシンソフトウェアの実装が困難だった中、プロセッサを供給するインテルおよびAMDは、プロセッサ自体に仮想化支援機能を追加しました。それが、インテル製のプロセッサに搭載されたIntel VT-x、およびAMD製のプロセッサに搭載されたSVMです。 リング0で動作するOSをも支配するVMM専用モード 前回解説したtrap-and-emulateによるシステム仮想マシンを実装するためには、仮想マシンモニタ（VMM）が、ゲストOSのカ

これまで、x86システム仮想マシンの概要、およびその実例としてDebian GNU/Linux 6.0を利用した仮想マシンの実行方法について紹介してきました。今回からは、より具体的にCPU、メモリ、I/Oデバイスの仮想化がどうやって実現されているかを解説したいと思います。 今回は、仮想マシンを実装するための古典的手法およびそれを従来のx86プロセッサに適用する際の問題点、そして仮想マシンソフトウェアがどのようにそれらの障壁を乗り越えてきたかについて解説します。 システム仮想マシンに求められる条件 これまで、システム仮想マシンはどのようなものかについて説明してきましたが、仮想化仮想化の生みの親とも言えるGoldbergらは、1974年に書いた論文にて、仮想マシンソフトウェアとはどのようなものであるべきかについて、コンピュータアーキテクチャの観点から論じています。 彼らは、その仮想マシンソフト

ARMはスマートフォン・携帯電話で広く使われていますが、クロック周波数の割に微妙にIntelのCPUよりも遅く、なんでなのかなーということで調べてみました。 まず、http://www.coremark.org/benchmark/index.php のベンチマークの結果から、色々数字があり、すごく悩みながら信用できそうな数字を拾ってみました。 1コア当たりの性能 名称 性能 備考 ARM Cortex-A8 600Mhz 2.035/MHz Cortex-A8は2010年のスマートフォンの主流 NVIDIA Tegra 250 1GHz 2.646/MHz Cortex-A9は2011年のスマートフォンの主流かな？ Intel Core2 Duo 1596MHz 3.205/MHz Intel Core i5-650 3200MHz 3.244/MHz このように、クロック当たりの性能が

Sandy BridgeのGPUコア「HD Graphics 3000＆2000」には，どこまで期待していいのか Core i7-2600K/3.40GHz Core i5-2500K/3.30GHz （Intel HD Graphics 3000） Core i7-2600/3.40GHz （Intel HD Graphics 2000） Text by 宮崎真一 単体グラフィックスカードを組み合わせる前提で行ったレビュー記事で筆者は，「Sandy Bridge一択」と評した。それほどまでに，Sandy Bridgeと呼ばれていたLGA1155パッケージ版Core i7＆i5プロセッサの上位モデルには性能面でのインパクトがあったわけだ。 i7-2600K 一方，Sandy Bridgeにおける最大の特徴が，「CPUコアとグラフィックスコア，ノースブリッジ機能がシングルダイに統合されている

図1.20に見られるように、電源電圧を下げるとクロックも下げざるを得なくなる。しかし、プロセサのやるべき仕事が少なく、クロックを下げて処理速度を落としても十分間に合うという状態では、電源電圧と動作クロック周波数をつり合いのとれた形で下げてやると、大幅に消費電力を減らすことができ、電源電圧を20%下げると消費電力はほぼ半減する。このように処理負荷に応じて電源電圧とクロック周波数を変えるのがDynamic Voltage Frequency Scaling(DVFS)という方法で、マイクロプロセサとしては、今は亡きTransmetaのCrusoeで最初に採用され、その後、多くのプロセサで採用が広がっている省電力手法である。 そして、最後に残るパラメタがαである。前に、αが小さくなる理由としてプロセサが浮動小数点演算器は使っていないというケースを挙げたが、実は、使っていない=電力を喰わないという

キャッシュの仕組み解説編最後のテーマは、「コヒーレンシ」(Coherency)である。あまり耳にしない単語だが、直訳すると「首尾一貫性」といったところか。キャッシュの場合、この単語は「データの一貫性」「データの整合性」といった意味合いで利用される。これは、前回触れた複数レベルのキャッシュで問題となる場合もあるが、一番大きな問題が起きるのは、マルチプロセッサー/マルチコアCPUの環境である。 マルチプロセッサー環境でキャッシュの整合性を保つ スヌーピングとその方式 例えば図1のような、懐かしいデュアルCPU構造を例にとって見る。ここで「CPU #1」があるデータを書き換えたとする。 すると、図2のように1次/2次キャッシュの更新を経て、最終的にメモリーにそれを反映して終わる。ここまではいい。問題は「CPU #2」である。もしCPU #2が同じアドレスのデータをすでにキャッシュしていたとすると

前回までに、CPUには複数のキャッシュが搭載されていることを説明した。今回はそのキャッシュをどう制御するか、という話をしよう。 3階層のキャッシュのどこにデータを置くか？ 例えば図1のように、1次～3次までキャッシュを持つCPUを考えてみる。ここでCPUがデータ(命令でもいい)のフェッチを掛けた場合、まずは1次キャッシュのタグを検索する(図1-①)。ここで見つかれば問題なく、単に1次キャッシュからそのデータを引っ張ってくる(図1-②)だけでいい。問題は1次キャッシュにデータがなかった場合(キャッシュミス)である。

仮想アドレスと物理アドレスを変換する Address Translationの基本 前回はメモリーの階層構造と同様に、複数段階のキャッシュ構成があることを説明した。今回はちょっと見方を変えた話をしたい。まず、キャッシュという形でCPU内部に搭載されている、別のメモリーについて触れよう。 ご存知の通り、1次キャッシュは通常「ハーバード・アーキテクチャー」と呼ばれる構造に基づき、命令用とデータ用がそれぞれ別に用意される。詳細は後述するが、2次キャッシュや最近では3次キャッシュを搭載するプロセッサーも多くなった。ただ、これらはいずれも「プログラムそのもの、およびプログラムの実行時に利用されるデータ」である。 「ではそれ以外に何かあるのか？」と言われると、これが結構ある。一番多く利用されるのが「TLB」(Translation Lookaside Buffer)と言われるものだ。これは「仮想記憶」

引き続き今回もキャッシュの話である。前回はキャッシュにデータを取り込み、それをタグで検索するところまでを解説したが、今回はその先のことを考える。 新しいデータでキャッシュを入れ替える 「リフィル」の方式 プログラムや利用するデータが非常に小さくて、(OSまで含めて)全部オンキャッシュで動くなんて場合は問題ない。例えばMS-DOSであれば、OSそのものは100KB前後で動くし、簡単なプログラムであればライブラリやデータまで含めても100KB未満、なんてことも少なくない。 こうした小さなプログラムなら、2次/3次キャッシュまで含めれば、数MBのキャッシュ容量を持つ昨今のプロセッサーなら、最初だけメモリーアクセスしたあとは、全部オンキャッシュでも動作する。しかし、昨今のOSは流石にこんなものでは済まないし、アプリケーションだって数10MBを軽く超えるものが普通だから、当然キャッシュには入りきらな

CPUの高速化についていけないメモリーの速度 今回からはちょっと趣を変えて、「キャッシュ」の話である。キャッシュの目的は「レイテンシの遮蔽」にある。といきなり大上段に構えても話が通じないので、昔話から始めよう。 初期のPCの場合、図1のようにCPUとメモリーが直結(厳密に言えばメモリーコントローラーを介する)されていた。初期というのは、おおむねi386ないし互換チップセットが利用されていた頃までの話である。 この頃は、CPUの速度が速くても30MHz程度。対するメモリーチップの速度は100ns(10MHz)～80ns(12.5MHz)程度。たまに70ns品(≒14.3MHz)や60ns(≒16.7MHz)品が高値で販売されるという、ある意味のどかな時代であった。 もちろん、これでもCPUの速度には追いついていないが、例えば2～4ウェイ・インターリーブでアクセスすれば、40～50MHz相当で

仮想化と入出力 仮想化を行う場合のもう1つの大問題は入出力(I/O)である。単純に普通のOSをゲストOSとして動かすと、それぞれのゲストOSがI/Oを占有していると思って、自分のデバイスドライバでI/Oハードウェアを制御してしまう。これでは、I/Oの動作は滅茶苦茶になってしまう。 基本的な解決方法は、VMMにI/Oデバイスのソフトウェアモデルを持ち、ゲストOSはI/Oデバイスの制御レジスタを読み書きしてI/O動作を行っているつもりであるが、ユーザ状態での制御レジスタの読み書きは特権違反となり、VMMのソフトウェアモデルがゲストOSの指令を変換して、整合の取れた形で実I/Oデバイスを動かすという方法である。 原理的にはこれで良いのであるが、各種のI/Oデバイスに対してそのデバイス専用のデバイスドライバを騙すほどそっくりで、かつ、矛盾なく複数のゲストOSからのI/O処理をサポートするソフトウェ

IPCの引き上げは難しい シンプルな解決策がCPU数の増加 今回のテーマはマルチコアである。もともとコンピューターの世界では、CPUのコアをいっぱい並べるという技法は、非常に一般的であった。66回でも書いたが、CPUの処理性能は以下の式で表わされる。 P＝F×IPC PがPerformance(処理性能)で、FがFrequency(動作周波数)、IPCは「Instructions Per Cycle」(1サイクルあたりの処理命令数)となる。Pを引き上げるためには、Fを上げるかIPCを上げるかになるが、Fを上げると同時に消費電力も増えることになり、ある程度以上の動作周波数以上に引き上げるのが放熱の観点から困難、という制約があった。 一方IPCを引き上げるのはもっと難しい、というのはここまでの連載で紹介したとおり。いろいろな策を講じてIPCを引き上げようとしているが、それでもなかなか上がらない

ゲストOSが実行するアプリケーションが新しいページを要求したり、ユーザ状態で実行するアプリケーションを切り替えるとゲストOSのページテーブルが変わり、それに対応してVMMはシャドーテーブルを書き換えなければならない。ゲストOSのページテーブルは普通のメモリ上にあるので、その書き換えを検出するため、ページテーブルを格納するメモリ領域を書込み禁止にして、ゲストOSがページテーブルのエントリを書き換えようとすると、特権違反が発生してVMMに制御が渡るようにする。そして、VMMは、この書き込みのアドレスを自分のページテーブルで再度変換して物理アドレスに変換してシャドーテーブルに書き込むという処理を行うので、書き換えの頻度にもよるが、一般的に、このゲストOSのページテーブルの書き換えにシャドーページテーブルを追従させる処理のオーバヘッドが、VMMの主要なオーバヘッドの1つとなっている。 この問題を解

まずはSMTを理解するための基本 プロセスとスレッドの関係 今回は「SMT」(Simultaneous MultiThreading、同期マルチスレッディング)の話をしてみたい。インテルではこれを「Hyper-Threading」と呼んでおり、以下では一般論の場合にはSMT、インテル製品に関する話題ではHyper-Threadingと、それぞれ称することにする。このSMTの技法はここ5回に渡って説明してきたパイプラインの改良そのものとは、ちょっと異なる方法論である。 例えば、図1のようなデュアルコアCPUを考えてみよう。2次キャッシュがコア別に異なるのは、インテルの「Pentium D」やAMDの「Athlon 64 X2」「Athlon X2」など、共有なのが「Core Duo」以降のインテルのCoreマイクロ・アーキテクチャー製品になる。だが、この話では2次/3次キャッシュはあまり問題

仮想マシンモニタ 図10.8に示すように、通常のプログラム実行環境は、スーパバイザ状態で実行されるOSがハードウェアを制御し、ユーザ状態で実行されるアプリケーションはOSのサービスを使って特権命令でしか操作できないハードウェアを動かすという階層構造になっている。 ユーザ/スーパバイザ機構を持つプロセサで、通常のOSをアプリケーション状態で実行すると、そのOSが特権命令を実行しようとすると、特権違反の例外が発生する。これをスーパバイザ状態で実行する管理プログラムが受け取り、必要な動作をソフトウェアでシミュレートして実行し、あたかもOSの発行した特権命令が実行されたようにして例外から復帰させれば、処理時間は別として、OSとしては自分が実ハードウェアを操作しているのと同じように動作することができるはずである。 このようにしてユーザ状態で実行されるOSをゲストOSと呼び、スーパバイザ状態で動作する

x86に限ってだが、アウトオブオーダーで欠かせないのが命令変換の仕組みである。インテルの場合は「μOp」(マイクロオプ)、AMD(というか旧NexGen)は当初「RISC86」と称し、その後「Op」、最終的には「microOp」と表記は変わっているが、要するにx86命令を「RISC風の」内部命令に変換する仕組みである。この内部命令が、μOpとかmicroOpなどと呼ばれるわけだ。 ここでちょっと寄り道して、RISCとCISCの話をしておくことにする。例えばx86という命令はCISCの代表例であるが、そもそもRISCとCISCの違いとは？　というところを簡単に説明しておこう。 RISCとCISCの違いをざっとおさらい RISCという概念を、それと明確には知らずに搭載したCPUはかなり昔からある※1。だが、RISCという概念が明確になったのは、1981年にデビッド・パターソン(David Pa

プロセサ本体と比べると著しく速度の遅いI/Oの動作完了や、キーボードや通信インタフェースからの入力の到着のように、プログラム中の命令の実行と非同期に発生する事象を処理するために割り込みという方法が使われる。 割り込み処理機構は、当初は、このようなプロセサの外部から入力される事象を処理する目的で設けられたが、その後、前記の特権違反や、ゼロでの割り算などのプログラムの実行に伴ってプロセサ内部で発生する異常な事象に対処するためにも用いられるように拡張されてきている。そして、これらを総称してトラップ(Trap)という名称が使われる。また、外部からの事象と内部からの事象を区別する場合は、外部からのものを割り込み(Interrupt)、内部からのものを例外(Exception)と呼ぶ。 プロセサに割り込み信号が到着すると、割り込み処理機構は、プログラムカウンタやキーとなる若干のハードウェアレジスタを退