Page 1 of 2
Return of the triplefaulting paging - this time with atttach
Posted: Sun Aug 21, 2005 11:38 am
by Crazed123
I AM zeroing out the page directory and table manually, and those are the only two data structures I know I am relying on the make paging work that could possibly need zeroing out (ie: they are the only fresh memory at that point).
Enabling paging as I have coded it triplefaults a real computer, but works perfectly on Bochs. I have been unable to figure out what's going on, as I am used to having some form of either debug output or a real debugger to work with.
This time the entire Pascal unit is attached, as a .txt file (Can we please be able to attach .pas files? Please?!) so that the spaces used for indentation will show up.
On that note, I apologize for my reaction to being told my code has no identation in the other thread. As it turns out the code tags weren't displaying the spaces I put in, they must be used to tab indentation. I failed to see this and took offense where I shouldn't have.
Re:Return of the triplefaulting paging - this time with attt
Posted: Sun Aug 21, 2005 11:54 am
by Kim
Can you please give the declare part of SegmentationVirtualBase + the value.
Re:Return of the triplefaulting paging - this time with attt
Posted: Sun Aug 21, 2005 12:37 pm
by Crazed123
Sure.
Code: Select all
var
SegmentationVirtualBase: longword; external name 'SEGMENTATION_VIRTUAL_BASE';
and the assembler code says:
Code: Select all
global SEGMENTATION_VIRTUAL_BASE
SEGMENTATION_VIRTUAL_BASE equ 0x40000000
For some reason the linker calls that value the symbols
address (this is only supposed to be done for linker symbols, I thought) and so I use @SegmentationVirtualBase to equal 0x40000000.
Re:Return of the triplefaulting paging - this time with attt
Posted: Sun Aug 21, 2005 2:42 pm
by Kim
Code: Select all
pascal:
var
SegmentationVirtualBase: longword; external name 'SEGMENTATION_VIRTUAL_BASE_PTR';
asm:
global SEGMENTATION_VIRTUAL_BASE_PTR
SEGMENTATION_VIRTUAL_BASE equ 0x40000000
section .data
SEGMENTATION_VIRTUAL_BASE_PTR:
dd SEGMENTATION_VIRTUAL_BASE
Re:Return of the triplefaulting paging - this time with attt
Posted: Sun Aug 21, 2005 4:56 pm
by Crazed123
OK, thanks, but how will that cure the triplefaulting?
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 1:23 am
by distantvoices
after loading the pagedir, you should do a ret to some label to flush tlb and other caches. Further, you won't need a patched gdt after enabling paging. (I'd add a constant to the addresses ere activating paging)
That's how it looks like in asm:
write_cr3:
push ebp
mov ebp,esp
mov eax,[ebp+8]
mov cr3,eax
push .1
ret
.1
pop ebp
ret
Hope this helps. If not, it might be useful to get hold of the approx. pos. in code where it triple faults. Place some print statements and getch()'s to trace throu the code.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 1:57 am
by Kim
I never read in the intel doc's about doing a ret to flush the tlb i thoughed using mov cr3 would flush it...
And why do a ret to a label when your function will ret to the caller.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 2:07 am
by distantvoices
That ret is used for the tlb flush.
As for intel docs: Need to check that. I can't comment on it currently as I don't know it by heart. Just this: the code I've posted is from an actually very well working OS. *gg* Guess which one.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 4:14 am
by Pype.Clicker
beyond infinity wrote:
That ret is used for the tlb flush.
That sounds weird to me too ...
- first you don't have to flush the TLB after a "mov CR3,eax", since reloading CR3 *do* flush the TLB (you can easily check out that we were suggested to use "mov eax,CR3 ; mov CR3,eax" to flush them before "INVLPG" instruction appeared on 486)
- i don't see how the cpu could guess that *this precise* 'RET' should flush TLBs and why other 'RETs' at the end of other functions don't do it. Imho, all it does is flushing the pipelines, forcing further instructions to be re-interpreted along new MMU rules if any effective address or fetch address has already been computed.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 4:56 am
by distantvoices
well, I've given it an empirical verification, and this gives the following results:
the ret-thing is needed after enabling paging and loading a page dir for the first time - as far as I can tell. have tested it here with vmware - and without the ret thing it simply refuses to work further.
all following cr3 loads need not be followed by a ret-thing. Tested too. OS boots up and runs pretty fine.
regrding the tlb stuff: Silly me, claiming something ere looking up stuff. Sorry for that.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 9:39 am
by Colonel Kernel
The "ret" thing probably serves the same purpose as the "jmp ecx" does here:
Code: Select all
_loader:
mov ecx, (BootPageDirectory - KERNEL_VIRTUAL_BASE)
mov cr3, ecx
mov ecx, cr4
or ecx, 0x00000010 ; Set PSE bit in CR4 to enable 4MB pages.
mov cr4, ecx
mov ecx, cr0
or ecx, 0x80000000 ; Set PG bit in CR0 to enable paging.
mov cr0, ecx
; Start fetching instructions in kernel space.
lea ecx, [StartInHigherHalf]
jmp ecx ; NOTE: Must be absolute jump!
StartInHigherHalf:
; Unmap the identity-mapped first 4MB of physical address
; space. It should not be needed anymore.
mov dword [BootPageDirectory], 0
invlpg [0]
I had to add that because otherwise EIP was still in the lower half when I unmapped it with invlpg.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 12:44 pm
by Crazed123
OK, the assembler portion of my SetPaging() function is now:
Code: Select all
asm
mov eax,reg
mov cr0,eax
push dword offset flush
ret
flush:
nop
end;
Hopefully that'll show up correctly, cause I can't type tabs inside this posting box to replace the spaces that might not get displayed.
Where reg is a variable containing the new value of cr0. I added ret'ing to a label here, and... it still triplefaults. Getting closer though, as traces show that the kernel gets up to setting the page directory in cr3 and THEN dies.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 1:05 pm
by Kim
Works fine for me without using ret to force a eip update.
Tested on bochs and some old pentium mmx. Could it be a vmware bug, or I am just lucky that for some strange reason it works for me.
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 1:37 pm
by Crazed123
OK, then how are you enabling paging?
Re:Return of the triplefaulting paging - this time with attt
Posted: Mon Aug 22, 2005 1:57 pm
by Kim
I attached my init section code. Its just some code linked at 1MB that enables paging and jumps to the kernel linked at 3GB.