***本記事にはプロモーションが含まれています。***
現状のCVSだと、ハードディスクのRAWイメージは動くのですが、QCOWイメージが動きません。それと、CD-ROMも\.d:とかで直接指定すると動かないようです。
振り返ってみると、小さい不具合はいっぱいありますよね。-snapshotとか。折に触れ、直していくしかないけど。
***本記事にはプロモーションが含まれています。***
現状のCVSだと、ハードディスクのRAWイメージは動くのですが、QCOWイメージが動きません。それと、CD-ROMも\.d:とかで直接指定すると動かないようです。
振り返ってみると、小さい不具合はいっぱいありますよね。-snapshotとか。折に触れ、直していくしかないけど。
***本記事にはプロモーションが含まれています。***
Win98/Meホストのサポートは、続くことになりました。
Readの最初がエラーになるのも直りました。
RedHat 7.2ゲストを使って、ディスクI/Oのスピードを測ってみました。
hdparm -t /dev/hdaの結果。
QEMU-0.8.2
21.12MB/sec
25.20MB/sec
25.10MB/sec
25.20MB/sec
CVS
41.03MB/sec
57.14MB/sec
57.14MB/sec
57.14MB/sec
ほぼ倍のスピードになっています。OSの起動時間は変わらないですけどね。
***本記事にはプロモーションが含まれています。***
シリアルの扱いをポーリングからスレッドに変えたパッチを作りました。名前つきパイプをクライアントモードで使うオプションも付け加えました。
-serial pipe_client:com_1
-serial pipe:com_1を別のQEMUで使ってサーバーを立て、もう1つで-serial pipe_client:com_1で接続すると、2つのQEMUで通信ができます。
QEMUを2つ使って名前つきパイプで通信してみると、ポーリングからスレッドに変えることで、通信速度が4倍くらい速くなっています。スレッドって効率がいいんだってことがわかった。
ただ、windbgが使えなくなってしまいました。調べてみると、CPUのロードが大きいときにmain_loop_waitのループの回転速度が遅くて、データが送受信されていないことが原因でした。
前回作ったwindbgのパッチを使うとちゃんと動きました。
windbgを使えるようにしたバイナリ。
http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.8.2-windbg.zip
パッチ。
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-host_alarm.patch
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-serial-thread.patch
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-windbg.patch
これでいいんだと思うけど。
***本記事にはプロモーションが含まれています。***
ファイルの入出力にAIO(Asynchronous I/O 非同期I/O)を使った修正がCVSに取り込まれました。なんとかコンパイルはできたのですが、いろいろと悩ましい問題を発見。
まず、Win98/Meホストがサポートされなくなってしまいます。ソースのヘッダに変更を加えないといけないので、Win2k/XP系とどちらもサポートするバイナリが作れません。どうしても必要なときは、別のバイナリにしないといけないです。そうするには、パッチも作らないといけないし、どうしましょう。ホストは、Win2k/XPのみで困る人はいるかな。
手許にWin98/Meホストの環境がないので、作ろうとしても動くかどうかわからないし。QEMUの中で動かせばいいのかもしれないけど。でも、イマイチだけど。
もうひとつは、ドライブレターつきのハードディスクイメージを開こうとすると、最初のトライが失敗してしまいます。なぜかは不明。これは直さないと使えない。
AIOそのものも、今は使わないようになっています。これを動作させるのも大変そう。
***本記事にはプロモーションが含まれています。***
VLANとTapのバイナリとパッチを更新しました。
Tapのポーリングはやめて、スレッドのみにしています。
VLANの方は、とりあえず更新のみです。パフォーマンスを上げるために、selectを使うのをやめないといけないのですが、もう少し時間がかかりそう。
***本記事にはプロモーションが含まれています。***
Sparcのバイナリをアップデートしました。
OpenBIOSをアップデートすることで、ちゃんと動くようになりました。
***本記事にはプロモーションが含まれています。***
0.8.2のバイナリを作りました。
sparc-softmmuのバイナリがうまく動かなくて、アップしていません。
qemu-img.exeでFAT32上で4GB以上のファイルが作れないですけど、パッチが当てられなくなってしまっていて、今後の課題です。
VLAN用もまた作ります。
***本記事にはプロモーションが含まれています。***
-serial pipe:com_1とwindbgを使ったときの、スピードを上げるパッチを作った。windbgを使わない時と同じくらいのスピードが出るようになります。
問題は、CPUのロードが大きいときにデバイスを扱うループの実行回数が減ってしまうことにありました。たとえば、CPUがアイドルのときは1000回/秒あるのですが、CPUが動き出すと130回/秒になってしまって、データの受信速度が極端に遅くなるのが原因でした。本当は、データの送受信があるときは、ループがたくさん回らないといけないですけど。
強制的に、CPUのループを抜け出してデバイスを扱うようにしています。そのため、少し効率が悪いので他の目的には適さないかもしれません。
シリアルは、ポーリングをすることでデータが来たことを検出しているのですが、シグナルを使ったものに変えてくれと言われています。メーリングリストに投稿するのはそのあとです。
レスポンスがよくなって、これなら使えるという感じです。ただ、windbgのコマンドを知らないのでまずそれからですけど。
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060709-windbg.patch
調べてたら、windbgの使い方が書かれているのを見つけました。すごい。
http://www.ttoyota.com/php/windbgintro.php
***本記事にはプロモーションが含まれています。***
QEMUを扱っていると、PowerPCやSPARCのバイナリを作りたくなることがあります。そこで、gccを使ったクロスコンパイル環境を作れないものかと思ってトライしてみたのですが、何も見ないでやろうとしてもうまくコンパイルできません。
検索してみると、gcc-2.95のような古いものは解説があります。新しいものでいいものがないかと探してみると、Linux From ScratchにCross Linux From Scratch(CLFS)として、いろいろなCPU用のクロスコンパイルの方法が載っているのを見つけた。
実際にPowerPC用のgccと、glibc、binutilsを作ってみたのですが、これがなかなか難しい。オプションが少し違っていただけで、glibcやgccがエラーになってぜんぜん作れなくなったりします。仕方がないので、言われたとおりに作ってみると、やっと作ることができました。
ポイントの1つは、LFSで提供されているLinuxカーネルのヘッダーを使ってglibcを作ることです。もう1つgccのデフォルトのライブラリへのパスを設定するところなのですが、どこで設定しているのかよくわからなかった。
gccはまずglibcを作るためにstatic版を作って、そのあと作ったglibcを使ってもう一度gccを作ることでやっと普通に使えるものができます。
もう少し、クロスコンパイルが楽にできるといいのですけど。でも、情報があるだけでもありがたいことですけどね。
OpenBIOSのPowerPC用を作ることができることも確認した。でも、これではQEMUは立ち上がらなかった。SPARC用のも同様に作ってみた。少し変更するとバイナリができました。QEMUで使ってみるとペンギンさんは現れるのですが、文字が見えずでした。OpenBIOSはちゃんと動いているみたいだけど、なぜでしょう。
***本記事にはプロモーションが含まれています。***
インストールしてみた。けど、なぜかネットワークのインストールのところで止まって次に行かないみたい。
ハードディスクは、3GB用意しました。
qemu-system-x86_64 -L ../pc-bios -hda winxp64.img -cdrom //./e: -boot d -m 256
しょうがないので、-net nic,model=rtl8139 -net user つけて途中からやり直してみると、今度はドライバーのインストールのところで止まる。
それで、もう一度 -net 付けずにトライしてみたら、インストールできた。
なんか、x64の画面を見ると感動。
設定を保存していますのところででものすごい時間がかかる。ハードディスクのアクセスが遅いのか、容量がたくさん必要なのか、メモリーがもっと必要なのかわからないけど。
とにかく時間がかかりました。止まっているように見えても、動いていると思いますので放っておきましょう。
ネットワークは、動いていないようなので、RTL8139をチェック。
そこで、-net nic,model=rtl8139 -net user 付けて起動してみると、デバイスの認識はしたみたい。ネットワークが使えるようになった。
x86_64 Fedora Core 4上で、Kqemuの64ビット版を使ってみた。すこし速くなって快適になります。-kernel-kqemuは使えないけど。i386で64bitが使えるともっといいのにね。
もう少し速いと、いいんですけど。