On 10/06/18 at 02:33pm, Ingo Molnar wrote: > > * 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?
Yes, you are right. I wondered why the size is a weird unaligned value. Sorry about that. Thanks Baoquan
