x86-64: guest directed placement of initial p->m map

By adding another ELF note, the kernel can now direct the hypervisor
(for Dom0) and in the future also the tools (for DomU-s) to place the
initial phys->mach translation table at other than an address
immediately above the kernel/initrd images. This eliminates the size
restriction imposed on this table by Linux (the kernel loads above the
-2Gb boundary, and hence the entire initial mapping cannot reach or
even exceed 2Gb).

There are a few items in this patch I'm not particularly happy with,
but couldn't think of a better solution:
- there is a hidden assumption that pages allocated for the domain are
  put on the domain's page list sequentially
- the way backward compatibility is maintained is placing requirements
  on the kernel side that make the code somewhat convoluted (because
  it
  needs to check where the map is actually placed in quite a few
  places)
- code is there to use 1Gb mappings for the hypervisor created table,
  but lacking a machine with 512G+ memory for immediate testing I
  can't
  verify this works; I know that 2Mb mappings work, and hence imply
  that 1Gb ones would too (of course, if the kernel replaces the table
  - like Linux does -, it cannot use 2Mb/1Gb mappings or even try to
  re-use the page table entries, but I don't consider this a problem)

Signed-off-by: Jan Beulich <jbeulich@novell.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index ead6cd1559..5f2908502b 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,7 +1,7 @@
 
 structs                   |  x86_32  x86_64    ia64
 
-start_info                |    1104    1152    1152
+start_info                |    1112    1168    1168
 trap_info                 |       8      16       -
 pt_fpreg                  |       -       -      16
 cpu_user_regs             |      68     200       -