It looks like level page table changed the layout. Now,
0xffff810000000000 is a valid.

Documentation/x86_64/mm.txt

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47bits) user space, different per
mm
hole caused by [48:63] sign extension
ffff800000000000 - ffff80ffffffffff (=40bits) guard hole
ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of phys.
memory
ffffc10000000000 - ffffc1ffffffffff (=40bits) hole
ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space
... unused hole ...
ffffffff80000000 - ffffffff82800000 (=40MB)   kernel text mapping, from
phys 0
... unused hole ...
ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space

Thanks,
Badari

There probably will need to be some work done to deal with
page table walkthroughs in x86_64_kvtop() and x86_64_uvtop()
for translating non-unity-mapped memory like user space
and vmalloc space.

But just getting the basic unity-mapped memory accesses will
be a initial necessity before even looking into that.

Dave