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 ]
The console UART address changed between chip versions C0 and D0.
Broadcom 7445[ABC]0 versions were not released and are not supported.
Signed-off-by: Jon Fraser <jfraser@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
For the physical APIC, oprofile code was abusing APIC_DM_NMI as a mask.
For the virtual APIC, a wrong assumption was made that LVTPC could be
programmed to only fixed or NMI delivery modes. While other modes are
invalid here, we still shouldn't inject an NMI into the guest in such
a case. Instead just do nothing.
In the course of adjusting this it became obvious that what value
vpmu_do_interrupt() returns on its various return paths was pretty
arbitrary. With its only caller ignoring the return value, simply make
the function's return type "void".
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The 'xen' binary for arm64 is both an Image file and a PE/COFF executable,
copy it to xen.efi so that the 'make install' processing is shared with
x86. Prior to this 'make install' was broken on arm64.
Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The arm64 EFI boot support added a new 'dtb' value to the configuration file.
Update the documentation to describe this and how the coniguration file is not
used when GRUB loads the modules. Updates 'ucode' description to indicate that
it is x86 only.
Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xc_unmap_domain_meminfo uses P2M_FLL_ENTRIES macro instead of P2M_FL_ENTRIES.
Moreover, P2M_FL_ENTRIES macro uses (dinfo->p2m_size) which is always 0 here
as we don't initialize it. The result is that we always unmap just 1 frame.
xc_map_domain_meminfo uses P2M_FLL_ENTRIES macro instead of P2M_FL_ENTRIES
on failure path.
The issue went unnoticed mostly because we use unmap_domain_meminfo and
xc_map_domain_meminfo in one-shot xen-mfndump and xen-hptool (through
xc_exchange_page()) tools. When used is long-running apps (e.g. in xl)
domains become zombies after their death.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
{~0,} only initializes the first cell of the array to ~0. The other cells
are initialized to 0.
Explicitly initialize every cells of the array and, at the same time, do the
same for the mappings.
This is fixing boot after 82985d7 "xen: arm: handle variable p2m levels
in apply_p2m_changes" on platform where the root-level doesn't have
concatenate table (such as the Foundation Model).
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
While the write path change appears to be purely cosmetic (but still
gets done here for consistency), the read side mistake permitted
accesses beyond the virtual APIC page.
Note that while this isn't fully in line with the specification
(digesting MSRs 0x800-0xBFF for the x2APIC), this is the minimal
possible fix addressing the security issue and getting x2APIC related
code into a consistent shape (elsewhere a 256 rather than 1024 wide
window is being used too). This will be dealt with subsequently.
This is CVE-2014-7188 / XSA-108.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
The commit 8ab802c "xen/arm: Restricted access to IFSR32_EL2 and FPEXC32_EL2"
introduced the use of the variable current in show_registers.
The variable is not correctly set until Xen has finished to boot.
Therefore any call to show_registers will result to crash Xen.
As the register IFSR32_EL2 is only printed when the registers represent
a guest view, Xen can read the value only for this case.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently the hypervisor will hang if it hits a WARN_ON.
The implementation uses an undefined instruction, made ourself because ARM
don't provide one, to implement BUG/ASSERT/WARN_ON, and sets up the
different tables (one for each type) which contain useful information.
This is based on the x86 implementation (include/asm-x86/bug.h). Unfortunately
the structure can't be shared because many ARM{32,64} gcc versions doesn't
correctly support %c. The support for executing a function in an exception handler
is also keep unimplemented on ARM. Therefore, dump_execution_state is
implemented as WARN()
The current opcode used to go in exception mode may not be undefined on ARM64.
Use the instruction "brk" to generate a software debug exception.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch adds EFI boot support for ARM based on the previous refactoring of
the x86 EFI boot code. All ARM specific code is in the ARM efi-boot.h header
file, with the main EFI entry point common/efi/boot.c. The PE/COFF header is
open-coded in head.S, which allows us to have a single binary be both an EFI
executable and a normal arm64 IMAGE file. There is currently no PE/COFF
toolchain support for arm64, so it is not possible to create the PE/COFF header
in the same manner as on x86. This also simplifies the build as compared to
x86, as we always build the same executable, whereas x86 builds 2. An ARM
version of efi-bind.h is added, which is based on the x86_64 version with the
x86 specific portions removed. The Makefile in common/efi is different for x86
and ARM, as for ARM we always build in EFI support.
NR_MEM_BANKS is increased, as memory regions are now added from the UEFI memory map,
rather than memory banks from a DTB. The UEFI memory map may be fragmented so a larger
number of regions will be used.
Signed-off-by: Roy Franz <roy.franz@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- applied vga.h movement fixup patch from Roy, plus moved the xen/vga.h
include before the asm/* ones. ]
I started porting QEMU over to use the new ioreq server API and hit a
problem with PCI bus enumeration. Because, with my patches, QEMU only
registers to handle config space accesses for the PCI device it implements
all other attempts by the guest to access 0xcfc go nowhere and this was
causing the vcpu to wedge up because nothing was completing the I/O.
This patch introduces an I/O completion handler into the hypervisor for the
case where no ioreq server matches a particular request. Read requests are
completed with 0xf's in the data buffer, writes and all other I/O req types
are ignored.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
* Introduce hvm_dump_emulation_state() to be a common implementation rather
than having the printk() open-coded slightly differently in 3 separate
places.
* Identify the vcpu operating mode to allow for unambiguous decoding of the
instruction bytes.
* A valid instruction can be up to 15 bytes long, but may also be shorter than
the current arbitrary 10 bytes. Print only the fetched bytes, which could
include nothing if the emulation failed due to an inability to fetch the
instruction.
A sample new error message looks like:
(d1) MMIO emulation failed: d1v0 64bit @ 0008:ffff82d0802c4f20 -> 48 8b b8 e8 7f 00 00
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
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
Jon Fraser
Roy Franz
Vitaly Kuznetsov
Julien Grall
Roger Pau Monne
Paul Durrant