oy vey, I am stuck with it. I understand, that I have to do some mapping (paging is quite helpful with that), to get this task running in the 1 mb area. But ha, that's it. 've stuffed together an extra function just to create a stackframe for a vm86 task, do some mapping (it does what I want it to do, test peeks and a test pmode task run perfectly...), but it craps out when it comes to running in vm86 mode: bochs says clearly: interrupt(): SS selector null, when it reaches the first instruction to execute in vm86 mode.
to avoid misunderstandings: I've done research, I've examined MK_FP, FP_OFF, FP_SEG macros and included them in my kernel, but it doesn't help.
My task switcher runs. It should, as I understand it, go in and out of vm86 mode at task switch.
btw: I am loading the vm86 task as an extra module via grub. this feature is handy ) Gonna do some testing of task loading with it too.
thanks for help and clarifiying.
creating vm86 mode task
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
creating vm86 mode task
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:creating vm86 mode task
It might be worth noting that an interrupt frame for V86 mode has some extra fields at the end, for the real-mode DS, ES, FS and GS segments. Look at the Intel manuals or the Mobius source for inspiration.
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:creating vm86 mode task
these are pushed by the cpu right after user stack segment/offset, as far as I've seen.
thank you for help.
thank you for help.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:creating vm86 mode task
it still doesn't do what I expect it to.
Now, I have mapped some memory to 0x00002000 - 0x00009fff. In this memory area I move the vm86-module loaded by grub (thats a real nifty thing), assign user stack at 0x00003000. Kernel is mapped to 0xc0000000 -0xffffffff.
Hm... I think I still have not really understood, how the cpu in vm86 mode knows where the kernel is located. It can just adress 1 mb. so, what is going on here? bochs quits with interrupt(): ss selector null, when vm86-task traps into a sensitive instruction: push in my case. Looks like it can't put things on the kernel stack. Oy Vey, I feel silly...
Now, I have mapped some memory to 0x00002000 - 0x00009fff. In this memory area I move the vm86-module loaded by grub (thats a real nifty thing), assign user stack at 0x00003000. Kernel is mapped to 0xc0000000 -0xffffffff.
Hm... I think I still have not really understood, how the cpu in vm86 mode knows where the kernel is located. It can just adress 1 mb. so, what is going on here? bochs quits with interrupt(): ss selector null, when vm86-task traps into a sensitive instruction: push in my case. Looks like it can't put things on the kernel stack. Oy Vey, I feel silly...
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:creating vm86 mode task
basically, the VM86 mode ignores everything about kernel, but if it ever (and it eventually will) generates an exception or receives an interrupt, protected mode is restored with an inter-level call and GPF handler is invoked.
to have this exception taken correctly,you of course need a valid SS0 selector in your VM86 TSS, and a valid ESP0 that comes with it. (that's the first possible cause for your "null SS" message)
Your VM86 task receives its ax..bp values from the current eax..ebp contents at the time of the IRETD instruction, while it receives ip, xs and sp from the current stack frame.
to have this exception taken correctly,you of course need a valid SS0 selector in your VM86 TSS, and a valid ESP0 that comes with it. (that's the first possible cause for your "null SS" message)
Your VM86 task receives its ax..bp values from the current eax..ebp contents at the time of the IRETD instruction, while it receives ip, xs and sp from the current stack frame.
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:creating vm86 mode task
hmm.... my stack switching code patches the system tss in an apropriate way.
Seems as if the vm86 task doesn't mind then wether the kernel is located at 0xc0000000 or not, then. I still have to provide a kernel stack segment and adress for the userlevel->kernellevel transitions in case of exceptions. and exactly here i have problems.
Thanks for clearing the miracle pype. Hope, I get this sorted out *ggg*
Seems as if the vm86 task doesn't mind then wether the kernel is located at 0xc0000000 or not, then. I still have to provide a kernel stack segment and adress for the userlevel->kernellevel transitions in case of exceptions. and exactly here i have problems.
Thanks for clearing the miracle pype. Hope, I get this sorted out *ggg*
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:creating vm86 mode task
Oh Gosh, I did it finally )
A real awful bunch of flaws came along as obstacle to it. But now, it does what I want it to do.
Just need to do message passing now to tell that vm86 task what to do and then to wake it up.
It feels better now that it has bios support built in.
A real awful bunch of flaws came along as obstacle to it. But now, it does what I want it to do.
Just need to do message passing now to tell that vm86 task what to do and then to wake it up.
It feels better now that it has bios support built in.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image