Em Wed, 24 Apr 2019 08:52:09 +0200
Peter Zijlstra <[email protected]> escreveu:
> On Tue, Apr 23, 2019 at 11:38:16PM +0200, Borislav Petkov wrote:
> > 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.
>
> That is not a happy diff; that table has gotten waay worse to read due
> to all that extra table crap.
Not that I'm proposing such change, but, as a reference, I just discovered
today that there's a way to make it even lighter than it is while still
showing it as a table:
================= ======== == ================ ===== ==
===========================================================
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
================= ======== == ================ ===== ==
===========================================================
If one wants the table headers as such, an extra line is required:
================= ======== == ================ ===== ==
===========================================================
Start addr Offset End addr Size VM area description
----------------- ----------- ---------------- --------
-----------------------------------------------------------
================= ======== == ================ ===== ==
===========================================================
<snip/>
================= ======== == ================ ===== ==
===========================================================
The output using this approach and a markup to use mono-spaced cells
e. g. either using ..raw or using .. cssclass as commented before in
this thread is at:
https://www.infradead.org/~mchehab/rst_conversion/x86/x86_64/mm_alternative.html
Just converted the first table, keeping the other as a literal block.
Thanks,
Mauro
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
