Cortex-A15で登場するARMの仮想化サポートと物理アドレス空間拡張

AppleのiPadに使われているA4プロセサは、「ARMv7-A」という命令アーキテクチャのプロセサであるが、2010年9月8日にARMが発表したCortex-A15コアには、このARMv7-Aに2つの主要なアーキテクチャ拡張が追加されている。

このアーキテクチャ拡張の目玉は，

1. 仮想化のための機能拡張
2. 物理アドレス空間の拡張

である。

このアーキテクチャ拡張については、Cortex-A15コアの発表に先立ち、8月23日のHot Chips 22で発表が行われた。

現在のARMv7-Aでは、プロセサの状態は通常のアプリケーションプログラムを実行する非特権のユーザモードと特権のスーパバイザモードがある。スーパバイザモード以外にも割り込みの処理などを行う例外モードなども特権状態であるが、ここでは省略する。今回の拡張ではこれらに加えてVMM(Virtual Machine Monitor、あるいはHypervisor)を走らせるHypモードが追加された。

Hypモードで使えるレジスタとして、ゲストOSのハードウェア操作などVMMが捕捉してエミュレーションすべき事象とその割り込み原因の詳細を示すSyndromeレジスタが追加されている。これにより、VMMが割り込み原因を解析して必要な仮想化操作を行うまでに必要となる処理時間が短縮できる。また、VMMから復帰するアドレスを保持するException Linkレジスタが設けられ、専用のERETという命令が設けられ，VMMからの復帰を高速化している。また、VMMは各ゲストOSの物理アドレスから本当の物理アドレスへのアドレス変換を行う必要があるが、このアドレス変換テーブルの先頭アドレスを指定するHTTBRレジスタが設けられている。

そして、今回のアーキテクチャ拡張で、アプリケーションの仮想アドレスを各ゲストOSが"物理アドレスと思っている"アドレスに変換した結果をVMMのページテーブルを使って再度アドレス変換を行って"本当の"物理アドレスを生成する機構が追加された。

この二重のアドレス変換はIntelの「Extended Page Table」やAMDの「Nested Page Table」サポートと基本的には同じ機能であり、仮想化にともなうアドレス変換のオーバヘッドを大幅に削減することができる。

一方、IntelやAMDはVMMとゲストOSのシステムコンテキストを一括して入れ替える命令を持ちVMM-ゲストOSの切り替え時間を短縮しているが、このARMの仮想化サポートはVMMへの出入り口を、多少、高速化する程度で比較的軽い仕様となっている。

また、もう1つの目玉が40ビット物理アドレスへの拡張である。従来はページテーブルのディスクリプタが32ビットであったが、今回、32ビット以上のアドレスを記述する必要があることからディスクリプタのサイズが64ビット(8バイト)に拡張された。そのため、4KBのページに格納できるディスクリプタの数が512個の半減している。

この図に示すように、アプリケーションやゲストOSが使うことができるアドレス空間は32ビットで従来から変わっていないが、ゲストOSの生成するゲストOS物理アドレスは40ビットに拡張されている。

端的に言うと、各OSやアプリが使えるメモリ空間は従来と変わらないが、拡張された8ビット分の256個のゲストOSを同時に動かしても問題ないサイズの物理メモリをサポートできるようになったということである。

そして、VMMが行う第2レベルのアドレス変換テーブルのエントリは次の図のようになっている。

従来の32ビット物理空間の場合は、2レベルのアドレス変換で済んでいたが、物理アドレスを拡張したので、次の図のように3レベルのアドレス変換が必要となっている。

気になるのは、第1レベルの仮想アドレスからゲストOS物理アドレスへの変換を行うページテーブルエントリの8バイト化とそれに伴う形式の変更である。このページテーブルはゲストOSが管理するテーブルであり、これが変わるということはOSのメモリ管理のコードに何がしかの修正が必要となり、これまでのOSはそのままではゲストOSとしては動かないということになる。この点は、IntelやAMDの仮想化が、従来のOSをそのままゲストOSとして動かすというものであるのと大きく違っているところである。

4バイトのテーブルのままでは綺麗な形での40ビット物理アドレスへの拡張は不可能であるが、ゲストOS物理空間は32ビットのままとして、OSの互換性を保つ方法も考えられる。しかし、これは遠からずアプリ空間の拡張が必要になると考えると、姑息な手段である。

また、ARMプロセサの場合は、WindowsやLinuxのように一般ユーザがOSをインストールすることは少ないので、思い切って過去のしがらみを断ち切り、将来を見据えた拡張を行ったのだと思われる。

そして、仮想化を行った時に、もう1つ問題になるのがI/Oのドライバである。I/Oの制御レジスタのアドレスはVMMのアドレス変換で吸収できるが、ゲストOSのドライバは、自分が思い込んでいるゲストOS物理空間のアドレスをI/O側のDMAのターゲットアドレスとして設定してしまう。これでは正しい物理アドレスへのデータ転送ができない。このため、x86ではI/Oハブチップに、DMAのターゲットアドレスをゲストOS物理空間のアドレスから本当の物理アドレスに変換してメモリにアクセスするためのアドレス変換機構を設けている。

これに相当するものとして、今回の拡張アーキテクチャとしてはDMA用にSystem MMUという機構を設けている。DMA機構はゲストOSのデバイスドライバから指示されたゲストOS物理アドレスにデータ転送を行っていると思っているのであるが、このSystem MMUがゲストOS物理アドレスを本当の物理アドレスに変換してしまうので、正しい物理アドレスにDMA転送が行える。

このSystemMMUのアーキテクチャ仕様は2011年前半に公開予定であり、さらに、AMBA仕様に組み込んでいく考えであるという。

全体として仮想化もアドレス拡張もx86よりは軽めの仕様という印象であるが、ARM CPUコア自体がx86 CPUより軽めであり、バランスは取れていると思われる。携帯デバイスのメモリもGBになるのは時間の問題だし、機能の急拡大から、マルチゲストOSが必要というのも理解できる。

一方、9月8日の発表で示されたかなり大規模なキャッシュコヒーレントなマルチコアシステムのサポートは、サーバなどのハイエンドの機器への進出を目指したもののように感じられる。そして、アドレス拡張や仮想化のサポートは、サーバ市場向けとしては不可欠な機能である。その点では今回のアーキテクチャ拡張は、一石二鳥である。今後、ARMがサーバ市場に切り込んでいくのか、あるいはIntelやAMDがARMの挑戦を退けて市場を守るのか、この先のサーバ市場がどうなっていくのか興味深いところである。