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