From: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
To: Mauro Carvalho Chehab
<mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Rafael J. Wysocki"
<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Farhan Ali <alifm-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>,
kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>,
Halil Pasic <pasic-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
tboot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Alan Stern
<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
Boqun Feng <boqun.feng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Sean Paul <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
linux-wireless@v
Subject: Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst
Date: Tue, 23 Apr 2019 23:38:16 +0200 [thread overview]
Message-ID: <20190423213816.GE16353@zn.tnic> (raw)
In-Reply-To: <20190423170409.7b1370ac-qA1ZUp+OV9c@public.gmane.org>
On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote:
> That's my view about how that specific file would be after
> converted to ReST:
>
> https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames
>
> I don't have any troubles reading/understanding it as a plain text
> file,
If that is all the changes it would need, then I guess that's ok. Btw,
those rst-conversion patches don't really show what got changed. Dunno
if git can even show that properly. I diffed the two files by hand to
see what got changed, see end of mail.
So I guess if table in rst means, one needs to draw rows and columns, I
guess that's ok. It's not like I have to do it every day.
But exactly this - *having* to do rst formatting would mean a lot of
getting used to and people writing something which is not necessarily
correct rst and someone else fixing up after them.
Another pain point is changing the file paths. Without cscope I would've
been cursing each time I'm looking for kernel-parameters.txt, for
example. First of all, it is in Documentation/admin-guide/ now and then
there's Documentation/admin-guide/kernel-parameters.rst too.
I guess the .rst sucks in the .txt file and shows it monospaced. Oh
well.
So* I'd suggest having as less markup in those files as possible and if
it is needed, automate adding the needed markup, as Jon suggested.
The perfect example was the one which Peter gave and I had to paste in a
thread today:
"The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
:c:func:`kmem_cache_alloc` and"
That is very unreadable.
Anyway, stuff like that. Just giving my feedback here in case you're
interested. :-)
> and its html output is also nice (although Sphinx 1.7.8 seems to
> have some issues when parsing some cells - probably due to some bug):
>
> https://www.infradead.org/~mchehab/rst_conversion/x86/x86_64/mm.html
I don't know how that looks in your browser but in mine those addresses
are not in monospaced font and there's no properly reading them.
And yap, the cells parsing fun I see too.
> Changbin's approach was somewhat close to what you want. He simply
> prepended the tables with ::, in order to show them as plain old
> ascii:
>
> https://lore.kernel.org/lkml/20190423162932.21428-60-changbin.du-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
Yap, that's better.
I mean, the file is just as readable in plain old ASCII, if not even
more so. At least to me but I prefer simple things so...
>
> Both equally works, from ReST conversion PoV. I'm fine ether way.
>
> I prefer my approach, as, IMHO, it is visually nicer on both text and
> html versions, but his approach is likely easier to maintain, as doing
> ascii artwork by hand is sometimes painful.
Yap.
Thx.
---
--- mm.old 2019-04-23 23:18:55.954335784 +0200
+++ mm.new 2019-04-23 23:18:48.122335821 +0200
@@ -18,51 +18,68 @@ Notes:
notation than "16 EB", which few will recognize at first sight as 16 exabytes.
It also shows it nicely how incredibly large 64-bit address space is.
-========================================================================================================================
- Start addr | Offset | End addr | Size | VM area description
-========================================================================================================================
- | | | |
- 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
-__________________|____________|__________________|_________|___________________________________________________________
- | | | |
- 0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
- | | | | virtual memory addresses up to the -128 TB
- | | | | starting offset of kernel mappings.
-__________________|____________|__________________|_________|___________________________________________________________
- |
- | Kernel-space virtual memory, shared between all processes:
-____________________________________________________________|___________________________________________________________
- | | | |
- ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor
- ffff880000000000 | -120 TB | ffff887fffffffff | 0.5 TB | LDT remap for PTI
- ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base)
- ffffc88000000000 | -55.5 TB | ffffc8ffffffffff | 0.5 TB | ... unused hole
- ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)
- ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
- ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
- ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
- ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
-__________________|____________|__________________|_________|____________________________________________________________
- |
- | Identical layout to the 56-bit one from here on:
-____________________________________________________________|____________________________________________________________
- | | | |
- fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
- | | | | vaddr_end for KASLR
- fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
- fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
- ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
- ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
- ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
- ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
- ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
- ffffffff80000000 |-2048 MB | | |
- ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
- ffffffffff000000 | -16 MB | | |
- FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
- ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
- ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
-__________________|____________|__________________|_________|___________________________________________________________
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| Start addr | Offset | End addr | Size | VM area description |
++=================+============+==================+=========+===========================================================+
+| | | | | |
+|0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| | | | | |
+|0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical |
+| | | | | virtual memory addresses up to the -128 TB |
+| | | | | starting offset of kernel mappings. |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Kernel-space virtual memory, shared between all processes:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff880000000000 | -120 TB | ffff887fffffffff | 0.5 TB | LDT remap for PTI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffc88000000000 | -55.5 TB | ffffc8ffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Identical layout to the 56-bit one from here on:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole |
+| | | | | vaddr_end for KASLR |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0 |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 |-2048 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff000000 | -16 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
====================================================
@@ -76,51 +93,66 @@ Notes:
offset and many of the regions expand to support the much larger physical
memory supported.
-========================================================================================================================
- Start addr | Offset | End addr | Size | VM area description
-========================================================================================================================
- | | | |
- 0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm
-__________________|____________|__________________|_________|___________________________________________________________
- | | | |
- 0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical
- | | | | virtual memory addresses up to the -64 PB
- | | | | starting offset of kernel mappings.
-__________________|____________|__________________|_________|___________________________________________________________
- |
- | Kernel-space virtual memory, shared between all processes:
-____________________________________________________________|___________________________________________________________
- | | | |
- ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor
- ff10000000000000 | -60 PB | ff10ffffffffffff | 0.25 PB | LDT remap for PTI
- ff11000000000000 | -59.75 PB | ff90ffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base)
- ff91000000000000 | -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole
- ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base)
- ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
- ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
- ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
- ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
-__________________|____________|__________________|_________|____________________________________________________________
- |
- | Identical layout to the 47-bit one from here on:
-____________________________________________________________|____________________________________________________________
- | | | |
- fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
- | | | | vaddr_end for KASLR
- fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
- fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
- ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
- ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
- ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
- ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
- ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
- ffffffff80000000 |-2048 MB | | |
- ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
- ffffffffff000000 | -16 MB | | |
- FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
- ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
- ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
-__________________|____________|__________________|_________|___________________________________________________________
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| Start addr | Offset | End addr | Size | VM area description |
++=================+============+==================+=========+===========================================================+
+|0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical |
+| | | | | virtual memory addresses up to the -64 PB |
+| | | | | starting offset of kernel mappings. |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Kernel-space virtual memory, shared between all processes:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff10000000000000 | -60 PB | ff10ffffffffffff | 0.25 PB | LDT remap for PTI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff11000000000000 | -59.75 PB | ff90ffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff91000000000000 | -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Identical layout to the 47-bit one from here on:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole |
+| | | | | vaddr_end for KASLR |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0 |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 |-2048 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff000000 | -16 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffffe00000 | -2 MB | 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
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "Mike Snitzer" <snitzer@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Farhan Ali" <alifm@linux.ibm.com>,
"Will Deacon" <will.deacon@arm.com>,
dri-devel@lists.freedesktop.org,
"Jaroslav Kysela" <perex@perex.cz>,
kernel-hardening@lists.openwall.com,
"Christoph Hellwig" <hch@lst.de>,
linux-arch@vger.kernel.org, linux-sh@vger.kernel.org,
"James Morris" <jmorris@namei.org>,
"Halil Pasic" <pasic@linux.ibm.com>,
tboot-devel@lists.sourceforge.net,
"Alan Stern" <stern@rowland.harvard.edu>,
openipmi-developer@lists.sourceforge.net,
"Guenter Roeck" <linux@roeck-us.net>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Matt Mackall" <mpm@selenic.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Sean Paul" <sean@poorly.run>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org,
"Mark Rutland" <mark.rutland@arm.com>,
linux-fbdev@vger.kernel.org, linux-ia64@vger.kernel.org,
"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
"David Airlie" <airlied@linux.ie>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
dm-devel@redhat.com, "Harry Wei" <harryxiyou@gmail.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Alasdair Kergon" <agk@redhat.com>,
linux-s390@vger.kernel.org,
"Alex Shi" <alex.shi@linux.alibaba.com>,
"Yoshinori Sato" <ysato@users.sourceforge.jp>,
"Helge Deller" <deller@gmx.de>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
"Changbin Du" <changbin.du@gmail.com>,
"Eric Farman" <farman@linux.ibm.com>,
linux-watchdog@vger.kernel.org, "Corey Minyard" <minyard@acm.org>,
"Mauro Carvalho Chehab" <mchehab@infradead.org>,
linaro-mm-sig@lists.linaro.org, linux-gpio@vger.kernel.org,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org,
"Tony Luck" <tony.luck@intel.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
"Andrea Parri" <andrea.parri@amarulasolutions.com>,
linux-pci@vger.kernel.org, "Akira Yokosawa" <akiyks@gmail.com>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
platform-driver-x86@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Kishon Vijay Abraham I" <kishon@ti.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Emese Revfy" <re.emese@gmail.com>,
"Darren Hart" <dvhart@infradead.org>,
"Jade Alglave" <j.alglave@ucl.ac.uk>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Fenghua Yu" <fenghua.yu@intel.com>,
"Kees Cook" <keescook@chromium.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
"Ning Sun" <ning.sun@intel.com>,
"Luc Maranget" <luc.maranget@inria.fr>,
"Kurt Schwemmer" <kurt.schwemmer@microsemi.com>,
"Guan Xuetao" <gxt@pku.edu.cn>,
linux-parisc@vger.kernel.org, iommu@lists.linux-foundation.org,
"Stuart Hayes" <stuart.w.hayes@gmail.com>,
"Logan Gunthorpe" <logang@deltatee.com>,
"Andreas Färber" <afaerber@suse.de>,
"Rich Felker" <dalias@libc.org>,
kvm@vger.kernel.org, "Maxime Ripard" <maxime.ripard@bootlin.com>,
"Jerry Hoemann" <jerry.hoemann@hpe.com>,
"David Howells" <dhowells@redhat.com>,
linux-mm@kvack.org, "Kirti Wankhede" <kwankhede@nvidia.com>,
"H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org,
"Steffen Klassert" <steffen.klassert@secunet.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
x86@kernel.org, "Russell King" <linux@armlinux.org.uk>,
"Ingo Molnar" <mingo@redhat.com>,
devicetree@vger.kernel.org, "Daniel Lustig" <dlustig@nvidia.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
linux-block@vger.kernel.org, "Rob Herring" <robh+dt@kernel.org>,
"Wim Van Sebroeck" <wim@linux-watchdog.org>,
"Jens Axboe" <axboe@kernel.dk>,
netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
"Daniel Vetter" <daniel@ffwll.ch>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Robin Murphy" <robin.murphy@arm.com>,
"Andy Shevchenko" <andy@infradead.org>
Subject: Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst
Date: Tue, 23 Apr 2019 23:38:16 +0200 [thread overview]
Message-ID: <20190423213816.GE16353@zn.tnic> (raw)
Message-ID: <20190423213816.I1aOfjDEZBgrTzrIf1d9yYXVrBfoQ8AFzYcHpxq3_sw@z> (raw)
In-Reply-To: <20190423170409.7b1370ac@coco.lan>
On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote:
> That's my view about how that specific file would be after
> converted to ReST:
>
> https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames
>
> I don't have any troubles reading/understanding it as a plain text
> file,
If that is all the changes it would need, then I guess that's ok. Btw,
those rst-conversion patches don't really show what got changed. Dunno
if git can even show that properly. I diffed the two files by hand to
see what got changed, see end of mail.
So I guess if table in rst means, one needs to draw rows and columns, I
guess that's ok. It's not like I have to do it every day.
But exactly this - *having* to do rst formatting would mean a lot of
getting used to and people writing something which is not necessarily
correct rst and someone else fixing up after them.
Another pain point is changing the file paths. Without cscope I would've
been cursing each time I'm looking for kernel-parameters.txt, for
example. First of all, it is in Documentation/admin-guide/ now and then
there's Documentation/admin-guide/kernel-parameters.rst too.
I guess the .rst sucks in the .txt file and shows it monospaced. Oh
well.
So* I'd suggest having as less markup in those files as possible and if
it is needed, automate adding the needed markup, as Jon suggested.
The perfect example was the one which Peter gave and I had to paste in a
thread today:
"The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`,
:c:func:`kmem_cache_alloc` and"
That is very unreadable.
Anyway, stuff like that. Just giving my feedback here in case you're
interested. :-)
> and its html output is also nice (although Sphinx 1.7.8 seems to
> have some issues when parsing some cells - probably due to some bug):
>
> https://www.infradead.org/~mchehab/rst_conversion/x86/x86_64/mm.html
I don't know how that looks in your browser but in mine those addresses
are not in monospaced font and there's no properly reading them.
And yap, the cells parsing fun I see too.
> Changbin's approach was somewhat close to what you want. He simply
> prepended the tables with ::, in order to show them as plain old
> ascii:
>
> https://lore.kernel.org/lkml/20190423162932.21428-60-changbin.du@gmail.com/
Yap, that's better.
I mean, the file is just as readable in plain old ASCII, if not even
more so. At least to me but I prefer simple things so...
>
> Both equally works, from ReST conversion PoV. I'm fine ether way.
>
> I prefer my approach, as, IMHO, it is visually nicer on both text and
> html versions, but his approach is likely easier to maintain, as doing
> ascii artwork by hand is sometimes painful.
Yap.
Thx.
---
--- mm.old 2019-04-23 23:18:55.954335784 +0200
+++ mm.new 2019-04-23 23:18:48.122335821 +0200
@@ -18,51 +18,68 @@ Notes:
notation than "16 EB", which few will recognize at first sight as 16 exabytes.
It also shows it nicely how incredibly large 64-bit address space is.
-========================================================================================================================
- Start addr | Offset | End addr | Size | VM area description
-========================================================================================================================
- | | | |
- 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
-__________________|____________|__________________|_________|___________________________________________________________
- | | | |
- 0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
- | | | | virtual memory addresses up to the -128 TB
- | | | | starting offset of kernel mappings.
-__________________|____________|__________________|_________|___________________________________________________________
- |
- | Kernel-space virtual memory, shared between all processes:
-____________________________________________________________|___________________________________________________________
- | | | |
- ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor
- ffff880000000000 | -120 TB | ffff887fffffffff | 0.5 TB | LDT remap for PTI
- ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base)
- ffffc88000000000 | -55.5 TB | ffffc8ffffffffff | 0.5 TB | ... unused hole
- ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)
- ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
- ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
- ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
- ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
-__________________|____________|__________________|_________|____________________________________________________________
- |
- | Identical layout to the 56-bit one from here on:
-____________________________________________________________|____________________________________________________________
- | | | |
- fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
- | | | | vaddr_end for KASLR
- fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
- fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
- ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
- ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
- ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
- ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
- ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
- ffffffff80000000 |-2048 MB | | |
- ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
- ffffffffff000000 | -16 MB | | |
- FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
- ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
- ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
-__________________|____________|__________________|_________|___________________________________________________________
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| Start addr | Offset | End addr | Size | VM area description |
++=================+============+==================+=========+===========================================================+
+| | | | | |
+|0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| | | | | |
+|0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical |
+| | | | | virtual memory addresses up to the -128 TB |
+| | | | | starting offset of kernel mappings. |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Kernel-space virtual memory, shared between all processes:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff880000000000 | -120 TB | ffff887fffffffff | 0.5 TB | LDT remap for PTI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffc88000000000 | -55.5 TB | ffffc8ffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Identical layout to the 56-bit one from here on:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole |
+| | | | | vaddr_end for KASLR |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0 |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 |-2048 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff000000 | -16 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
====================================================
@@ -76,51 +93,66 @@ Notes:
offset and many of the regions expand to support the much larger physical
memory supported.
-========================================================================================================================
- Start addr | Offset | End addr | Size | VM area description
-========================================================================================================================
- | | | |
- 0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm
-__________________|____________|__________________|_________|___________________________________________________________
- | | | |
- 0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical
- | | | | virtual memory addresses up to the -64 PB
- | | | | starting offset of kernel mappings.
-__________________|____________|__________________|_________|___________________________________________________________
- |
- | Kernel-space virtual memory, shared between all processes:
-____________________________________________________________|___________________________________________________________
- | | | |
- ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor
- ff10000000000000 | -60 PB | ff10ffffffffffff | 0.25 PB | LDT remap for PTI
- ff11000000000000 | -59.75 PB | ff90ffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base)
- ff91000000000000 | -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole
- ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base)
- ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
- ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
- ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
- ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
-__________________|____________|__________________|_________|____________________________________________________________
- |
- | Identical layout to the 47-bit one from here on:
-____________________________________________________________|____________________________________________________________
- | | | |
- fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
- | | | | vaddr_end for KASLR
- fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
- fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
- ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
- ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
- ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
- ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
- ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
- ffffffff80000000 |-2048 MB | | |
- ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
- ffffffffff000000 | -16 MB | | |
- FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
- ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
- ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
-__________________|____________|__________________|_________|___________________________________________________________
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| Start addr | Offset | End addr | Size | VM area description |
++=================+============+==================+=========+===========================================================+
+|0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical |
+| | | | | virtual memory addresses up to the -64 PB |
+| | | | | starting offset of kernel mappings. |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Kernel-space virtual memory, shared between all processes:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff10000000000000 | -60 PB | ff10ffffffffffff | 0.25 PB | LDT remap for PTI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff11000000000000 | -59.75 PB | ff90ffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ff91000000000000 | -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base) |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| **Identical layout to the 47-bit one from here on:** |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole |
+| | | | | vaddr_end for KASLR |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0 |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffff80000000 |-2048 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff000000 | -16 MB | | | |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+| FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI |
++-----------------+------------+------------------+---------+-----------------------------------------------------------+
+|ffffffffffe00000 | -2 MB | 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
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-04-23 21:38 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1555938375.git.mchehab+samsung@kernel.org>
[not found] ` <cover.1555938375.git.mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2019-04-22 13:27 ` [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst Mauro Carvalho Chehab
2019-04-22 13:27 ` Mauro Carvalho Chehab
[not found] ` <cda57849a6462ccc72dcd360b30068ab6a1021c4.1555938376.git.mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2019-04-22 16:37 ` Logan Gunthorpe
2019-04-22 16:37 ` Logan Gunthorpe
2019-04-23 8:31 ` Peter Zijlstra
2019-04-23 8:31 ` Peter Zijlstra
[not found] ` <20190423083135.GA11158-Nxj+rRp3nVydTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2019-04-23 12:55 ` Mike Snitzer
2019-04-23 12:55 ` Mike Snitzer
[not found] ` <20190423125519.GA7104-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-04-23 13:01 ` Peter Zijlstra
2019-04-23 13:01 ` Peter Zijlstra
[not found] ` <20190423130132.GT4038-Nxj+rRp3nVydTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2019-04-23 13:21 ` Mike Snitzer
2019-04-23 13:21 ` Mike Snitzer
[not found] ` <20190423132100.GB7132-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-04-23 15:07 ` Mauro Carvalho Chehab
2019-04-23 15:07 ` Mauro Carvalho Chehab
2019-04-23 16:30 ` Jonathan Corbet
2019-04-23 16:30 ` Jonathan Corbet
[not found] ` <20190423103053.07cf2149-T1hC0tSOHrs@public.gmane.org>
2019-04-23 17:11 ` Peter Zijlstra
2019-04-23 17:11 ` Peter Zijlstra
[not found] ` <20190423171158.GG12232-Nxj+rRp3nVydTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2019-04-23 17:20 ` Borislav Petkov
2019-04-23 17:20 ` Borislav Petkov
[not found] ` <20190423172006.GD16353-Jj63ApZU6fQ@public.gmane.org>
2019-04-23 20:05 ` Mauro Carvalho Chehab
2019-04-23 20:05 ` Mauro Carvalho Chehab
[not found] ` <20190423170409.7b1370ac-qA1ZUp+OV9c@public.gmane.org>
2019-04-23 21:38 ` Borislav Petkov [this message]
2019-04-23 21:38 ` Borislav Petkov
[not found] ` <20190423213816.GE16353-Jj63ApZU6fQ@public.gmane.org>
2019-04-23 22:06 ` Jonathan Corbet
2019-04-23 22:06 ` Jonathan Corbet
[not found] ` <20190423160640.70c9703f-T1hC0tSOHrs@public.gmane.org>
2019-04-24 9:19 ` Borislav Petkov
2019-04-24 9:19 ` Borislav Petkov
2019-04-24 6:52 ` Peter Zijlstra
2019-04-24 6:52 ` Peter Zijlstra
2019-05-06 19:50 ` Mauro Carvalho Chehab
2019-04-24 10:40 ` Mauro Carvalho Chehab
2019-04-24 10:40 ` Mauro Carvalho Chehab
[not found] ` <20190423232325.679c100b-qA1ZUp+OV9c@public.gmane.org>
2019-04-24 14:54 ` Borislav Petkov
2019-04-24 14:54 ` Borislav Petkov
[not found] ` <20190424145410.GE30142-Jj63ApZU6fQ@public.gmane.org>
2019-04-24 16:36 ` Mauro Carvalho Chehab
2019-04-24 16:36 ` Mauro Carvalho Chehab
2019-04-23 17:53 ` Jonathan Corbet
2019-04-23 17:53 ` Jonathan Corbet
[not found] ` <20190423115349.589c3d50-T1hC0tSOHrs@public.gmane.org>
2019-04-23 18:21 ` Peter Zijlstra
2019-04-23 18:21 ` Peter Zijlstra
2019-04-23 20:19 ` Mauro Carvalho Chehab
2019-04-23 20:19 ` Mauro Carvalho Chehab
[not found] ` <20190423171944.7ac6db54-qA1ZUp+OV9c@public.gmane.org>
2019-04-23 20:34 ` Jonathan Corbet
2019-04-23 20:34 ` Jonathan Corbet
2019-04-23 17:13 ` Wes Turner
2019-04-23 17:13 ` Wes Turner
[not found] ` <CACfEFw-viqBH7tDJ8t_um5erPFnRmzuztux86+3XR0+e=YcYYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-04-23 17:41 ` Peter Zijlstra
2019-04-23 17:41 ` Peter Zijlstra
2019-04-23 17:28 ` Wes Turner
2019-04-23 17:28 ` Wes Turner
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=20190423213816.GE16353@zn.tnic \
--to=bp-gina5biwoiwzqb+pc5nmwq@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=alifm-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org \
--cc=boqun.feng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org \
--cc=kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-wireless@v \
--cc=mchehab+samsung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org \
--cc=npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=pasic-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org \
--cc=perex-/Fr2/VpizcU@public.gmane.org \
--cc=rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org \
--cc=snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
--cc=tboot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox