* Ingo Molnar <mi...@kernel.org> wrote:
> +========================================================
> +| Complete virtual memory map with 4-level page tables |
> +========================================================
> +--------------------------------------------------------------------------------
> +start addr | offset | end addr | size | VM area
> description
> +-----------------|------------|------------------|---------|--------------------
> +
> +# Identical layout to the 56-bit one from here on:
> +
> +ffffff8000000000 | -512 GB | fffffffeefffffff | ~507 GB | ... unused hole
> +ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region
> mapping space
> +========================================================
> +| Complete virtual memory map with 5-level page tables |
> +========================================================
> +ffffff8000000000 | -0.5 TB | ffffffeeffffffff | 444 GB | ... unused hole
> +
> +# Identical layout to the 47-bit one from here on:
> +
> +ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region
> mapping space
So patch #2 appears to have introduced an error/typo in the 47-bit table. Note
the weird size
and discontinuity of the 'unused hole' in the 47-bit table, and compare it with
56-bit table:
fffffffeefffffff
ffffffeeffffffff
(Note how the incorrect end address was cargo-cult-copied into the 'size' field
of ~507 GB...)
The correct number is the 56-bit one, and both tables should show the following
identical
layout:
ffffff8000000000 | -512 GB | fffffffeefffffff | 444 GB | ... unused hole
ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region
mapping space
Agreed?
Thanks,
Ingo
