スマホのAndroidのプログラム開発で、アクセラレーターとして使われているIntel Hardware Accelerated Execution Manager(HAXM)ですが、QEMUでも使えるようになっています。Windowsホストでアクセラレートできるのがいいですね。
これが、昨年2017年の11月にオープンソースになって公開されていました。QEMUのメーリングリストにはメールが出されていました。気づかなかった。
ライセンスは、BSD 3-Clause Licenseです。
作るには、Enterprise WDK 10かVisualStudioとSDK、WDKを使うようになっています。
ソースコードを見てみたのですが、自分が少しプログラムとは離れていたせいで、読めなくなっていました。どうしましょ。
ともあれ、ソースコードが公開されたことは今後にとって良かったのではないでしょうか。
QEMUでHAXMを使う手順が次のところに載っています。
Accelerating QEMU on Windows with HAXM
興味がある方はお試しください。
先月のQEMUのメーリングリストで、WindowsホストでアクセラレーターのHyper-Vを使えるようにするパッチが投稿されました。パッチを見てみると、なんとMicrosoftの人が作っています。Microsoftの人がGPLv2のソースコードを提供するなんてことは一昔前には考えられないことですね。
以前、インテルのアクセラレーターを使えるようになるパッチが取り込まれました。
今回これが動くと、特別にアクセラレーターをインストールしなくてもQEMUが速く動くのでいいですね。
メーリングリストではどのバージョンのWindows 10でも動くといっていますが、Hyper-VはWindows 10 Professionalでしか使えないことになっていますね。どちらが正しいのでしょう。
それと、Windows 10 Insider Previewというバージョンでしか動かないようです。次のWindows 10のアップデートで動くということでしょうか。
アクセラレーターはWindows Hypervisor Platform acceleratorという名前で、2月の初めにはソースコードがマージされています。
バイナリを作ろうとしたら、なんかエラーが出て試せていませんが、興味のある方は試してみてはいかがでしょうか。
ARM版のWindows 10が発表されましたね。興味深いのは、ARM版でも、x86版のソフトウェアが動くことです。どうやっているかというと、x86版のソフトをバイナリトランスレーションして、ARMの命令に変換して動かしているのです。
明らかになってきたArm版Windows 10の課題とそのメリット
QEMUでやっていることと同じなので、どれくらい速度が出るのか気になるところです。記事を読むと、Win32のシステムコールにトランスレートした後、呼び出すDLLはネイティブの物を使うようです。この辺が、全部トランスレートして動かすQEMUと違うところでしょうか。サポートするのも32ビットのバイナリのみで、64ビットのソフトは動かないようです。Officeの32ビットが動けばいいやという感じでしょうか。
Intelが自社のチップのスマホで、ARM版のバイナリをx86の命令にトランスレートして動作させていますが、それとは全く逆のことをやっていますね。
Snapdragon 835だと、Cherry TrailとCore i3の間くらいの速度だそうです。あまり速度は気にならないような使い方がメインなのでしょうか。
動作速度より長時間使えることの方が、大切なのかもしれません。
来年には、Snapdragon 845が出るそうですから、そちらの方がいいような気がします。
ともあれ、実際に出てきたときはそれほど高いものにならないといいなと思います。
QEMU on Windowsのサイトを移転します。
auのホームページ公開サービスが、2017年10月31日で終了します。
そのため、今のままで保存しておくことができなくなりました。
サイトの更新をやめてもう10年もたつのですね。時の過ぎるのは速いです。
情報も古くなっていますし、プログラムだけダウンロードできるようにしました。
新しいバージョンは、バグが入っていて公開しにくいです。
とりあえず、新しいサイトをよろしくお願いします。
スマホのアプリ開発では、Android SDKが使われます。このSDKの中でQEMUがエミュレーターとして使われています。Intelから、このQEMUを補助するドライバとしてHardware Accelerated Execution Manager(Intel HAXM)というアクセラレーターが提供されています。
動作する条件は、２つあります。１つは、パソコンの開発環境がIntelのCPU上であること。２つめは、エミュレートするAndroidは、Intelのチップ上で動くx86用のAndroidであることです。
WindowsとMac OS用に以下の場所でデバイスドライバーが提供されています。
IntelR Hardware Accelerated Execution Manager (Intel HAXM)
自分もAndroid SDKを動かしてみたことがあります。やはり素のQEMUよりアクセラレーターがあったほうがアプリもきびきび動いてよいです。
このデバイスドライバーを使うパッチがメーリングリストに投稿されました。2017年の４月ごろに予定されているQEMUの次のバージョン2.9.0でサポートされるようになるようです。
Linux上ではKVMがありましたが、WindowsやMac OS上でアクセラレーターがなかったので動くとうれしいですね。
QEMU/KVMでセキュアブートを利用する方法が紹介されています。
セキュアブートを実現するには、３つも鍵が必要なんですね。公開鍵と秘密鍵を作って、それを利用して鍵をNVRAM領域に書き込む必要があるそうです。
少し手間がかかります。QEMUを使って体験してみると、セキュアブートの理解が進んでいいのではないでしょうか。
QEMU/KVMでUEFIファームウェアを使う方法が紹介されています。
OVMFというオープンソースのファームウェアを使っています。
UEFIを使うメリットとしては、２TB以上のハードディスクを使う場合ぐらいしか現状ではないかもしれませんが。
でも、UEFIを開発するにはデバッグもできていいのでしょうね。
久しぶりにWindows上でQEMUを作ろうとしたら、ソースコードの修正が入っていて作り方が変わっていました。いろいろ試行錯誤して作り方を見つけたので紹介します。
今年（２０１６年）の３月までは、GCC 4.5とGTK+ 3.6.4という組み合わせでコンパイルできていました。でも、MinGW-w64のgcc 4.8になるとwinsock関係のインクルードファイルに変更があって、それに対応するためにQEMUにも変更が入りました。
この変更で、GTK+ 3.6.4のライブラリ内でワーニングが出てしまい、QEMUをコンパイルできなくなりました。GCC 5.4に変えても無理で、GTK+のライブラリのバージョンを上げることが必要になりました。
QEMUは、GTK+に含まれるGlibというライブラリを使っています。Windows上でコンパイルしようとするときは、今まではGTK+のホームページからx86_64版をダウンロードして使ってきました。しかし、メンテナンスする人がいないようで、配布されなくなりました。GTK+のホームページでは、MSYS2という開発環境を使うよう案内があります。今後は、MSYS2を使った環境でしかQEMUを作れないことになりそうです。
Linux上のクロス開発環境では今までどおり作れると思います。
MSYS2はインストーラーが準備されていますので、MSYS2インストーラーのホームページからmsys2-x86_64-20160205.exeというインストーラーをダウンロードしてインストールするだけです。
SourceForgeにあるMSYS2の新しいインストーラーはなぜか起動しなかったです。
インストール後にMSYS2インストーラーのホームページに従ってアップデートするのですが、
pacman -Sy pacman
は大丈夫でした。しかし、次の
pacman -Syu
をすると、エラーで止まってしまいました。新しいプロセスをフォークできませんと言っています。調べてみると、エラーのあったパッケージは手動でインストールしなおさないといけないそうです。filesystemというパッケージがエラーになっているのをメモリました。仕方がないのでCrtl-Cでプロンプトに戻り、いったんターミナルを終了しました。ターミナルを、もう一度スタートメニューから起動しようとしましたが起動せず、コマンドプロンプトが出てしまいます。
原因は、MSYS2の起動方法が変わり、batファイルで起動していたのをcmdファイルに変更したためです。
C:\msys64\msys2_shell.cmdをダブルクリックすることでターミナルは起動しました。そこで、
pacman -S filesystem
で、filesystemをインストールしなおします。メッセージに起動方法が変わったことが出ていました。
あとは、スタートニューのMSYS2 Shellの項目のプロパティを開き、
C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -msys
と書き換えることで起動できるようになります。ポイントは、msys2_shell.cmdを指すように変更することです。コマンドプロンプトのウィンドウも閉じるように/Kオプションを/Cオプションに変更しました。なお、Windows 10では、右クリックでプロパティを表示させることができませんでした。いったん「ファイルの場所を開く」で、エクスプローラーを表示させて、アイコンを右クリックでプロパティを変更することができます。
スタートメニューの問題は、インストーラーがアップデートされれば、いずれなくなると思います。
MSYS2のアップデートが終わったら、QEMUに必要なツールをインストールします。
MSYS2は、パッケージマネージャで管理されているので、次のようにしました。まずは、gccなどのツールをインストールします。
pacman -S mingw-w64-x86_64-toolchain
次に、GTK3をインストールします。
pacman -S mingw-w64-x86_64-gtk3
SDLライブラリも必要なので入れます。
pacman -S mingw-w64-x86_64-SDL2
あとは、makeとcmpとbisonが無いといわれますのでインストールします。
pacman -S msys/make
pacman -S diffutils
pacman -S bison
これで、必要なツールは、インストールできました。あとは、QEMUのソースコードを持ってきて作るだけです。
QEMUを作るときは、MinGW-w64 Win64 Shellを起動して作ります。このときの起動パラメーターは、-mingw64をつけます。スタートメニューのMinGW-w64 Win64 Shellのプロパティを変更する必要がありました。
C:\Windows\System32\cmd.exe /A /Q /C C:\msys64\msys2_shell.cmd -mingw64
QEMUをWindowsで作るにはMSYS2の開発環境が必要になりました。
MSYS2のインストールで、エラーが出るため手動で書き換える必要がありました。
MSYS2のMinGW-w64のGCCのバージョンは、6.1.0です。ちょっと見ないうちにすごく上がってしまいました。
GTK+のWindows版をメンテナンスする人がいないということは、使う人もいないのでしょうね。開発の主力がインターネットのほうに移っているのでしょう。時代の流れを感じます。
MSYS2という環境は、パッケージマネージャがあるので、環境整備はやりやすくなったと思います。
インテルがアルテラを買収するそうですね。XeonにFPGAを組み込む計画があるそうです。
インテル、プログラマブルなLSI「FPGA」大手のアルテラ買収を発表。XeonにFPGAを組み込む計画も表明
そこで思ったのですが、QEMUのダイナミックトランスレートの部分をFPGAに書き込んで実行させたら少しは早くなりそう。
2倍くらいにはなりそうな気がします。
プログラムの実行時に書き込みができるようにするんですかね。それとも、OSが立ち上がる前に書き込んでおかないと使えないのかな。
VT-xには足元にも及びませんが、FPGAの使いかたの1つにはなりますかね。
x86_64ゲストがカーネルパニックで起動しないバグを見つけてしまいました。
QEMUの2.3.0を作ろうとしています。何の気なしにx86_64のゲストを起動したところ、カーネルパニックが発生。最初MinGWの問題かと思いました。VMware Player上のUbuntu 14.04ホストでも発生することがわかりました。
起動するゲストOSと起動しないものがあります。32bitのゲストOSは起動します。64bitのゲストOSは、起動するものは、Fedora 10です。Fedora Core 4は起動しません。Ubuntu 12.04は、-m 2048オプションをつけると起動しますが、つけないと起動しません。
さて、どうしたものでしょう。