bzt wrote:
This means you haven't mapped your code correctly, so as soon as you set the new paging table, the next instruction can't be fetched. Make sure that you map your kernel (at least this function and it's variables) at the same address as it's mapped in the old table. (In your case the PTE for ffffffff80102000 should point to the same physical page in the new table as in the old one, and the stack must be the same too to get the return address correctly.)
The thing you said about stack got me thinking - if the faulty instruction is iretq which stores the return address on top of the stack and the last exception has a physical address in CR2 - then maybe I just haven't mapped the stack and that is why an error occurs?
So now I have a couple of questions about this
- Could I read the SP register to get the address where the stack is stored, if physical then I would just map it to a virtual, if virtual then map it to a physical?
- Does the SP contain virtual/linear or physical address?
- If physical - is there a need for the stack to be mapped into virtual memory - the CPU operates on physical addresses and the stack is not accessed directly, but using the pop and push instructions instead?
Also:
When I dump the registers in qemu using qemu monitor(first I run of the page table reloading in the kernel so the OS runs without double faulting) "reg info" the address in SP is - 0xFFFFFFFF801116a8
The address in SP when I just use mov to get it is - 0xFFFFFFFF801116a0
The address in SP when I get it from exception(using qemu -d int) before reloading page tables - 0000000007ef4f38
After reloading tables it is - ffffffff80111630
What could be wrong with the SP?