Set CONFIG_LEAF_DIR with configure to give control if needed. The
check for the correct value if the option is not specified is tricky.
Since other packages (such as grub2) started to populate also
/etc/default/ a given system may have both directories.
Use "default" only if /etc/sysconfig does not exist. "sysconfig"
remains the default.
Move the variable from StdGNU.mk to Linux.mk because thats the only
place where it is used.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
This replaces config/Linux.modules with a configure option. As a result
of this change only a single xencomons.in is required, instead of a
xencomons.in.in and sed hackery.
After this change blktap2 and blktap will be loaded at the same time.
This is already done in out-of-tree xencommons scripts, and systemd will
load both modules as well. No harm is expected by loading both modules.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
The current usage of LIBEXEC is bogus. It describes the directory for
private xen executables. Other places create their own, similar
libexecdir path as $prefix/lib/xen/*.
Additional two other variables are used to describe similar paths:
PRIVATE_BINDIR and PRIVATE_PREFIX
The autoconf documentation refers to libexec as a directory for
executables and stuff which is called by other programs, not by the
user.
Adjust all places that want libexecdir as a target path. LIBEXEC refers
now to the base directory. Three convenience variables are used to refer
to paths to private binaries, libs and include files.
In the systemd files LIBEXEC_BIN is substituted, so this variable has to
be present in autoconf. All other variables are expanded in Paths.mk
because they are only used in Makefiles.
Most users of LIBEXEC are updated to use LIBEXEC_BIN because that is
what they want.
Users of PRIVATE_BINDIR are updated to use LIBEXEC_BIN because that is
what they want. PRIVATE_BINDIR and PRIVATE_PREFIX usage is removed by
this patch, in favour of LIBXEC_BIN and LIBEXEC
An internal libxl function was removed. A single helper to retrieve
LIBEXEC_BIN remains.
As suggested by the autoconf documentation, configure appends the
package name to LIBEXEC to make sure the provided directory really
refers to xen. This makes sure "make uninstall" preserves the real
libexecdir.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested, updated QEMU_TRADITIONAL_REVISION to
pickup version which uses LIBEXEC_BIN ]
This patch lays the groundwork to convert variables used in Makefiles
to the common automake style, i.e. PREFIX becomes prefix, MANDIR becomes
mandir and so on.
The reason is that configure variables such as mandir expand to
${datarootdir}/man, and datarootdir expands to ${prefix}/share. This
requires extra expansion in configure.ac before assigning to MANDIR.
Special care must be taken when variable substition is done in other
files, such as xencommons.in. All @VARIABLES@ used in these files have
to be the expanded version, or all other variables must be available at
runtime.
This patch by itself changes nothing, but upcoming changes will make use
of the lowercase variables.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
... because they are already in Paths.mk:
BINDIR, LIBEXEC, PRIVATE_BINDIR, PRIVATE_PREFIX, SBINDIR, SHAREDIR,
XEN_CONFIG_DIR, XENFIRMWAREDIR, XEN_LOCK_DIR, XEN_PAGING_DIR,
XEN_RUN_DIR. Remove unused PKG_XEN_PREFIX, which was also incorrectly
assigned to PRIVATE_PREFIX.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
Helper scripts get installed into XEN_SCRIPT_DIR, but initscripts,
helper scripts and udev rules still refer to the hardcoded location
/etc/xen/scripts/. Update scripts, rules and Makefile to refer to
@XEN_SCRIPT_DIR@ instead.
Update configure.ac to substitute the path in files using
XEN_SCRIPT_DIR. Remove XEN_SCRIPT_DIR from StdGNU.mk and SunOS.mk, its
already in Paths.mk.
Note: In SunOS.mk it refered to PRIVATE_PREFIX, which was introduced by
9f6d07bac9 ("tools: get rid of hardcoded
config dirs").
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
A make -j8 will call the xen.conf rule twice. The move-if-changed
macro may fail if the tmp file was already removed by the other make
process. Fix this by let the all target depend on install.
Also remove the generated file with make clean.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- fixed s/of/if/ typo in commit message ]
The uninstall target does not know about the paths it removes because
the toplevel Makefile does not include the required files.
Move the commands to tools/Makefile because all files come from subdirs
in tools/ anyway. Drop the removal of $(XEN_RUN_DIR) because it gets
created at runtime. Drop the removal of systemd related files because
the wildcard matches everything.
The proper fix is to remove the files and directories in the Makefiles
which install them. But this version is the least intrusive change at
this point.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Some arm64 platforms implement only aarch64 mode. So allow
domains that are only 64-bit
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- s/cpu_has_a32/cpu_has_arm/ as discussed on list ]
Fixed the return value of the function libxl_wait_for_memory_target. It was always returning 0 even inthe case of an error.
Signed-off-by: Ayush Ruia <ayushruia@gmail.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In GICv3 use IROUTER register contents to deliver irq to
specified vcpu.
vgic irouter[irq] is used to represent vcpu number for which
irq affinity is assigned. Bit[31] is used to store IROUTER
bit[31] value to represent irq mode.
This patch is similar to Stefano's commit
5b3a817ea3 for GICv2
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
If the CMT service is attached to a domain, its related RMID
will be set to hardware for monitoring when the domain's vcpu is
scheduled in. When the domain's vcpu is scheduled out, RMID 0
(system reserved) will be set for monitoring.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Add hypervisor side support for dynamically attach and detach
Cache Monitoring Technology(CMT) services for a certain guest.
When attach CMT service for a guest, system will allocate an
RMID for it. When detach or guest is shutdown, the RMID will be
recycled for future use.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Detect Cache Monitoring Technology(CMT) feature and enumerate the
resource types, one of which is to monitor the L3 cache occupancy.
Also introduce a Xen command line parameter to control the Platform
Shared Resource such as CMT.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Xen added a new platform_op hypercall for generic MSR access, and this
is the the tool side change to wrapper the hypercall into xc APIs.
For non-preemptible batch resource operations, group them in entries of
xc_resource_op structure. For preemptible ones, use multiple
xc_resource_op structure instead.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Add a generic resource access hypercall for tool stack or other
components, e.g., accessing MSR, port I/O, etc.
The resource is abstracted as a resource address/value pair.
The resource access can be any type of XEN_RESOURCE_OP_*(current
only support MSR and it's white-listed). The resource operations
are always runs on cpu that caller specified. If caller does not
care this, it should use current cpu to eliminate the IPI overhead.
Batch resource operations in one call are also supported but the
max number currently is limited to 2. The operations in a batch are
non-preemptible and execute in their original order. If preemptible
batch is desirable, then multicall mechanism can be used.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Both the freeing and the inspection of the bitmap get done in (nested)
loops which - besides having a rather high iteration count in general,
albeit that would be covered by XSA-77 - have the number of non-trivial
iterations they need to perform (indirectly) controllable by both the
guest they are for and any domain controlling the guest (including the
one running qemu for it).
Note that the tying of the continuations to the invoking domain (which
previously [wrongly] used the invoking vCPU instead) implies that the
tools requesting such operations have to make sure they don't issue
multiple similar operations in parallel.
Note further that this breaks supervisor-mode kernel assumptions in
hypercall_create_continuation() (where regs->eip gets rewound to the
current hypercall stub beginning), but otoh
hypercall_cancel_continuation() doesn't work in that mode either.
Perhaps time to rip out all the remains of that feature?
This is part of CVE-2014-5146 / XSA-97.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
This patch introduces documentation notes about AMD container
file formats and where to obtain latest container files from.
Also, We provide a how-to for updating patch level by
concatenating container files along with initrd images.
Misc notes about how Xen handles two containers of same
kind (if/when) they are concatenated together are also included.
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
AMD Guest IOMMU support was added to allow correct use of PASID and PRI
hardware support with an ATS-aware guest driver.
However, support cannot possibly function as guest_iommu_set_base() has no
callers. This means that its MMIO region's P2M pages are not set to
p2m_mmio_dm, preventing any invocation of the MMIO read/write handlers.
c/s fd186384 "x86/HVM: extend LAPIC shortcuts around P2M lookups" introduces a
path (via hvm_mmio_internal()) where iommu_mmio_handler claims its MMIO range,
and causes __hvm_copy() to fail with HVMCOPY_bad_gfn_to_mfn.
iommu->mmio_base defaults to 0, with a range of 8 pages, and is unilaterally
enabled in any HVM guests when the host IOMMU(s) supports any extended
features.
Unfortunately, HVMLoader's AP boot trampoline executes an `lmsw` instruction
at linear address 0x100c which unconditionally requires emulation. The
instruction fetch in turn fails as __hvm_copy() fails with
HVMCOPY_bad_gfn_to_mfn.
The result is that multi-vcpu HVM guests do not work on newer AMD hardware, if
IOMMU support is enabled in the BIOS.
Change the default mmio_base address to ~0ULL. This prevents
guest_iommu_mmio_range() from actually claiming any physical range
whatsoever, which allows the emulation of `lmsw` to succeed.
Reported-by: Roberto Luongo <rluongo@ready.it>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roberto Luongo <rluongo@ready.it>
Acked-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
There's no reason to use the "hardware_domain" variable anywhere here,
making the code more cumbersome to read.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Just like for LAPIC, IO-APIC, MSI, and HT we shouldn't be granting Dom0
access to these. This implicitly results in these pages also getting
marked reserved in the machine memory map Dom0 uses to determine the
ranges where PCI devices can have their MMIO ranges placed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Commit d1222afda4 ("x86: allow Dom0 read-only access to IO-APICs") had
an unintended side effect: By no longer adding IO-APIC pages to Dom0's
iomem_caps these also no longer get reported as reserved in the machine
memory map presented to it (which got added there intentionally by
commit b8a456caed ["x86: improve reporting through
XENMEM_machine_memory_map"] because many BIOSes fail to add these).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Commit d1b6d0a024 ("x86: enable multi-vector MSI") went a little too
far with moving things around in msi_free_irqs() in order to streamline
the code: We shouldn't drop the MSI-X control page reference before
calling destroy_irq(), as the latter will call us back via
desc->handler->shutdown() (effectively invoking to msi_set_mask_bit()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This patch add initial (minimal) platform support for AMD Seattle,
which mainly just define the matching ID, and specify system_off,
and system_reset mechanism.
Initially, the firmware only support a subset of PSCI-0.2 functions,
system-off and system-reset. The mechanism for bring up auxiliary processors
is still using spin-table.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On arm32 the xenheap has a maximum size of 1GB. On systems with more than 8GB
(so 1/8 total RAM is greater than 1GB) there is no point in searching for a
region with 1/8 of the total RAM when only 1GB will be used. Therefore limit
the maximum size to 1GB before searching.
Signed-off-by: Frediano Ziglio <frediano.ziglio@huawei.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- updated commit message as discussed ]
Olaf Hering
Ian Campbell
Jan Beulich
Vijaya Kumar K
Ayush Ruia
Stefano Stabellini
Tamas K Lengyel
Dongxiao Xu
Aravind Gopalakrishnan
Andrew Cooper
Suravee Suthikulpanit
Frediano Ziglio