aboutsummaryrefslogtreecommitdiffstats
path: root/tools/include/xen-foreign
Commit message (Collapse)AuthorAgeFilesLines
* tools: foreign: add checks for compatible architecturesIan Campbell2013-08-202-2/+24
| | | | | | | | | That is architectures whose struct layout must be identical. Use this for arm32 and arm64. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
* xen: arm: include public/xen.h in foreign interface checkingIan Campbell2013-08-204-12/+18
| | | | | | | | | | | | | | | | | mkheader.py doesn't cope with struct foo { }; so add a newline. Define unsigned long and long to a non-existent type on ARM so as to catch their use. Teach mkheader.py to cope with structs which are ifdef'd. This cannot cope with #defines between the #ifdef and the struct definitions, so move MAX_GUEST_CMDLINE to be next to its only usage. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
* tools: foreign: ensure 64 bit values are properly aligned for armIan Campbell2013-02-261-4/+10
| | | | | | | | When building the foreign headers on x86_32 we use '#pragma pack(4)' and therefore need to explicitly align types which should be aligned to 8-byte boundaries. Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
* xen: arm: separate guest user regs from internal guest state.Ian Campbell2013-02-223-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | struct cpu_user_regs is currently used as both internal state (specifically at the base of the stack) and a guest/toolstack visible API (via struct vcpu_guest_context used by XEN_DOMCTL_{g,s}etvcpucontext and VCPUOP_initialise). This causes problems when we want to make the API 64-bit clean since we don't really want to change the size of the on-stack struct. So split into vcpu_guest_core_regs which is the API facing struct and keep cpu_user_regs purely internal, translate between the two. In the user API arrange for both 64- and 32-bit registers to be included in a layout which does not differ depending on toolstack architecture. Also switch to using the more formal banked register names (e.g. with the _usr suffix) for clarity. This is an ABI change. Note that the kernel doesn't currently use this data structure so it affects the tools interface only. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
* xen: arm64: add to foreign struct checksIan Campbell2013-02-224-11/+28
| | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
* xen: event channel arrays are xen_ulong_t and not unsigned longIan Campbell2013-02-221-1/+3
| | | | | | | | | | On ARM we want these to be the same size on 32- and 64-bit. This is an ABI change on ARM. X86 does not change. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
* tools: s/arm/arm32/ in foreign header checks.Ian Campbell2013-02-223-4/+8
| | | | | | | Also define __arm__ARM32 as required. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
* arm: tools: add arm to foreign structs checkingIan Campbell2012-10-174-12/+27
| | | | | Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Campbell <ian.campbell@citrix.com>
* tools: drop ia64 only foreign structs from headersIan Campbell2012-09-172-13/+0
| | | | | | | 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>
* tools: drop ia64 supportIan Campbell2012-09-123-33/+16
| | | | | | | | | | | | | | | | | 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>
* build: Make XEN_ROOT an absolute path.Keir Fraser2011-03-171-1/+1
| | | | | | | | Otherwise make can search the path relative to certain standard paths such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in Config.mk suffers from this). Signed-off-by: Keir Fraser <keir@xen.org>
* x86, libxc: Fix xc_translate_foreign_address() for PV guests ofKeir Fraser2011-03-031-0/+1
| | | | | | | different bitness than dom0 (32-bit vs 64-bit). Original patch by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Keir Fraser <keir@xen.org>
* tools: python -> $(PYTHON)Keir Fraser2009-07-091-4/+4
| | | | Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
* x86_64: allow more vCPU-s per guestKeir Fraser2009-06-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Since the shared info layout is fixed, guests are required to use VCPUOP_register_vcpu_info prior to booting any vCPU beyond the traditional limit of 32. MAX_VIRT_CPUS, being an implemetation detail of the hypervisor, is no longer being exposed in the public headers. The tools changes are clearly incomplete (and done only so things would build again), and the current state of the tools (using scalar variables all over the place to represent vCPU bitmaps) very likely doesn't permit booting DomU-s with more than the traditional number of vCPU-s. Testing of the extended functionality was done with Dom0 (96 vCPU-s, as well as 128 vCPU-s out of which the kernel elected - by way of a simple kernel side patch - to use only some, resulting in a sparse bitmap). ia64 changes only to make things build, and build-tested only (and the tools part only as far as the build would go without encountering unrelated problems in the blktap code). Signed-off-by: Jan Beulich <jbeulich@novell.com>
* Fix dependencies in tools/include/xen-foreign/MakefileKeir Fraser2009-06-161-4/+4
| | | | Signed-off-by: Jan Beulich <jbeulich@novell.com>
* tools: clean up handling of xen config and scripts directories.Keir Fraser2009-05-191-1/+1
| | | | | | | For now hardcode /etc w/o a prefix as there are hardcoded config paths in the code which would break otherwise. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
* x86-64: guest directed placement of initial p->m mapKeir Fraser2009-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert all usages of gcc's __extension__ keyword, and instead assertKeir Fraser2008-03-312-5/+2
| | | | | | | | | | | that our headers are not built with __GNUC__ and __STRICT_ANSI__. __extension__ had some weird (and buggy) behaviours when nested which make it a risky proposition for general usage in our header files. Better to disallow -ansi, -std=c99, and similar gcc options when building against Xen headers. Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Explicitly tag every anonymous aggregate in the public headers.Keir Fraser2008-03-262-1/+4
| | | | Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Prefix unnamed union structure fields with __extension__ to make itKeir Fraser2008-03-251-1/+1
| | | | | | work properly even in e.g. C99 standard mode. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com>
* Move remaining xen/include/public/foreign files to tools/include/xen-foreignKeir Fraser2008-01-275-9/+301
| | | | | | | | | | 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
* Do not special-case native architecture in mkchecker.py.Keir Fraser2008-01-271-6/+1
| | | | | From: Bastian Blank <waldi@debian.org> Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Use real source files for xen/foreign build.Keir Fraser2008-01-261-9/+9
| | | | Signed-off-by: Bastian Blank <waldi@debian.org>
* Remove commented-out dropping from previous changeset.Keir Fraser2008-01-261-1/+0
| | | | Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Move generation of public header hierarchy into the tools.Keir Fraser2008-01-261-0/+45
This patch merges the two versions of public header generation currently used in the build into one. Signed-off-by: Bastian Blank <waldi@debian.org>