OSDev.org

Posted: **Tue Dec 13, 2005 3:28 pm**

here's my situation. I have setup user space applications, and they work very nicely in vmware, but fail miserably in bochs.

I have narrowed down the issue to my mapping of pages into the user space process.

Here a synopsis of my algorithm.

i have 3 temp mapping addresses. 0xf0001000, 0xf0002000, and 0xf0003000. these are used to so i can alter the contents of the pages which will be in the target process (i have a "process->mapPage(virt, phys, flags);")

when mapping pages there are two processes i will refer to. "current" means the one that is running now and is doing the mapping, "target" means the process which i intend to map the page to.

so first i make sure that in the current process there is a page table setup in it's page dir that will let me map in pages at the previously mentioned addresses.

Code: Select all

1) then i map the target's PD at 0xf0001000 of the current process.
2) I then check the target's PD (via 0xf0001000) to see if it has a page table at the desired address, if it doesn't i allocate one and set it.
3) I then map the target's page table for the desired virtual address at 0xf0002000 of the current process.
4) I then check if there is already a page allocated at the desired virtual address if so, clean up, error out
5) finally I map the page into the page table (via 0xf0002000)
6) If the "zero page" flag is set, i map the target page at 0xf0003000 and zero it
7) cleanup, unmap, etc

now every time i map or unmap a page anyway, i do an invlpg for that page to be safe (though i think this is only needed for unmapping right?)

