Eliminate the mis-naming of 64-bit fields with 32-bit register names
(eflags instead of rflags etc). To ensure no piece of code was missed,
transiently use the underscore prefixed names only for 32-bit register
accesses. This will be cleaned up subsequently.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current seedery doesn't work with BSD sed, so remove the try to match
int64_t also (since there's none at the moment). Also, apply the same
treatment to all arch headers, currently this is only done to x86_64
headers.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Due to the fact that on ARM headers types are substituted to uint64_t and
then uint64_t is also substituted to contain the aligment, this would lead
to some types containing two __align8__ directives. Fix this by first
expanding Xen specific types to uint64_t only, and then replacing all the
uint64_t types to __align8__ uint64_t. This relies on the fact that all
Xen-specific types will have longer names, so they will always be replaced
first.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
The foreign header generation blindly replaces 'uint64_t' with '__align8__
uint64_t', to get correct alignment when built as 32bit. This is correct in
most circumstances, but Clang objects to two specific uses.
* Inside a sizeof() expression
* As part of a typecast
An example error looks like:
/local/xen.git/tools/libxc/../../tools/include/xen/foreign/x86_64.h:204:44:
error: 'aligned' attribute ignored when parsing type [-Werror,-Wignored-attributes]
__align8__ uint64_t evtchn_mask[sizeof(__align8__ uint64_t) * 8];
^~~~~~~~~~
/local/xen.git/tools/libxc/../../tools/include/xen/foreign/x86_64.h:13:36:
note: expanded from macro '__align8__'
^~~~~~~~~~~
This sedary is sufficient to fix all the bad examples without touching any of
the legitimate uses, and is more simple than teaching mkheader.py how to parse
C.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Linux is in the process of converting their seconds representation to
64 bits, so in order to support it consistently we should follow suit
(which at some point in quite a few years we'd have to do anyway). To
represent this in struct shared_info we leverage a 32-bit hole in
x86-64's and arm's variant of the structure; for x86-32 guests the only
(reasonable) choice we have is to put the extension in struct
arch_shared_info.
A note on the conditional suppressing the xen_wc_sec_hi helper macro
definition in the ix86 case for hypervisor and tools: Neither of the
two actually need this, and its presence causes the tools to fail to
build (due to the inclusion of both the x86-64 and x86-32 variants of
the header).
As a secondary change, x86's do_platform_op() gets a pointless
initializer as well as a pointless assignment of that same variable
dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The original rule to target "distclean" in tools/Rules.mk was in effect
"make clean". It should be "make distclean".
However not all Makefiles in subdirectories have distclean target
defined. So this patch also adds a bunch of distclean targets to various
Makefiles. They only depend on clean target and don't have any actions
in most cases.
With the patch applied, following command outputs 0 results:
find tools -name 'Makefile*' -exec grep -L 'distclean' {} \+ \
| grep -v ocaml | grep -v libfsimage
Ocaml and libfsimage are known to have distclean defined in a dedicated
rules file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
currently contains the mfn of the top level page frame of the 3 level
p2m tree, which is used by the Xen tools during saving and restoring
(and live migration) of pv domains and for crash dump analysis. With
three levels of the p2m tree it is possible to support up to 512 GB of
RAM for a 64 bit pv domain.
A 32 bit pv domain can support more, as each memory page can hold 1024
instead of 512 entries, leading to a limit of 4 TB.
To be able to support more RAM on x86-64 switch to an additional
virtual mapped p2m list.
This patch expands struct arch_shared_info with a new p2m list virtual
address, the root of the page table root and a p2m generation count.
The new information is indicated by the domain to be valid by storing
a non-zero value into the page table root member.
To avoid build failures in the tools directory the checked structure
sizes must be adapted, too.
Signed-off-by: Juergen Gross <jgross@suse.com>
Storing it in a 32-bit variable in struct arch_vcpu caused breakage over
context switch.
There were also several other places which stored this as the 32-bit value.
Update them all.
The "struct vcpu_guest_context" case needs special consideration. This struct
is in theory is exposed to guests, via the VCPUOP_initialise hypercall.
However as discussed in
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00912.html this isn't
really a guest visible interface since ARM uses PSCI for VCPU bringup
(VCPUOP_initialise simply isn't available) The other users of this interface
are the domctls, which are not a stable API. Therefore while fixing the ttbcr
size also surround the struct in ifdefs to restrict the struct to the
hypervisor and the tools only (omitting the extra complexity of renaming as I
suggested in the referenced thread).
NB TCR_EL1 on arm64 is known as TTBCR on arm32, hence the apparent naming
inconsistencies.
Spotted-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Cc: Anup Patel <anup.patel@linaro.org>
Cc: patches@linaro.org
Cc: patches@apm.com
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>
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>
Jan Beulich
Roger Pau Monne
Andrew Cooper
Wei Liu
Juergen Gross
Ian Campbell
Keir Fraser
Keir Fraser