GIC driver contains both generic and hardware specific low
level functionality in gic.c file.
With this patch, low level functionality is moved to separate
file gic-v2.c and generic code is kept in gic.c file
Callbacks are registered by low level driver with generic driver
and are called wherever required.
The locking mechanism is not changed.
This helps to separate generic and hardware functionality
and implement future hardware version drivers.
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
gic-v2 driver uses fixmap to map the registers.
Instead use ioremap to access mmio registers.
With this patch, gic-v2 register definitions are updated
to use absolute offset address instead of dividing the
register offset by 4.
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This wasn't done upon the initial addition of the file since the
section processing needs some adjustment for this: We can't mark the
two arrays needing relocations as either __initdata or __initconst, as
both have the potential of creating section conflicts (with -fPIC the
compiler may want to mark the section writable due to the necessary
relocations, colliding with other __initconst uses, and if the compiler
chooses to use the provided section name, __initdata on a constant
object might collide with other __initdata uses). However, local data
known to be referenced only by init code/data can also safely be moved
into .init.*. Hence the respective logic is being tweaked such that it
won't complain on non-empty .*.local sections.
While at it also drop the non-local section names from
SPECIAL_DATA_SECTIONS - they can't be safely converted.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
While this was intended to only do cleanup (replace the two bogus
"ret |= " constructs, and a simple formatting correction), this now
also
- fixes the bit manipulations for size_order > 0
a) correct an off-by-one in the use of size_order for shifting (till
now double the requested size got invalidated)
b) in fact setting bit 12 and up if necessary (without which too
small a region might have got invalidated)
c) making them capable of dealing with regions of 4Gb size and up
- corrects the return value handling, such that a later iteration's
success won't clear an earlier iteration's error indication
- uses PCI_BDF2() instead of open coding it
- bail immediately on bad passed in invalidation type, rather than
repeatedly printing the same message for each ATS-capable device, at
once also no longer hiding that failure from the caller
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Yang Zhang <yang.z.zhang@intel.com>
If the "generation_id" option is set in the domain configuration,
generate and set a new random VM generation ID every time a domain is
created or restored.
xl lacks the infrastructure to fully track the lifecycle of VM images
as they are snapshotted and cloned (etc) so always using a new ID is
the safe option and ensures that a new one will be used where it matters.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Toolstacks may specify a VM generation ID using the u.hvm.ms_vm_genid
field in the libxl_domain_build_info structure, when creating a
domain.
The toolstack is responsible for providing the correct generation ID
according to the Microsoft specification (e.g., generating new random
ones with libxl_ms_vm_genid_generate() as appropriate when restoring).
Although the specification requires that a ACPI Notify event is raised
if the generation ID is changed, the generation ID is never changed
when the domain is in a state to receive such an event (it's either
newly created or suspended).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: David Scott <dave.scott@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Make the set of MCEs that xen-mceinj can inject by data-driven instead
of a whole pile of cut-and-paste functions.
There is no functional change.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Christoph Egger <chegger@amazon.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Correctly name --page option and make it clear that it takes a
parameter. Use consistent formatting for help message.
Remove unused options.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
err() calls perror() which appends a newline.
Make Lprintf() also append a newline so err() and Lprintf() are
consistent.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Christoph Egger <chegger@amazon.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On FreeBSD ZVOLs/disks/partitions are char devices, so libxl must
allow it's usage. This is already taken care in the OS-specific bits
of libxl by libxl__try_phy_backend, so remove the generic gate.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
blktap2 will be enabled by default on Linux systems only, also give
the oportunity to disable it from configure.
Remove the gate in the Makefile that only allows enabling blktap{1,2}
on Linux, since this is now done in a more flexible way on configure.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
XSA-93 adds a couple of new functions to trap coprocessor registers. They
unconditionally inject an undefined instruction to guest.
When debugging an OS at early stage, it may be hard to know why the guest
received an UNDEFINED. Add some debug message to help the developer when Xen
is built in debug mode.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The function init_traps sets up the handler taken when Xen hits a
BUG_ON/ASSERT.
If an error happen before init_traps is called, we lose the backtrace.
When a trap is taken from HYP mode, we need to:
- get the processor ID, percpu has to be initialized and the
smp_processor_id correctly set.
- initialize current, even though it's not used for the time being. Move
the debug sanity earlier.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Naresh Bhat <naresh.bhat@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fixed typos and rewrapped commit log ]
The {GET,SET,MEMCPY,MEMSET_ARRAY}_FIELD() macros previously required
'dinfo->guest_width' to exist in scope, which is somewhat antisocial, and
makes them awkward to use in other contexts.
Update these macros to take guest width as a parameter, and in all cases pass
dinfo->guest_width.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The VM generation ID support in libxc/libxl was based on a draft
specification which subsequently changed considerably. Remove much of
the code in anticipation of introducing something simpler that
conforms to the current specification from Microsoft.
Switch to using a HVM param (HVM_PARAM_VM_GENERATION_ID_ADDR) instead
of the hvmloader/generation-id-address XenStore key. This simplifies
save/restore since it only needs to transfer the value of this param.
There are no changes to the migration stream format or the public
libxl API.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- updated xc_nomigrate.c for interface change ]
HVM_PARAM_VM_GENERATION_ID_ADDR is the guest physical address of the
VM Generation ID. This parameter will be written by hvmloader and read
by the toolstack when updating the gen. ID (e.g., after restoring from a
snapshot).
A HVM parameter is easier for the save/restore code to work with (than
a XenStore key).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The random bytes are obtained from /dev/urandom and are suitable for
almost all uses (except for generating long-lived secure keys).
Documentation suggests that /dev/urandom is widely available on Unix-like
systems (such FreeBSD and NetBSD).
A public libxl_random_bytes() (or similar) could be trivially added,
if this required in the future.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
HVMOP_get_param and HVMOP_set_param take a uint32_t for the parameter
index and a uint64_t for the value. So add xc_hvm_param_get() and
xc_hvm_param_set() that take the same types.
The existing xc_get_hvm_param() and xc_set_hvm_param() are retained
for compatibility but are deprecated.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- dropped one hunk against xen-access.c which didn't apply due to
intervening changes ]
Testing whether the result of local_irq_save is zero doesn't work on
ARM.
Suggested by Julien Grall.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
The old code said "Xenbus tests disabled, because of a Xend bug".
Since xend doesn't exist any longer, we can enable these again.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
This allows closing any ports opened by the arch-specific code.
ARM will use it for the debug port.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Moves some x86-specific code into arch/x86.
Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
[talex5@gmail.com: split into multiple patches]
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@gmail.com>
[talex5@gmail.com: separated from big ARM commit]
[talex5@gmail.com: restored comment, moved prototypes to headers]
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
[talex5@gmail.com: restored stack address printk on x86]
[talex5@gmail.com: moved first printk's after start_info setup on x86]
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Would crash if HYPERVISOR_event_channel_op returned an error code.
The other changes in this commit are just fixing indentation.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Ian Campbell <ian.cammpbell@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Before, it read "" and started a shutdown immediately. Now, it waits for
a non-empty value and then actually shuts down.
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
[talex5@gmail.com: avoid declaration-after-statement in kernel.c]
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Make .o rules depend on the includes. Before, only the final link step
depended on setting up the includes directory, making parallel builds
unreliable.
Make symlinks use explicit make rules instead of using a phony target.
Avoids unnecessary rebuilds.
[talex5@gmail.com: bring back "make links", for stubdom]
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
This patch introduces an array of libxl_bitmap called "vcpu_hard_affinity"
in libxl IDL to preserve VCPU to PCPU mapping. This is necessary for libxl
to preserve all information to construct a domain.
The array accommodates at most max_vcpus elements, each containing the
affinity of the respective VCPU. If less than max_vcpus bitmaps are
present, the VCPUs associated to the missing elements will just stay with
their default affinity (they'll be free to execute on every PCPU).
In case both this new field, and the already existing cpumap field are
used, the content of the array will override what's set in cpumap. (In
xl, we make sure that this never happens in xl, by using only one of the
two at any given time.)
The proper macro to mark the API change (called
LIBXL_HAVE_BUILDINFO_VCPU_AFFINITY_ARRAYS) is added but it is commented.
It will be uncommented by the patch in the series that completes the
process, by adding the "vcpu_soft_affinity" array. This is because, after
all, these two fields are being added sort-of together, and are very
very similar, in both meaning and usage, so it makes sense for them to
share the same marker.
This patch was originally part of Wei's series about pushing as much
information as possible on domain configuration in libxl, rather than
xl. See here, for more details:
http://lists.xen.org/archives/html/xen-devel/2014-06/msg01026.htmlhttp://lists.xen.org/archives/html/xen-devel/2014-06/msg01031.html
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
by avoiding allocating them in libxl__domain_build_info_setdefault.
In fact, back in 7e449837 ("libxl: provide _init and _setdefault for
libxl_domain_build_info") and a5d30c23 ("libxl: allow for explicitly
specifying node-affinity"), it was decided that the default for these
fields was for them to be allocated and filled.
That is now causing problem, whenever we have to figure out whether
the caller is using or not one of those fields. In fact, when we see
a full bitmap, is it just the default value, or is the user that
wants it that way?
Since that kind of knowledge has become important, change the default
to be "bitmap not allocated". It then becomes easy to know whether a
libxl caller is using one of the fields, just by checking whether the
bitmap is actually there with a non-zero size.
This is very important for the following patches introducing new ways
of specifying hard and soft affinity. It also allows us to improve
the checks around NUMA automatic placement, during domain creation
(and that bit is done in this very patch).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Make space a new cpumap in vcpu_info, called cpumap_soft,
for retrieving soft affinity, and amend the relevant API
accordingly.
libxl_set_vcpuaffinity() now takes two cpumaps, one for hard
and one for soft affinity (LIBXL_API_VERSION is exploited to
retain source level backword compatibility). Either of the
two cpumap can be NULL, in which case, only the affinity
corresponding to the non-NULL cpumap will be affected.
Getting soft affinity happens indirectly (see, e.g.,
`xl vcpu-list'), as it is already for hard affinity).
This commit also introduces some logic to check whether the
affinity which will be used by Xen to schedule the vCPU(s)
does actually match with the cpumaps provided. In fact, we
want to allow every possible combination of hard and soft
affinity to be set, but we warn the user upon particularly
weird situations (e.g., hard and soft being disjoint sets
of pCPUs).
This very change also update the error handling for calls
to libxl_set_vcpuaffinity() in xl, as that can now be any
libxl error code, not just only -1.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
by using the flag and the new cpumap arguments introduced in
the parameters of the DOMCTL_{get,set}_vcpuaffinity hypercalls.
Now, both xc_vcpu_setaffinity() and xc_vcpu_getaffinity() have
a new flag parameter, to specify whether the user wants to
set/get hard affinity, soft affinity or both. They also have
two cpumap parameters instead of only one. This way, it is
possible to set/get both hard and soft affinity at the same
time (and, in case of set, each one to its own value).
In xc_vcpu_setaffinity(), the cpumaps are IN/OUT parameters,
as it is for the corresponding arguments of the
DOMCTL_set_vcpuaffinity hypercall. What Xen puts there is the
hard and soft effective affinity, that is what Xen will actually
use for scheduling.
In-tree callers are also fixed to cope with the new interface.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The following two patches break both libxc and libxl ABI and
API, so we better bump the MAJORs.
Of course, for libxl, proper measures are taken (in the
relevant patch) in order to guarantee API stability.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
I'm not sure why this wasn't added at the same time as the other
debug registers.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
As with HCR_EL2.{IMO,AMO} we want to route FIQs to Xen not the guest. See ARM
ARM DDI 0406C.b B1.8.4.
So far none of the platforms which we support use FIQ for anything, but when we
end up supporting one it would be far better to surprise Xen with them than
whatever guest happens to be running...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Vijaya Kumar K
Jan Beulich
David Vrabel
Roger Pau Monne
Julien Grall
Andrew Cooper
Thomas Leonard
Karim Raslan
Wei Liu
Dario Faggioli
Ian Campbell