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>
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>
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>
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>
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>
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>
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>
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>
Ian Campbell
Keir Fraser
Keir Fraser