"paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor"
This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000 to 0xffff880000000000. I have no general justification for this: the specific reason is that Xen claims the first 16 kernel GDT slots for itself, and we must move up the mapping to make room. In the process I parameterised the compile-time construction of the initial pagetables in head_64.S to cope with it.
This reduces native kernel max memory support from around 127 TB to around 120 TB. We also limit the Xen hypervisor to ~7 TB of physical memory - is that wise in the long run? Sure, current CPUs support 40 physical bits [1 TB] for now so it's all theoretical at this moment.
my guess is that CPU makers will first extend the physical lines all the way up to 46-47 bits before they are willing to touch the logical model and extend the virtual space beyond 48 bits (47 bits of that available to kernel-space in practice - i.e. 128 TB).
So eventually, in a few years, we'll feel some sort of crunch when the # of physical lines approaches the # of logical bits - just like when 32-bit felt a crunch when physical lines went to 31 and beyond.
That should be fine too - and probably useful for 64-bit kmemcheck support as well.
To further increase the symmetry between 64-bit and 32-bit, could you please also activate the mem=nopentium switch on 64-bit to allow the forcing of a non-PSE native 64-bit bootup? (Obviously not a good idea normally, as it wastes 0.1% of RAM and increases PTE related CPU cache footprint and TLB overhead, but it is useful for debugging.)
a few other risk areas:
- the vmalloc-sync changes. Are you absolutely sure that it does not
matter for performance?
- "The 32-bit early_ioremap will work equally well for 64-bit, so just
use it." Famous last words ;-)
Anyway, that's all theory - i'll try out your patchset in -tip to see what breaks in practice ;-)