06/09/17 01:40:24
>>257
＞３）タイマー割り込みのハンドラでVMビットをONしてリアルモードの割り込み
＞ ヴェクタをスタックに設定してIRETします。
この部分。タイマ割り込みを使って実験の状態を作っているのだと思いますけど、
ここのIRETは以前書かれていた"VMが1のまま"となるというのは …VMビットに触れないので仮想86モードのままのIRET
インテルのマニュアルにもある通りでしょう。
例えばこのIRETの前に
(別の)割り込みを呼んでVM=0,IRET(オペランドは32bitとする)の後、 …プロテクトモードでのIRET
先のIRETが呼ばれるのだと …VM=0とされた状態でのIRET
期待通りになるんでしょう。
260:崎本
06/09/17 05:16:21
仮想86モードにIRETする前にTSSのESPは再設定してるかね？
261:Be名無しさん
06/09/17 12:05:23
>>260
よく理解はしていないですが
取り合えず、リング０のEPSは設定しています
262:Be名無しさん
06/09/17 12:11:46
>>259
以前、心当たりが有ると書いたのは
割り込みのIRET時の戻り先に#UDを発生させる関数を設定して
VMビットをクリアーでいいのかなっと思ってます。
ただ、IRETで例外が発生すると思っていたので上記の処理はしてませんでした。
263:ぴゅあ
06/09/17 15:31:53
>>262
タスク関連はよく解らんと言ってたし、
特に使ってないんだろうという前提で話してきてるけど
＞割り込みのIRET時の戻り先に#UDを発生させる関数を設定して
＞VMビットをクリアーでいいのかなっと思ってます。
割り込み前のメインは無限ループとかで、
ただタイマ割り込みを待ってるみたいなものとして
(そしてそのメインはプロテクトモードで)
(実験中にタイマ割り込みが多重に割り込むとかない(考えなくていい)と仮定されているとして)
タイマ割り込みを受け付けた時点でプロテクトモードになってて
そこでVMビットを1にして仮想86モードにするのは、
どういう形でやっているか判らないけど、できてるということなんでしょう。
(たぶん以前は(自分でVM=0としようとしたのかどうか…)IRETに任せようとしていたのでVM=1のまま)
(＞戻り先に#UDを発生させる関数を設定して)
#UDを発生させた後、プロテクトモードに戻っている(VM=0)の筈なので
#UDを発生させたことによってスタックされた分を後始末(破棄)して
(仮想86モードに入ることによって触ったものも元に戻して)
"＞VMビットをクリアーでいいのかなっと"というのは、自分でやらなくても既にVM=0で
#UDの最後のIRETでタイマ割り込みを受け付けた時点の状態でIRETすれば
VM=0にもなってて、タイマ割り込みルーチンからもちゃんと抜け出ているだろうと思うけど。
頭の中でイメージしてるだけだけど。。。
＞VMビットをクリアーでいいのかなっと思ってます。
って、なんとか形にはなって、いちおOKかな？と思ってるということ？
それとも、(理解が途中とかは置いといて)まだうまく行かなくて格闘中？
264:Be名無しさん
06/09/18 10:03:48
まだ格闘中で、マニュアルを読んでいる最中です。
265:256
06/09/18 14:48:50
>>255
少し調べてみたけど、別にintとかコールゲートでも問題なさそうですね、
ってか2000辺りでもintは使われているんだな。
まぁオーバヘッドを考えたらsysenter一本らしいですけど。
とにかく参考になったので多謝。
後はメモリの管理かぁ、むむぅ、ここがネックだなぁ。
266:Be名無しさん
06/09/18 15:04:23
2000出た頃はsysenterなんてなかった。
267:Be名無しさん
06/09/18 16:04:34
>>266
比較的2000って信頼性では良いという評価を受けているから、ビックリしました。
sysenterとかそういう命令じゃないと、現状では信頼性が確保できないのかと思ってしまいました。
やはり調べないと分からないものですね。変態チックで楽しいですけどｗ
268:崎本
06/09/18 18:43:51
「最近」ゆっとるがな(´・ω・｀)
269:Be名無しさん
06/09/18 18:59:01
>>268
いやいや、その「最近」が難しいもんでｗ
270:Be名無しさん
06/09/18 19:00:50
>>267
intとsysenterの選択って信頼性に関係するんですか?
271:Be名無しさん
06/09/18 19:25:17
sysenterは486で動かない
272:崎本
06/09/18 19:26:09
パソの世界じゃ2000年はもう過去じゃね？
273:Be名無しさん
06/09/18 19:48:43
>>270
いや、関係ないんだなぁと改めて確かめる事ができたということです。
もともと大して問題は無いよなぁーとは思っていたけど。
>>272
崎本さんは64bitOSを作っているわけですから。
まだまだIA32も現役だからねー。
結論として何でもいいけどバグさえ混入しないようにという結論となりますた
274:Be名無しさん
06/09/30 13:32:52
OSつくーるで作れば？
275:Be名無しさん
06/10/21 00:35:02
以前に仮想８６モードに付いて質問した者です。
取り合えず解決しました。
今回やりたかった事はローダからカーネルをメモリーに読み込むために
DISK BIOSを使用したい為、シングルプロセスで他からの割り込みが入らない
条件で仮想８６モードへ移行し、プロテクトモードに戻ってくることを想定しています。
旨く行った条件は NMI 関連の割り込み処理なので実際にやりたい事とは違いますが
下記の様に処理しています。
１）メインの処理で NMI の割り込みを許可
２）メイン処理で無限ループに入る
３）タイマー割り込み発生
４）タイマー割り込みハンドラ内で一時的なスタックを使用して
１６Bits タイマー割り込みハンドラ を呼び出す為に仮想８６モードへ移行
５）この時、IIRET の戻り先を #UD を発生させる関数にする
６）#UD の例外処理関数内で 終了処理を行う
７）この時点で４）の直前に戻っている
８）そのまま、何もせずに割り込まれた処理へ戻る
処理５）から処理６）へ移行する時に割り込みが発生する可能性が在りますが
ローダの処理なので見なかった事にします。(~_~)
#UD の発生は オペコード 0x0FB9 を記述して UD2命令はは使用していません。
今回は TSS を使用した切り替えを行っていませんが 特権レベルが変化するような場合は
最低限の設定が必要なんでしょうか？
今回は、ss0/esp0 の設定しかしていません。
気になる点が有りましたら御教授願います。
276:ぴゅあ
06/10/21 20:58:34
解決したと言われているので問題なしだと思うけど
＞気になる点が有りましたら御教授願います。
タイマ割り込みを使った検証をされていたのですよね
タイマ割り込みを使ってとか#UD発生に終始されていた感もあったりしましたが
DISK BIOSを呼び出す上でどのように考えられているのかな？
ってところくらいかな
なので、気になるって程のものでもないですけど
277:Be名無しさん
06/10/27 23:58:03
>DISK BIOSを呼び出す上でどのように考えられているのかな？
タイマ割り込みやキーボード割り込み等と同じ割り込み時のスタックを擬似的に再現して
任意のINT命令を発行する予定です。
278:277
06/11/03 01:16:51
取り合えず、DISK BIOSの呼び出しで１セクタの読み込みは出来ました。
ハードウエア割り込みとソフトウエア割り込みを有効な状態で
DISK BIOSの呼び出しが出来たので、ローダの主処理を作成します。
煮詰りましたら、その時はまた伺います。<m(__)m>
279:Be名無しさん
06/11/04 14:16:03
むこうのスレ人いないんでまたこっちにきますね