* Virtual Memory map
@ 2017-12-12 19:14 Damian Tometzki
2017-12-13 2:59 ` valdis.kletnieks at vt.edu
2017-12-13 4:35 ` arshad hussain
0 siblings, 2 replies; 6+ messages in thread
From: Damian Tometzki @ 2017-12-12 19:14 UTC (permalink / raw)
To: kernelnewbies
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171212/52979c8d/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Virtual Memory map
2017-12-12 19:14 Virtual Memory map Damian Tometzki
@ 2017-12-13 2:59 ` valdis.kletnieks at vt.edu
2017-12-13 4:35 ` arshad hussain
1 sibling, 0 replies; 6+ messages in thread
From: valdis.kletnieks at vt.edu @ 2017-12-13 2:59 UTC (permalink / raw)
To: kernelnewbies
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171212/3820bd11/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Virtual Memory map
2017-12-12 19:14 Virtual Memory map Damian Tometzki
2017-12-13 2:59 ` valdis.kletnieks at vt.edu
@ 2017-12-13 4:35 ` arshad hussain
2017-12-13 8:28 ` Damian Tometzki
1 sibling, 1 reply; 6+ messages in thread
From: arshad hussain @ 2017-12-13 4:35 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Virtual Memory map
2017-12-13 4:35 ` arshad hussain
@ 2017-12-13 8:28 ` Damian Tometzki
2017-12-13 10:44 ` arshad hussain
0 siblings, 1 reply; 6+ messages in thread
From: Damian Tometzki @ 2017-12-13 8:28 UTC (permalink / raw)
To: kernelnewbies
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171213/f0c5a54e/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Virtual Memory map
2017-12-13 8:28 ` Damian Tometzki
@ 2017-12-13 10:44 ` arshad hussain
0 siblings, 0 replies; 6+ messages in thread
From: arshad hussain @ 2017-12-13 10:44 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Virtual Memory Map
@ 2017-12-12 20:18 Damian Tometzki
0 siblings, 0 replies; 6+ messages in thread
From: Damian Tometzki @ 2017-12-12 20:18 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-12-13 10:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-12 19:14 Virtual Memory map Damian Tometzki
2017-12-13 2:59 ` valdis.kletnieks at vt.edu
2017-12-13 4:35 ` arshad hussain
2017-12-13 8:28 ` Damian Tometzki
2017-12-13 10:44 ` arshad hussain
2017-12-12 20:18 Virtual Memory Map Damian Tometzki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.