OSDev.org

Hi,

So I'm trying to break things way down for my understanding, and I do need some help.

I have successfully loaded a test "kernel" trough UEFI and I understand the memory map that I'm getting from UEFI and what I need to be aware off regards this.

However I would like to make a "simple" test, to create my own page table and change the page table set by UEFI to my own, where I map the location of my loaded test kernel to virtual address 0 (and also wants to map the screen buffer to an address such that I can write something to the screen).

I have code to create a page table from when I boot with BIOS which work, but when I try to do more or less the same after UEFI,
then when i try to move the address of PML4 into cr3, the system just ends up rebooting.
(I guess triple fault? or? )

So I guess my starting question would be why the move instruction to cr3 immediately can caused a reboot?
I have no clue at this point, and I have done cli hlt rigth after the move instruction, so the reboot should(?) not be cause by a following bad reference.
Is it because that I mess up the interrupt handlers from UEFI?

Hope that someone can point my in a direction.

Do you have an identity map available for the instruction that switches CR3? UEFI will identity map all memory you request, so the code which switches CR3 will also be identity mapped. It needs to be identity mapped in your structures as well, otherwise switching CR3 is what is called an implicit jump, and that is not supported in any architecture I am aware of. In your case, the address at which CR3 is switched is probably not mapped at all, causing a page fault, which cannot be handled until the kernel is running, so everything dies with triple fault.

More generally, whenever CR3 is switched, the virtual address at which the "mov cr3" instruction is loaded must map to the same physical address in both address spaces.

ahh ffs... I was reading about this just a couple of days ago.

I have an idea now what to try, I will see if this will work out.
Thanks!

Just to close this off, it was the thing that nullplan said

that caused the trouble.

The code was now located in a place that where mapped in both address spaces, and it now works.