Page 2 of 2

Re: Example Higher Half x86_64 kernel @ -2GB

Posted: Thu Apr 20, 2017 11:22 am
by Velko
I was also tinkering with same thing (move kernel to -2 GiB addresses) lately.

It causes interesting consequences if you're using Recursive mapping. The last 512 GiB of address space is reserved for paging tables. Better not try to sneak a kernel code in there, you have to move paging structures somewhere else first.

Fortunately, there is no technical restrictions on which entry of PML4T can be used for recursive mapping. We are using last one because it is convenient (PML4T is located @ -4KiB, PDPTs @ -2 MiB, PDs @ -1GiB and PTs @ -512GiB). Any entry will do, but table offset calculations get... complicated.

Here's a simplified model of recursive paging tables with only 4 entries per table and 3 levels, demonstrating how things move around:
ptables.png
ptables.png (3.06 KiB) Viewed 952 times
I was at complete loss :oops: until I drew this. Sharing, just in case someone finds it useful.

Re: Example Higher Half x86_64 kernel @ -2GB

Posted: Thu Apr 20, 2017 12:05 pm
by proxy
Velko wrote:I was also tinkering with same thing (move kernel to -2 GiB addresses) lately.

It causes interesting consequences if you're using Recursive mapping. The last 512 GiB of address space is reserved for paging tables. Better not try to sneak a kernel code in there, you have to move paging structures somewhere else first.

Fortunately, there is no technical restrictions on which entry of PML4T can be used for recursive mapping. We are using last one because it is convenient (PML4T is located @ -4KiB, PDPTs @ -2 MiB, PDs @ -1GiB and PTs @ -512GiB). Any entry will do, but table offset calculations get... complicated.
Right, the way that I've chosen to view it, is that the recursive mapping can go into one of 512 "slots", each occupying 512GB of address space. For my -2GB mapped kernel, I just put the recursive mapping in the second to last slot :-). Easy once you look at it that way (at least for me)