* Ingo Molnar <mingo@xxxxxxxxxx> 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
