This isn't strictly necessary but since it is going to be exposed via
tools/include in a later patch this will help prevent accidental
leakage beyond the tools.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
When called from the tools side in a later patch we will want to
direct its output to the appropriate place.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
We are going to need this to generate the userspace flask.h header.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh ]
There was a missing [ in the aio check which lead to never check if aio
is present on the platform.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
Until recently, a maintenance IRQ was requested for any IRQ injected to
the guest on x-gene platform.
The commit 50dcb3de60 "xen: arm: X-Gene Storm
check GIC DIST address for EOI quirk" disable the quirk for boards using
the new firmware.
It is known that the quirk is fragile and cause performance regression.
Given that firmware is available for people having the board, I think
we can request the user to upgrade to the latest version.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Using gcc 4.8 to compile with -Werror.
xl_cmdimpl.c:5493:8: error: 'valid_devs' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (valid_devs == 0)
^
xl_cmdimpl.c:5455:9: note: 'valid_devs' was declared here
int valid_devs;
Signed-off-by: Charles Arnold <carnold@suse.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Said commit ("libxl_set_memory_target: retain the same maxmem offset on
top of the current target") caused a regression for "xl mem-set"
against Dom0: While prior to creation of the first domain this works,
the first domain creation involving ballooning breaks. Due to "enforce"
not being set in the domain creation case, and due to Dom0's initial
->max_pages (in the hypervisor) being UINT_MAX, the calculation of
"memorykb" in the first "xl mem-set" adusting the target upwards
subsequent to domain creation and termination may cause an overflow,
resulting in Dom0's maximum getting to a very small value. This small
maximum will the make the subsequent setting of the PoD target fail.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xm migrate would do non-live migration (effectively, save, transfer
and restore) by default, unless you specified --live.
xl migrate always does live migration. Honour (by ignoring) --live
for compatibility with old callers. Document this.
(This patch should be backported as far as possible.)
Reported-by: Matthew Vernon <mcv21@cam.ac.uk>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Matthew Vernon <mcv21@cam.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently, the GICv3 driver is only able to send an SGI when the cpumask
is provided. Although with the modes SGI_TARGET_OTHERS and SGI_TARGET_SELF,
no cpumask is provided. Any usage of those modes will crash the hypersivor.
Rename gicv3_send_sgi to gicv3_send_sgi_list and implement the
different modes:
- SGI_TARGET_OTHERS: Set the Interrupt Routing Mode (bit 40) to 1
(see Table 4 on Section 4.2.6 PRD03-GENC-010745 24.0)
- SGI_TARGET_SELF: Unlike GICv2, the GICv3 SGI registers don't
provide a specific field. So use gicv3_send_sgi_list and pass
the cpumask of the current CPU
- SGI_TARGET_LIST: Directly call gicv3_send_sgi_list with the given
cpumask
Also, use WRITE_SYSREG64 to write into ICC_SGI1R_EL1 the access is
64-bit on all the architectures.
Reported-by: Chen Baozi <baozich@gmail.com>
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Tested-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Note that the example is done on Midway whose SMMU driver is not
supported on Xen upstream.
Currently, I don't have other platform where I can test Device Tree
passthrough.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On ARM, every non-PCI device are described in the device tree. Each of
them can be found via a path.
This patch introduces a very basic support, only the IOMMU will be set
up correctly. The user will have to:
- Describe the device in the partial device tree
- Map manually MMIO/IRQ
This is a first approach, that will allow to have a basic Device Tree
passthrough support in Xen. This could be improved later.
Furthermore add LIBXL_HAVE_DEVICETREE_PASSTHROUGH to indicate we
support Device Tree passthrough and partial device tree (introduced by a
previous patch).
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
The partial device tree may contains phandle. The Device Tree Compiler
tends to allocate the phandle from 1.
Reserve the ID 65000 for the GIC phandle. I think we can safely assume
that the partial device tree will never contain a such ID.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Allow the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user to define
aliases which can be used by the guest kernel.
A simple partial device tree will look like:
/dts-v1/;
/ {
#address-cells = <2>;
#size-cells = <2>;
passthrough {
compatible = "simple-bus";
ranges;
#address-cells = <2>;
#size-cells = <2>;
/* List of your nodes */
}
};
Note that:
* The interrupt-parent property will be added by the toolstack in
the root node
* The properties compatible, ranges, #address-cells and #size-cells
in /passthrough are mandatory.
The helpers provided by the libfdt don't perform all the necessary
security check on a given device tree. Therefore, only trusted device
tree should be used.
Note: The partial device tree code requires the presence of libfdt
functions which have been only correctly exported in libfdt 1.4.0 and
higher. All the major distributions but Debian Wheezy are using v1.4.0
or higher. It has been decided to disable partial device tree support on
OSes where libfdt doesn't meet the requirement.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
The functions fdt_{first,next}_subnode may not be available because:
* It has been introduced in 2013 => Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently in the dtc repo [1]
When the functions are not available, implement our own in order to use
them in a following patch.
Note that the _hidden attribute is placed in both the prototype and the
declaration because some version of libfdt expose the prototype but not
the declaration.
[1] git://git.kernel.org/pub/scm/utils/dtc/dtc.git
commit a4b093f7366fdb429ca1781144d3985fa50d0fbb
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
These are a few bits of cleanup noticed when double checking the PV GDT
handling for migration v2.
* Drop write-only 'mfn' variable in set_gdt()
* Hoist page_get_owner() call in alloc_segdesc_page() and unify exit paths
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
This structure is used by XEN_DOMCTL_createdomain, and is liable to be
modified going forwards. Explicitly state that it falls under the
XEN_DOMCTL_INTERFACE_VERSION.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Don Slutz <dslutz@verizon.com>
It's being declared in xen/hypercall.h, and the duplication causes a
build failure with commit 8ddb99287c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
In tree, there is one single caller of XEN_DOMCTL_getpageframeinfo3
(xc_get_pfn_type_batch()), and no callers of the older variants.
getpageframeinfo3 and getpageframeinfo2 are compatible if the parameter
contents are considered to be unsigned long, and indeed, a compat guest
calling getpageframeinfo3 falls through into the getpageframeinfo2 handler.
However, getpageframeinfo3 and getpageframeinfo2 have different algorithms for
calculating the eventual frame type, which means that a toolstack will get
different answers depending on whether it is compat or not.
Rewrite getpageframeinfo3 such that the code block can handle both regular and
compat guests, and use the original getpageframeinfo3 algorithm for frame
time, which is more complete.
Remove getpageframeinfo2 and getpageframeinfo1, as they are unused and
obsolete.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This function should better return as bool_t and
remove that pointless comment.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
This is needed so Xen can properly trap 4 byte accesses to 0xcf8 in order to
keep consistency with accesses to 0xcfc.
The access to RTC ports also needs to be trapped in order to keep
consistency, this includes RTC_PORT(0) and RTC_PORT(1) (0x70 and 0x71
respectively).
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
It may not be the appropriate half to touch.
Drop the superfluous mem_sharing_enabled assignment, and move the hap_enabled
assignment to a suitable conditional before it is actually needed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Support C-states for the Airmont core in the Cherrytrail and Braswell
SOCs. The states are similar to those of Silvermont in Baytrail, except
both flavors of C6 states are faster.
Signed-off-by: Len Brown <len.brown@intel.com>
[Linux commit cab07a5652d1d124b505c2b7ed21c6823295c5d7]
Signed-off-by: Jan Beulich <jbeulich@suse.com>
On some Silvermont-Core/Baytrail-SOC systems,
C1E latency is higher than original specifications.
Although C1E is still enumerated in CPUID.MWAIT.EDX,
we delete the state from intel_idle to avoid latency impact.
Under some conditions, the latency of the C6N-BYT and C6S-BYT states
may exceed the specified values of 40 and 140 usec, respectively.
Increase those values to 300 and 500 usec; to assure
that the hardware does not violate constraints that may be set
by the Linux PM_QOS sub-system.
Also increase the C7-BYT target residency to 4.0 ms from 1.5 ms.
Signed-off-by: Len Brown <len.brown@intel.com>
[Linux commit d7ef76717322c8e2df7d4360b33faa9466cb1a0d]
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Older GCC versions such as 4.3 cannot have initializers for the
members of anonymous structures, so initialize .head_tail instead.
Use a SPINLOCK_TICKET_INC define so this initializer is near the
spinlock_tickets_t definition (in case the structure changes requiring
changes to the initializer).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reported-and-tested-by: Jan Beulich <jbeulich@suse.com>
Updates to idle_pg_table[] need to be mirrored into the page tables
used for invoking EFI runtime services.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
fail_if() and generate_exception_if() could theoretically bypass the
normal flow reaching put_fpu(), and not invoking it would leave the
fpu_exception_callback pointer in place, allowing for the callback to
be called at an unexpected time. Luckily the two
generate_exception_if()-s that would actually trigger this are
currently commented out, so this is not (yet) a (security) issue.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Instead of just using -c 0x<some hex value> we can
also use: -c <starting cpu>-<end cpu>, -c <cpu1>,<cpu2>, or a
combination of them, or 'all' for all cpus.
This new format can include just singular CPUs: -c <cpu1>,
or ranges without an start or end (and xentrace will figure out
the values), such as: -c -<cpu2> (which will include cpu0, cpu1,
and cpu2) or -c <cpu2>- (which will include cpu2 and up to MAX_CPUS).
That should make it easier to trace the right CPU if
using this along with 'xl vcpu-list'.
The code has been lifted from the Linux kernel, see file
lib/bitmap.c, function __bitmap_parselist.
To make the old behavior and the new function work, we check
to see if the arguments have '0x' in them. If they do
we use the old style parsing (limited to 32 CPUs). If that
does not exist we use the new parsing.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
When the caller of paging_log_dirty_op is a hvm guest Xen would choke when
trying to copy the dirty bitmap to the guest because the paging lock is
already held.
Fix this by independently mapping each page of the guest bitmap as needed
without the paging lock held.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Just like it's done for shadow_track_dirty_vram allocate the temporary
buffer using non-contiguous memory.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>