Commit Graph
5 Commits
Author SHA1 Message Date
Ian Campbell 20013e0b97 arm: tools: add arm to foreign structs checking
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
2012-10-17 16:43:48 +01:00
Ian Campbell 42d1b5413a tools: drop ia64 only foreign structs from headers
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
2012-09-17 11:17:05 +01:00
Ian Campbell e567964a54 tools: drop ia64 support
Removed support from libxc and mini-os.

This also took me under xen/include/public via various symlinks.

Dropped tools/debugger/xenitp entirely, it was described upon commit
as:
"Xenitp is a low-level debugger for ia64" and doesn't appear to be
linked into the build anywhere.

 99 files changed, 14 insertions(+), 32361 deletions(-)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
2012-09-12 17:55:27 +01:00
Keir Fraser c6d8d541e9 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>
2009-01-08 11:32:39 +00:00
Keir Fraser 21ffff5e7f Move remaining xen/include/public/foreign files to tools/include/xen-foreign
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>

--HG--
rename : xen/include/public/foreign/mkchecker.py => tools/include/xen-foreign/mkchecker.py
rename : xen/include/public/foreign/mkheader.py => tools/include/xen-foreign/mkheader.py
rename : xen/include/public/foreign/reference.size => tools/include/xen-foreign/reference.size
rename : xen/include/public/foreign/structs.py => tools/include/xen-foreign/structs.py
2008-01-27 17:25:56 +00:00