さて、こうしたものよりも大きな変更は、Virtualizationである。

現実に、複数のOSをP4080上で動作させたいというニーズはあるだろう。元々Freescaleの場合、MPC8641/Dで2つのe600をASMP構成にし、それぞれ別のOSを搭載することが理論上可能であったが、これはMMUの設定を行うSupervisorが別途どこかで動作する必要がある、ややトリッキーなImprementだった。流石に8Pともなると、きちんと動作させるための環境が提供される必要があるという事だろう

e500mcは、PartitioningとVirtualization、Hypervisorを搭載する。P4080の様なケースで、8コアが常に同じ仕事をする、というケースでフルにパフォーマンスを引き出させるのは意外に難しい。もちろん、すべてのプロセッサをOSの配下に置いて、ここで作業を振り分ける(いわゆるSMPの)構造ならばこうした問題は生じにくくなるが、

  • OSのオーバーヘッドが発生する
  • 逆に特定のプロセッサに処理を振り分けるといった作業がしにくい

といった欠点もある。そうしたことに対する回答の1つが、H/WレベルのPartitioningやVirtualize、これを管理するHypervisorということになる。

まず最初はPartitioningである。複数のOSを動作させる環境において、個々のOSから見える環境を完全に分離する(Partitioning)事が可能である。それぞれの環境にどんなリソースが見えるか、ということはHypervisorが管理する形になっており、いわゆるGuest OSはそうした環境を意識する必要がない。

ここで注意すべきは"mapped directly to explicit hardware"の一文。12枚目のスライドの構造で、Frame ManagerやOn-Chip Network、その他の周辺機器にIO-MMU(PCI Expressで言うところのATSやSR-IOVに相当する機能)は一切入らないそうである。要するにこれらはいずれもPartitioningには対応しており、特定のPartitionがデバイスを占有する形になるとか。「それじゃVirtualizationの環境下で複数のGuest OSでデバイスを共有する場合は?」と聞いたら、それはHypervisorが何とかするとの事。このあたりは、Virtualizationでの今後の課題になりそうな気がする

この上で、Virtualizationが動くことになる。とはいえ、ほとんどの機能はPartitioningで済むから、Virtual Machineが処理する範囲はそれほど多くない。せいぜいがSystem LevelのInterruptとか、一部のShared Resources程度で済む。当然Hypervisorも、Partition管理(これは原則としてReset時のみの処理となるだろう)の他は、Virtual Machineの処理だけを行えば済む。

このあたりは、最近x86にインプリメントされたVirtualizationとちょっと異なる部分。x86はそもそもPartitionが非常に難しいので、H/W全体をVirtualizationでカバーし、この上でPartitionを切る形になる。これは互換性を考えるとそうせざるを得ないという話なのだが、こちらではそうした縛りがないから、Partitionが最初にあって、その上で互換性を保つためにVirtualizationが動く形。負荷は言うまでもなく後者の方が小さい

ちょっと聞き忘れたのが、部分リセットに対応しているのか? という事。複数のOSが動いている環境で、あるOSだけがリセットを掛けてしまったとか、逆にリセットを掛けたいといった場合に、Hypervisorはこれを正しくハンドリングできるのか、は気になる部分だ

このHypervisorはFreescaleから提供するというのは、まぁこれは当然といえば当然の事だろう。