What is the state of page tables after kexec’ing into an ELF x86_64 binary?

I’m kexec’ing into a binary i wrote compiled to an x86_64 ELF. It runs fine.

Since it’s a 64-bit binary, i know the processor must be in 64-bit long mode. Which requires paging to be used, so I know paging must be turned on.

My question is, what is the state of these page tables? Is there some area, such as my loaded binary, that is guaranteed to be identity mapped? Is all of available RAM identity mapped? Since paging is enabled, where are the pages?

After kexec’ing I would like to identity map the entire address space. To do this i would need to build some page table structures at an address that i know the physical address to, and then write the address of that structure into CR3.

If i knew that the elf binary loaded into memory is identity mapped, I could build the page tables in there statically and then make the switch seamlessly. If there are no identity mapped pages after kexec, I’ll need to turn off paging, drop out of long mode, and set it up, and then re-enter long 64-bit mode.

Thanks!

Answer

The parts of the kexec process specific to x86-64 are handled in arch/x86/kernel/machine_kexec_64.c.

In short: the kernel allocates a page table, and the init_pgtable function initialises it to be identity mapping. So yes, your scheme should work.