All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Baoquan He <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: hpa@zytor.com, riel@surriel.com, luto@amacapital.net,
	luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com,
	peterz@infradead.org, tglx@linutronix.de, dvlasenk@redhat.com,
	mingo@kernel.org, torvalds@linux-foundation.org,
	brgerst@gmail.com, linux-kernel@vger.kernel.org, bhe@redhat.com
Subject: [tip:x86/mm] x86/mm/doc: Clean up the x86-64 virtual memory layout descriptions
Date: Sat, 6 Oct 2018 06:07:29 -0700	[thread overview]
Message-ID: <tip-5b12904065798fee8b153a506ac7b72d5ebbe26c@git.kernel.org> (raw)
In-Reply-To: <20181006084327.27467-3-bhe@redhat.com>

Commit-ID:  5b12904065798fee8b153a506ac7b72d5ebbe26c
Gitweb:     https://git.kernel.org/tip/5b12904065798fee8b153a506ac7b72d5ebbe26c
Author:     Baoquan He <bhe@redhat.com>
AuthorDate: Sat, 6 Oct 2018 16:43:26 +0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 6 Oct 2018 14:46:47 +0200

x86/mm/doc: Clean up the x86-64 virtual memory layout descriptions

In Documentation/x86/x86_64/mm.txt, the description of the x86-64 virtual
memory layout has become a confusing hodgepodge of inconsistencies:

 - there's a hard to read mixture of 'TB' and 'bits' notation
 - the entries sometimes mention a size in the description and sometimes not
 - sometimes they list holes by address, sometimes only as an 'unused hole' line

So make it all a coherent, readable, well organized description.

Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: corbet@lwn.net
Cc: linux-doc@vger.kernel.org
Cc: thgarnie@google.com
Link: http://lkml.kernel.org/r/20181006084327.27467-3-bhe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 Documentation/x86/x86_64/mm.txt | 84 ++++++++++++++++++++---------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5432a96d31ff..b4bc95c9790e 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -1,55 +1,55 @@
 
 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
-ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
-ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
-ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
-ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
-ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
-... unused hole ...
-ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
-... unused hole ...
+0000000000000000 - 00007fffffffffff (=47 bits,   128 TB) user space, different per mm
+				    hole caused by [47:63] sign extension
+ffff800000000000 - ffff87ffffffffff (=43 bits,     8 TB) guard hole, reserved for hypervisor
+ffff880000000000 - ffffc7ffffffffff (=46 bits,    64 TB) direct mapping of all phys. memory (page_offset_base)
+ffffc80000000000 - ffffc8ffffffffff (=40 bits,     1 TB) unused hole
+ffffc90000000000 - ffffe8ffffffffff (=45 bits,    32 TB) vmalloc/ioremap space (vmalloc_base)
+ffffe90000000000 - ffffe9ffffffffff (=40 bits,     1 TB) unused hole
+ffffea0000000000 - ffffeaffffffffff (=40 bits,     1 TB) virtual memory map (vmemmap_base)
+ffffeb0000000000 - ffffebffffffffff (=40 bits,     1 TB) unused hole
+ffffec0000000000 - fffffbffffffffff (=44 bits,    16 TB) kasan shadow memory
+fffffc0000000000 - fffffdffffffffff (=41 bits,     2 TB) unused hole
 				    vaddr_end for KASLR
-fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
-fffffe8000000000 - fffffeffffffffff (=39 bits) LDT remap for PTI
-ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
-... unused hole ...
-ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
-... unused hole ...
-ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
+fffffe0000000000 - fffffe7fffffffff (=39 bits,   512 GB) cpu_entry_area mapping
+fffffe8000000000 - fffffeffffffffff (=39 bits,   512 GB) LDT remap for PTI
+ffffff0000000000 - ffffff7fffffffff (=39 bits,   512 GB) %esp fixup stacks
+ffffff8000000000 - fffffffeefffffff (~39 bits,  ~507 GB) unused hole
+ffffffef00000000 - fffffffeffffffff (=36 bits,    64 GB) EFI region mapping space
+ffffffff00000000 - ffffffff7fffffff (=31 bits,     2 GB) unused hole
+ffffffff80000000 - ffffffff9fffffff (=29 bits,   512 MB) kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffeffffff (~31 bits,  1520 MB) module mapping space
 [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
-ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
-ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
+ffffffffff600000 - ffffffffff600fff (             =4 kB) legacy vsyscall ABI
+ffffffffffe00000 - ffffffffffffffff (             =2 MB) unused hole
 
 Virtual memory map with 5 level page tables:
 
-0000000000000000 - 00ffffffffffffff (=56 bits) user space, different per mm
-hole caused by [56:63] sign extension
-ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
-ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
-ff90000000000000 - ff9fffffffffffff (=52 bits) LDT remap for PTI
-ffa0000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space (12800 TB)
-ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole
-ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
-... unused hole ...
-ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB)
-... unused hole ...
+0000000000000000 - 00ffffffffffffff (=56 bits,    64 PB) user space, different per mm
+				    hole caused by [56:63] sign extension
+ff00000000000000 - ff0fffffffffffff (=52 bits,     4 PB) guard hole, reserved for hypervisor
+ff10000000000000 - ff8fffffffffffff (=55 bits,    32 PB) direct mapping of all phys. memory (page_offset_base)
+ff90000000000000 - ff9fffffffffffff (=52 bits,     4 PB) LDT remap for PTI
+ffa0000000000000 - ffd1ffffffffffff (=53 bits, 12800 TB) vmalloc/ioremap space (vmalloc_base)
+ffd2000000000000 - ffd3ffffffffffff (=49 bits,   512 TB) unused hole
+ffd4000000000000 - ffd5ffffffffffff (=49 bits,   512 TB) virtual memory map (vmemmap_base)
+ffd6000000000000 - ffdeffffffffffff (~51 bits,  2304 TB) unused hole
+ffdf000000000000 - fffffdffffffffff (~53 bits,    ~8 PB) kasan shadow memory
+fffffc0000000000 - fffffdffffffffff (=41 bits,     2 TB) unused hole
 				    vaddr_end for KASLR
-fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping
-... unused hole ...
-ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
-... unused hole ...
-ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
-... unused hole ...
-ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
+fffffe0000000000 - fffffe7fffffffff (=39 bits,   512 GB) cpu_entry_area mapping
+fffffe8000000000 - fffffeffffffffff (=39 bits,   512 GB) unused hole
+ffffff0000000000 - ffffff7fffffffff (=39 bits,   512 GB) %esp fixup stacks
+ffffff8000000000 - ffffffeeffffffff (~39 bits,   444 GB) unused hole
+ffffffef00000000 - fffffffeffffffff (=36 bits,    64 GB) EFI region mapping space
+ffffffff00000000 - ffffffff7fffffff (31 bits,      2 GB) unused hole
+ffffffff80000000 - ffffffff9fffffff (=29 bits,   512 MB) kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffeffffff (~31 bits,  1520 MB) module mapping space
 [fixmap start]   - ffffffffff5fffff kernel-internal fixmap range
-ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
-ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
+ffffffffff600000 - ffffffffff600fff (             =4 kB) legacy vsyscall ABI
+ffffffffffe00000 - ffffffffffffffff (             =2 MB) unused hole
 
 Architecture defines a 64-bit virtual address. Implementations can support
 less. Currently supported are 48- and 57-bit virtual addresses. Bits 63

  reply	other threads:[~2018-10-06 13:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-06  8:43 [PATCH 0/3] x86/mm/doc: Clean up mm.txt Baoquan He
2018-10-06  8:43 ` [PATCH 1/3] x86/KASLR: Update KERNEL_IMAGE_SIZE description Baoquan He
2018-10-06 13:06   ` [tip:x86/mm] " tip-bot for Baoquan He
2018-10-06  8:43 ` [PATCH 2/3] x86/mm/doc: Clean up the memory region layout descriptions Baoquan He
2018-10-06 13:07   ` tip-bot for Baoquan He [this message]
2018-10-06  8:43 ` [PATCH 3/3] x86/doc/kaslr.txt: Create a separate part of document abourt KASLR at the end of file Baoquan He
2018-10-06 11:28 ` [PATCH 0/3] x86/mm/doc: Clean up mm.txt Baoquan He
2018-10-06 12:21 ` Ingo Molnar
2018-10-06 12:22 ` [PATCH 4/3] x86/mm/doc: Enhance the x86-64 virtual memory layout descriptions Ingo Molnar
2018-10-06 12:33   ` Ingo Molnar
2018-10-06 14:41     ` Baoquan He
2018-10-06 14:38   ` [PATCH 4/3 v2] " Ingo Molnar
2018-10-06 15:02     ` Baoquan He
2018-10-06 17:03     ` Ingo Molnar
2018-10-06 22:17       ` Andy Lutomirski
2018-10-09  0:35         ` Baoquan He
2018-10-09  4:48           ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tip-5b12904065798fee8b153a506ac7b72d5ebbe26c@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.