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>
This behaves in the same way as Linux. The 64 byte limit is arbitrary but
long enough for practical purposes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Re-structured code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
As a general library routine, it should behave as efficiently as
possible, even if at present no significant contention is known here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
AMD SVM requires all software events to have their injection emulated if
hardware lacks NextRIP support. In addition, `icebp` (opcode 0xf1) injection
requires emulation in all cases, even with hardware NextRIP support.
Emulating full control transfers is overkill for our needs. All that matters
is that guest userspace can't bypass the descriptor DPL check. Any guest OS
which would incur other faults as part of injection is going to end up with a
double fault instead, and won't be in a position to care that the faulting eip
is wrong.
Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Injecting emulator software events as hardware exceptions results in a bypass
of DPL checks. As the emulator doesn't perform DPL checks itself, guest
userspace is capable of bypassing DPL checks and injecting arbitrary events.
Propagating software event information from the emulator allows VMX to now
properly inject software events, including DPL and presence checks, as well
correct fault/trap frames.
Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrei LUTAS <vlutas@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
This is needed by subsequent patches to support correctly injecting sofware
events for HVM Guests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
If HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN, or HVM_PARAM_BUFIOREQ_EVTCHN
parameters are read when guest domain is dying it leads to the following
ASSERT:
(XEN) Assertion '_raw_spin_is_locked(lock)' failed at ...workspace/KERNEL/xen/xen/include/asm/spinlock.h:18
(XEN) ----[ Xen-4.5-unstable x86_64 debug=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d08012b07f>] _spin_unlock+0x27/0x30
(XEN) [<ffff82d0801b6103>] hvm_create_ioreq_server+0x3df/0x49a
(XEN) [<ffff82d0801bcceb>] do_hvm_op+0x12bf/0x27a0
(XEN) [<ffff82d08022b9bb>] syscall_enter+0xeb/0x145
The root cause of this issue is the fact that ioreq_server.lock is being
released twice - first in hvm_ioreq_server_init() and then in hvm_create_ioreq_server().
Drop the lock release from hvm_ioreq_server_init() as we don't take it here, do minor
label cleanup.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Move architecture specific sanity checks into its own function
which is called when enabling mem_event.
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Acked-by: Tim Deegan <tim@xen.org>
A faulty tool stack can brick a debug hypervisor. Unpleasant while dev/test.
Suggested-by: Andres Lagar Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Acked-by: Tim Deegan <tim@xen.org>
Relocate p2m_mem_access_resume to common and abstract the new
p2m_mem_event_emulate_check into the p2m layer to.
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Acked-by: Tim Deegan <tim@xen.org>
We swap the order of the enum of types n ... rwx, as to have rwx at 0, which is
the default setting when mem_access is not in use. This has performance benefits for
non-memaccess paths, as now comparison is to 0 when checking if memaccess is in use,
which is often faster.
We fix one location in nested_hap where the order of the enum made a difference.
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Acked-by: Tim Deegan <tim@xen.org>
Aravind Gopalakrishnan
Andrew Cooper
Jan Beulich
Suravee Suthikulpanit
Frediano Ziglio
Jon Fraser
Roy Franz
Vitaly Kuznetsov
Julien Grall
Roger Pau Monne
Olaf Hering
Tamas K Lengyel
Paul Durrant
Wei Liu