this works perfectly in vmware (I haven't test on real deal recently but will shortly) but in bochs it fails on step 2 when reading the page dir of the parget process through 0xf0001000! and I have no clue why. I am absolutely lost as to why this doesn't work.

BTW, i've recently noticed that it under some circumstances seems to work in bochs, for example i am able to map and execute pages for my v8086 monitor in bochs just fine, just not my user space apps

so...see anything wrong? or should I be looking for something else?

proxy

Posted: **Tue Dec 13, 2005 10:00 pm**

Hi,

proxy wrote:now every time i map or unmap a page anyway, i do an invlpg for that page to be safe (though i think this is only needed for unmapping right?)

No - you need INVLPG when you add a page too, unless your page fault handler is designed to handle "lazy TLB invalidation".

proxy wrote:this works perfectly in vmware (I haven't test on real deal recently but will shortly) but in bochs it fails on step 2 when reading the page dir of the parget process through 0xf0001000! and I have no clue why. I am absolutely lost as to why this doesn't work.

Is it possible that you invalidate the wrong page during step 1? It's a frustrating bug to notice...

Also, what does happen - do you get a page fault in Bochs, or does Bochs lock up, or something else? If you do get a page fault, what does it tell you (error code, CR2, EIP, etc)?

Cheers,

Brendan

Posted: **Wed Dec 14, 2005 2:54 am**

Do you zero out your page dir and page tables ere using them?

What do you use these three areas for? I didn't get it, honestly. It's a bit too complex for my coffee-drained brain. *smirk*

and what is this -> "current process which does the mapping" and "process which gets the page mapped in"? I think, this is a bit of overcomplicating simple stuff, but your mileage may of course vary.

KNow, you can center all your mapping stuff around the current process: one page directory accessible via 0xfffff000 trick. Map in map out is done in this process' address space. That's why I'm quite puzzled by your approach.

If I were you, I'd return to a pen and a piece of paper (or more) and redraft the stuff. I've got the slight feeling as if there's a can of worms hidden inside.

Stay safe.

Posted: **Wed Dec 14, 2005 12:47 pm**

Brendan:

I get a generic page fault at the address 0xf0001000 in bochs, EIP is consistant with the line of code which is causing the error (I generate an assembly linsting with interleaved source upon compile and the reported EIP matches the line which seems to cause the fault).

As for the addresses I am passing to invlpg, I *beleive* they are correct, but I will of course double and triple check them

All in all, does it seem like it could be anything else besides invlpg being misused though? I can't think of anything

beyond infinity:

at first I wasn't zeroing out the pages I allocated for page tables, but I corrected this previous to my post. So, good call, but unfortunately not the problem

and what is this -> "current process which does the mapping" and "process which gets the page mapped in"? I think, this is a bit of overcomplicating simple stuff, but your mileage may of course vary.

KNow, you can center all your mapping stuff around the current process: one page directory accessible via 0xfffff000 trick. Map in map out is done in this process' address space. That's why I'm quite puzzled by your approach.

I do in fact map the page directory at that address, but I don't see how this would simplify the process. Here's why, the process which is _running_ is not the process which I am mapping a page into... which means the target process's page dir is currently inaccessible! so I must temporarily map it into the currently running proccess right? same thing for the page table for the address I want to map, must be temporarily mapped as well!

I suppose I could do some trickery with swapping the page directory to the target process and this would eliminate the need for temporary mappings, but would introduce overhead through the reloading of the page directory and such. (which would have to happen twice, swap page dir, do work, then swap back).

proxy

Posted: **Wed Dec 14, 2005 2:42 pm**

Hi,

proxy wrote:I get a generic page fault at the address 0xf0001000 in bochs, EIP is consistant with the line of code which is causing the error (I generate an assembly linsting with interleaved source upon compile and the reported EIP matches the line which seems to cause the fault).

As for the addresses I am passing to invlpg, I *beleive* they are correct, but I will of course double and triple check them All in all, does it seem like it could be anything else besides invlpg being misused though? I can't think of anything

Could be you're using a page of ROM thinking it's RAM, or you're mapping the same page to 2 different places (e.g. kernel stack and 0xF0001000), could be a bug in Bochs (or a bug in VMWare), might be a bug in an IRQ handler (e.g. trashing a general register with unfortunate timing), could be a re-entrancy problem somewhere.

To rule out INVLPG, just reload CR3 instead of doing INVLPG - it'll wipe the entire TLB and will fix the problem if it is related to TLBs (unless you're using global pages, in which case it'd make it worse or not help at all).

If this tells you that it's not INVLPG, then put the following code before the page fault:

Code: Select all

   push ecx
   mov ecx,0
.zz:
   jecxz .zz
   pop ecx

Then, when Bochs reaches this code it'll loop forever. When this happens press "control+C" to enter the debugger and type "set$ecx=1" to end the endless loop. Then you can single step through it with "s" and see exactly what is in each register and memory location at each step.

Some useful comands for Bochs debugger:

infor = show the contents of the general registers
s = execute one instruction and stop
c = continue executing
trace-on = display every instruction executed
x /64 0x1234 = dump 64 dwords from linear address 0x1234
xp /32 0x1234 = dump 32 dwords from physical address 0x1234
? eax+(ebx<<12)+0x1234 = calculate the answer to a formula
help = show a list of help topics
help '<something>' = get help on the command <something>

It takes a little time to get used to, but once you've used it a few times you'll realize how powerful the debugger can be (especially if you've been using VMWare)....

Cheers,

Brendan

Posted: **Wed Dec 14, 2005 4:19 pm**

Could be you're using a page of ROM thinking it's RAM, or you're mapping the same page to 2 different places (e.g. kernel stack and 0xF0001000), could be a bug in Bochs (or a bug in VMWare), might be a bug in an IRQ handler (e.g. trashing a general register with unfortunate timing), could be a re-entrancy problem somewhere.

well i don't think i am mapping rom since I get my page list from grub and only add ram pages to my freelist. I highlky doubt I am mapping a page to 2 places but will check, the pages I'm dealing with are coming from my free page stack. Finally as far as IRQs and such, I disable interrupts during the process of mapping a page. Eventually this will be changed into disabling context switches, but for now..simply no interrupts so I dont think that's the prob.

I have set break points in bochs and taken a look and the code. Unfortunately it's rather hard to visualize page tables and page directories from memory addresses. Which of course gives me an idea for an enhancment into debuggers in general. Add graphical representation of page tables and page directories! where you can click around, zoom in/out etc.. would be pretty cool

anyway, not a bad idea reloading cr3, i'll give it a try.

proxy

Posted: **Wed Dec 14, 2005 4:27 pm**

fixed!

it was a math error on my invlpg so I was invalidating the wrong entries. Once i fixed that, worked like charm ;D

thanks all for the help

proxy

OSDev.org

paging problem in bochs but no vmware

paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware

Re:paging problem in bochs but no vmware