これらの働きにより、例えばこんな形で8Pを2:4:1:1と分割して使うことが現実に可能である。もちろん、これをすべて賄える1つのOSが用意できればそのほうが(負荷分散の観点からは)好ましいのかもしれないが、既存のソフトウェア流用という点では作業が増えることになる。すでにあるOSとアプリケーションがそのまま移植できれば、それはそれで商品投入までのTTM短縮に繋がる。

"Without *large* changes"というわけで、細かな調整は当然必要になるだろう。そもそもCPUコアが従来と異なる新設計のe500mcだから、無修正で動作、という訳にはいかないだろう

ちなみにGuest OSをHypervisor上で動かすためにはどんな変更が必要か? を簡単にまとめたのがこちらとなる。

Guest OSから見た場合のResourceは基本的にe500v2と互換なので、ほとんど変更の必要はない。結局最大の問題はSPEの有無というあたりになる

これもどちらかといえば、Guest OSというよりはHypervisorの話な気がする

大雑把に言えば、MSRGS(Guest Statusを示すMachine Status Register)ほか幾つかのInternal Registerが追加されており、Hypervisorはこれらを用いて管理を行うが、これらはGuest OSから基本的には触る必要が無い部分で、特に気にしなくても良い。

むしろFPUに関係する部分の方が影響が大である。もちろんHypervisor側はPartitionを区別するLPID(Logical Partition ID)の管理とか、Partitionごとにメモリ空間を切り替える関係で、MMU内部の管理方式の違いなどが当然あるのだが、これはFreescaleが提供するHypervisorの中で吸収されるから、直接的には無関係である。多少なりとも関係があるとすれば、割り込みに関係する部分だろう。これは個々のGuest OSというよりは、システム全体の設計の中で関係してくる部分であろうと思われるが、この設定を行うのは必須というあたりか。

すべての割り込みについて、すべてをHypervisorをスルーして直接Guest OSに届かせたらHypervisorの管理ができなくなるし、全部をHypervisorでハンドルしたら割り込み処理が遅くなる。このあたりは、周辺機器のPartitioningの際に、一緒に設定することになるのだろう