Hello all, i have a short question: How are the bits (in brackets) calculated in the virtual memory map ? for example the first line (=47 bits) Virtual memory map with 4 level page tables: 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [47:63] sign extension ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor Best regards Damian
On Tue, 12 Dec 2017 20:14:35 +0100, Damian Tometzki said:
How are the bits (in brackets) calculated in the virtual memory map ?
For x86_64 architecture, the 47 comes from the fact that currently shipping CPUs have an architected 48 bit wide memory address bus, and the fact that Linux does a "userspace lower half, kernel upper half" division of the address space. Recently, a patch for 5-level page tables went it, to support upcoming hardware that provides hardware support for 56-bit memory address buses.
On Wed, Dec 13, 2017 at 12:44 AM, Damian Tometzki <damian.tometzki@icloud.com> wrote:
Hello all,
i have a short question:
How are the bits (in brackets) calculated in the virtual memory map ?
for example the first line (=47 bits)
Virtual memory map with 4 level page tables:
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [47:63] sign extension ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
Presently for x86-64 kernel uses 4-level paging. Out of 64bit only 48 bit is enabled (Which boils down to Terabyte of address space). For case where getpagesize() is 4K the breakup is :- CR3 -> Global(9 bits) -> Upper(9 bits) -> Middle(9 bits) -> Page table(9 bits) -> [12 bits for page or 4096 bytes] = (48 bits) Thanks
Hello, On more question. The second example:
ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
What are the relation between the Bits (=43bits) and the Adresse Range ? Is it possible to calculate the 43 Bits from the range ? If yes, how ? Best regards Damian
Am 13.12.2017 um 05:35 schrieb arshad hussain <arshad.super@gmail.com>:
On Wed, Dec 13, 2017 at 12:44 AM, Damian Tometzki <damian.tometzki@icloud.com> wrote:
Hello all,
i have a short question:
How are the bits (in brackets) calculated in the virtual memory map ?
for example the first line (=47 bits)
Virtual memory map with 4 level page tables:
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [47:63] sign extension ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
Presently for x86-64 kernel uses 4-level paging. Out of 64bit only 48 bit is enabled (Which boils down to Terabyte of address space). For case where getpagesize() is 4K the breakup is :-
CR3 -> Global(9 bits) -> Upper(9 bits) -> Middle(9 bits) -> Page table(9 bits) -> [12 bits for page or 4096 bytes] = (48 bits)
Thanks
On Wed, Dec 13, 2017 at 1:58 PM, Damian Tometzki <damian.tometzki@icloud.com> wrote:
Hello,
On more question. The second example:
ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
What are the relation between the Bits (=43bits) and the Adresse Range ?
If user-space stars and ends on 0x000000000000000 - 0x00007fffffffffff. And kernel space starts and ends on 0xffff8000000000 - 0xffffffffffffffff. Then this lines means
ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
That guard hole is part of kernel address space. Which starts at ffff800000000000 and ends at ffff87ffffffffff. The '=43' is the hint that ffff87ffffffffff - ffff800000000000 = 43bits. Valdis has already answered regarding the "upper kernel half" when 48th bit is sign extended and are all 1's. And "lower user half' where the bits are all 0. Please do read more about canonical and non-canonical address.
Is it possible to calculate the 43 Bits from the range ? If yes, how ?
Not sure I understood the question. Maybe the above answer would help. Thanks
participants (3)
-
arshad hussain -
Damian Tometzki -
valdis.kletnieks＠vt.edu