Help Needed with this Debug screen

[Slasher]

I've a working Kernel that can run both ring0 and ring3 code. Now I've decided to add V86 support.
I setup the V86 task with a level 0 stack at 0x9000 and set it up as follows ->gs,fs,ds,es,ss,esp,eflag,cs,eip (this matches what Intel states for the state of the stack after an interrupt in V86 mode)
the eflag is 0x23202 which is VM bit set,IOPL = 3,IF bit set.
I load a test file at 0x7c00 which contains
mov ax,0xdead
int 3
to test the switch to V86 mode
now, in Bochs, the code to switch to this task has a hlt instruction before it issues an iret so that I could dump the cpu. I get the expected register contents but as soon as I step the code to execute the iret i get the following output shown in the attachment below.
as you can see at the bottom of the image, the cs:ip is pointing to the right place but for some reason the cpu cant execute the code mov ax,0xdead.
can anyone tell me what Error: (0) print_gaurd_results: gaurd_found ? (stop reason 0) means?
Thanks

[BI lazy]

What version of bochs are you using? I can't identify this error message.

The line after the obscure bochs lament is most interesting:
you are actually in the vm86 and the bochs hasn't crapped out. what about saying s1 one more time to reach the int3. Surely it will drop you into your vm86 monitor.

Why do you set the level0 stack at 0x9000? I'd rather put this one in kernel land - say 0xc0005000, or what ever you allocate there for level0 stacks. (well, I use a dedicated kernel stack after saving esp0.) - and the ring3 Stack, which is of course needed for vm86 - at 0x9000. It'd be worth a try.

hth&ccw

[Slasher]

I'm using Bochs 2.1 and I've used both a stack for level 0 at 0xcxxxxxx and 0x9000 . Both yield the same results, all the registers get the expected values but the 16 bit instructions at 0x07c0
mov ax,0xdead
int 3
do not get executed, instead I get a page fault for linear address 0x7c00 which I know is linearly mapped,present and is a user page.
This fault happens as soon as I step Bochs to execute
mov ax,0xdead
Any ideas?

[BI lazy]

hmmmmm ...

AS far as I see, the bochs *is* in the correct page directory and it can access the contents of the page. Else it would inform us of not present memory with some question marks and sorta.

Maybe it is a silly question - but that's how I set up ring3 pagedirectories:
pagedir:system privilege.
pagetable for userland: user privilege
page table entry for userland: user privilege

How do you deal out privileges for pagedir/pagetables/Pagetable entries?

Because you get a pagefault if trying to access a system privilege page when running in ring3.

[Candy]

This fault happens as soon as I step Bochs to execute
mov ax,0xdead
Any ideas?

I would like to know whatever is on your stack (what does IRET get), the corresponding GDT/LDT/IDT entries and preferably your TSS too. Also, you did notice that the dump_cpu said your eip was 0?

[bi lazy]

good point, candy ... couldn't read this one from that screen shot, so I didn't recognize it.

Maybe an excerpt of the code to set up the vm86 task would be helpful? especially the place where you are setting up the stackframe for the vm86 task.

[Slasher]

THANK YOU ALL SO MUCH ;D
I've finally gotten the V86 task to run. And the problem was not with how I set up the stack, or the iret or my paging layout.
The problem was that I had defined the page_dir and page_tables for the v86 task as SYSTEM_PAGES
Now I'm confused, why in V86 mode,would the paging mechanism of the processor want the page_dir and page_tables to be defined as user pages? is it because v86 code is running at user level 3? If this is the case, why is it so because its the kernel/cpu that access the page_dir and page_tables are running at level 0.
Any explainations will be most welcome. (ps I going to re-read the info on paging in the intel manuals)

@candy:
if you look at the image, you'll see that cs = 0x007c0 and eip = 0
which when handled by the processor as real mode values gets
0x7c00 (0x07c0:0000).

[Pype.Clicker]

what is certain is that the entry #0 should have the 'USER' bit set, as your user-code will be running there. Both table & directory entries are checked to know if an operation can happen on a page.

[Slasher]

I did that. I mean, the page dir and page table for mapping 1:1 1Mb and the whole memory were defined as system pages so that no process could over write them. But the page frames for 0mb - 2mb are marked as User Level pages.
why didn't that work?

[Candy]

I did that. I mean, the page dir and page table for mapping 1:1 1Mb and the whole memory were defined as system pages so that no process could over write them. But the page frames for 0mb - 2mb are marked as User Level pages.
why didn't that work?

The entry in your page directory for your page tables indicates what level of protection should be over the pages mapped by the page tables below. The entry that describes the place where you have mapped your page tables (if you have even mapped them at all!) describes the protection of your page table itself.

[Pype.Clicker]

let's say you want to have user code in lowest 1MB and self-mapped the directory as the last page table.

Code: Select all

dir[0].frame=phys_addr(v86table);
dir[1023]=phys_addr(dir);

You'll grant user access to V86 task with

Code: Select all

dir[0].flags=PG_PRESENT|PG_USER|PG_WRITABLE;
for (int i=0..1023) v86table[i].flags=PG_PRESENT|PG_USER|PG_WRITABLE;

and prevent user to modify the mapping with

Code: Select all

dir[1023].flags=PG_PRESENT|PG_WRITABLE;

Of course, your directory may not be in the lowest 1MB for this to work correctly