It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.
Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
supported.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh and fix compilation on x86 ] Signed-off-by: Wei Liu <wei.liu2@citrix.com>
It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI. And the generation codes
are only built for 64-bit toolstack.
tools/libxl: Add an unified configuration option for ACPI
Since the existing configuration option "u.hvm.acpi" is x86 specific and
we want to reuse it on ARM as well, add a unified option "acpi" for
x86 and ARM, and for ARM it's disabled by default.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Wed, 28 Sep 2016 12:00:31 +0000 (06:00 -0600)]
pub-headers: reduce C99 dependencies
For consumers not using (fully) C99-aware compilers, limit the number
of places where tweaking of the headers would be necessary: Introduce
and use xen_mk_ullong(), allowing its helper macro to be overridden at
once.
For now don't touch public/io/, which also has a few offenders.
The need to include xen.h in hvm/e820.h demonstrates that it is a bad
idea to include public headers first thing - arch/x86/hvm/mtrr.c needs
adjustment just because of this.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Fri, 30 Sep 2016 08:01:14 +0000 (10:01 +0200)]
x86emul: simplify LEAVE handling
There's no 1-byte operand size case to take care of here, and there's
no point doing the first writeback using dst fields - we can read rBP
and write rSP directly.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 30 Sep 2016 07:55:08 +0000 (09:55 +0200)]
x86/PV: split out dealing with DRn from privileged instruction handling
This is in preparation for using the generic emulator here.
Some care is needed temporarily to not unduly alter guest register
state: The local variable "res" can only go away once this code got
fully switched over to using x86_emulate().
Also switch to IS_ERR_VALUE() instead of (incorrectly) open coding it.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Fri, 30 Sep 2016 07:52:52 +0000 (09:52 +0200)]
x86emul: fix {,i}mul and {,i}div
Commit a3db233ede ("x86emul: use DstEax also for {,I}{MUL,DIV}") went
a little too far: DstEax and SrcEax weren't really meant to be used
together with ModRM - they assume modrm_reg remains zero by the time
the destination / source register pointer gets calculated. Don't fully
undo that commit though, but instead just correct the register pointer,
and don't use dst.val as input for mul and imul (div and idiv did avoid
that already).
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tamas K Lengyel [Thu, 29 Sep 2016 00:55:47 +0000 (18:55 -0600)]
vm_event: Implement ARM SMC events
The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.
The intended use-case for this feature is for a monitor application to be able
insert tap-points into the domU kernel-code. For this task only unconditional
SMC instruction should be used.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Paul Lai [Thu, 29 Sep 2016 10:05:06 +0000 (12:05 +0200)]
x86: altp2m cleanup work
Indent goto labels by one space.
Inline (header) altp2m functions.
In do_altp2m_op(), during the sanity check of the passed command,
return -EOPNOTSUPP if not a valid command.
In do_altp2m_op(), when evaluating a command, ASSERT_UNREACHABLE()
if the command is not recognizable. The sanity check above should
have triggered the return of -EOPNOTSUPP.
Make hvm_funcs.altp2m_supported "bool" instead of "bool_t".
Make hvm_altp2m_supported() and altp2m_vcpu_emulate_ve() return
bool (rather than return void()).
Signed-off-by: Paul Lai <paul.c.lai@intel.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 29 Sep 2016 10:03:12 +0000 (12:03 +0200)]
x86emul: complete decoding of two-byte instructions
This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.
This at once adds correct raising of #UD for the three "ud<n>" flavors
(Intel names only "ud2", but AMD names all three of them in their
opcode maps), as that may make a difference to callers compared to
getting back X86EMUL_UNHANDLEABLE.
Note on opcodes 0FA6 and 0FA7: These are VIA's PadLock instructions,
which have a ModRM like byte where only register forms are valid. I.e.
we could also use SrcImmByte there, but ModRM is more likely to be
correct for a hypothetical extension allowing non-register operations.
Note on opcode 0FB8: I think we're safe to ignore the Itanium specific
JMPE (which doesn't take a ModRM byte, but an immediate).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 29 Sep 2016 10:02:39 +0000 (12:02 +0200)]
x86emul: track only rIP in emulator state
Now that all decoding happens in x86_decode() there's no need to keep
the local registers copy in struct x86_emulate_state. Only rIP gets
updated in the decode phase, so only that register needs tracking
there. All other (read-only) registers can be read from the original
structure (but sadly, due to it getting passed to decode_register(),
the pointer can't be made point to "const" to make the compiler help
ensure no modification happens).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 29 Sep 2016 10:02:15 +0000 (12:02 +0200)]
x86emul: fetch all insn bytes during the decode phase
This way we can offer to callers the service of just sizing
instructions, and we also can better guarantee not to raise the wrong
fault due to not having read all relevant bytes.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The only way a guest may trip with stage 2 access violation is if mem_access is
or was in-use, so reinjecting these exceptions to the guest is never required.
xen: libxc: allow to set the ratelimit value online
The main purpose of the patch is to provide the xen-libxc
plumbing necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).
While there:
- mention in the Xen logs when rate limiting was enables
and is being disabled (and vice-versa);
- fix csched2_sys_cntl() which was always returning
-EINVAL in the XEN_SYSCTL_SCHEDOP_putinfo case.
And also:
- fix style of an if in csched_sys_cntl();
- fix the style of the switch in csched2_sys_cntl();
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:22:01 +0000 (09:22 -0400)]
libxc/libxl: Allow multiple ACPI modules
Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.
We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:22:00 +0000 (09:22 -0400)]
libacpi: Build DSDT for PVH guests
PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:57 +0000 (09:21 -0400)]
acpi/hvmloader: Include file/paths adjustments
In prepearation to moving acpi sources into generally available
libacpi:
1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
2. Modify include files search paths to point to acpi directory
3. Macro-ise include file for build.c that defines various
utilities used by that file. Users of libacpi will be expected
to define this macro when compiling build.c
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:56 +0000 (09:21 -0400)]
acpi/hvmloader: Link ACPI object files directly
ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:55 +0000 (09:21 -0400)]
acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables
Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:54 +0000 (09:21 -0400)]
acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:49 +0000 (09:21 -0400)]
acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
ACPI builder is currently distributed under GPLv2 license.
We plan to make the builder available to components other than the
hvmloader (which is also GPLv2). Some of these components (such as
libxl) may be distributed under LGPL-2.1 so that they can be used by
non-GPLv2 callers. But this will not be possible if we incorporate
the ACPI builder in those other components.
To avoid this problem we are relicensing sources in ACPI bulder
directory to the Lesser GNU Public License (LGPL) version 2.1
gpl/mk_dsdt_asl.sh file will remain GPL-only pending permission to
relicense from Lenovo due to commit 801d469ad ("[HVM] ACPI support
patch 3 of 4: ACPI _PRT table."))
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Daniel Kiper <dkiper@net-space.pl> Acked-by: Stefan Berger <stefanb@us.ibm.com> Acked-by: Kouya Shimura <kouya@jp.fujitsu.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Simon Horman <horms@verge.net.au> Acked-by: Lars Kurth <lars.kurth@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [for Oracle, VirtualIron and Sun contributions]
Boris Ostrovsky [Wed, 28 Sep 2016 13:21:48 +0000 (09:21 -0400)]
acpi: Prevent GPL-only code from seeping into non-GPL binaries
Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed under
GPLv2. We want to prevent this code from showing up in non-GPL
binaries which might become possible after we make ACPI builder code
available to users other than hvmloader.
There are two pieces that we need to be careful about:
(1) A small chunk of code in dsdt.asl that implements _PIC method
(2) A chunk of ASL generator in mk_dsdt.c that describes with PCI
interrupt routing.
This code will now be generated by a GPL-only script which will be
invoked only when ACPI builder's Makefile is called with GPL variable
set.
We also strip license header from generated ASL files to prevent
inadverent use of those files with incorrect license.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
grub_printf() is supporting only a very limited number of formats.
Especially some error messages suffer from that, e.g. %lx won't work.
Switch to use printk() for error messages instead.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
pvgrub: fix crash when booting kernel with p2m list outside kernel mapping
When trying to boot a kernel with the p2m list not mapped by the
initial kernel mapping it can happen that pvgrub is failing as it is
keeping some page tables mapped.
Unmap the additional page tables created for the special p2m mapping
will avoid this failure.
Reported-by: Sven Koehler <sven.koehler@gmail.com> Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the necessary livepatch infrastructure pieces in.
This patch adds three major pieces:
1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL<cond>,
MOVT, and MOVW instructions.
The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)
2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)
3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.
Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com> [for non-ARM parts] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
The input and output parameters for $(OBJCOPY) are different
based on the platforms. As such provide them in the
OBJCOPY_MAGIC define and use that.
2) The alternative is a bit different (exists only under ARM64
and x86), while and there are no exceptions under ARM at all.
We use the LIVEPATCH_FEATURE CPU id feature for ARM similar to
how it is done on x86.
We are not yet attempting to build them under ARM32 so
that is still ifdefed out.
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
livepatch/arm/x86: Check payload for for unwelcomed symbols.
Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are supposed
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]
Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.
Either way - we can ignore these symbols.
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> [x86 bits] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
livepatch: ARM/x86: Check displacement of old_addr and new_addr
If the distance is too big we are in trouble - as our relocation
distance can surely be clipped, or still have a valid width - but
cause an overflow of distance.
On various architectures the maximum displacement for a unconditional
branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86
for 32-bit relocations is +/- 2G.
Note: On x86 we could use the 64-bit jmpq instruction which
would provide much bigger displacement to do a jump, but we would
still have issues with the new function not being able to reach
any of the old functions (as all the relocations would assume 32-bit
displacement). And "furthermore would require an register or
memory location to load/store the address to." (From Jan).
On ARM the conditional branch supports even a smaller displacement
but fortunately we are not using that.
Reviewed-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.
Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() declaration") to return
an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).
The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).
The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")
And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").
In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.
We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.
Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com> [non-arm parts] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Rename p2m_mmio_direct_nc to p2m_mmio_direct_dev to better
express that we are mapping device memory. This will allow us
to use p2m_mmio_direct_nc for Normal Non-Cached mappings.
No functional change.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Earlier patches exported the p2m interface (p2m_get_entry and
p2m_set_entry) to allow splitting xen/arch/arm/p2m.c. Those functions
require the callers to lock the p2m, so we need to export p2m_*_lock
helpers.
All helpers but p2m_write_unlock but p2m_write_unlock are moved in
xen/include/asm-arm/p2m.h to allow inlining. The helpers
p2m_write_unlock is kept in p2m.c because it depends on a static
function.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to ensure the MMIO are not kept half-mapped
in case of failure and to follow the x86 counterpart. This was removed
on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
mappings" and I think we should let the caller taking care of it.
Finally drop the operation INSERT in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at the
end, however I find easier to drop the operations one by one avoiding a
big deletion in the patch that convert the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Re-implement p2m_remove_using using p2m_set_entry
The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.
Also drop the operation REMOVE in apply_* as nobody is using it anymore.
Note that the functions could have been dropped in one go at the end,
however I find easier to drop the operations one by one avoiding a big
deletion in the patch that converts the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabelini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_{get,set}_entry
The function relinquish_p2m_mapping can be re-implemented using
p2m_{get,set}_entry by iterating over the range mapped and using the
mapping order given by the callee.
Given that the preemption was chosen arbitrarily, it is now done on every
512 iterations. Meaning that Xen may check more often if the function is
preempted when there are no mappings.
Finally drop the operation RELINQUISH in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at
the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that remove the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry
The ARM architecture mandates to use of a break-before-make sequence
when changing translation entries if the page table is shared between
multiple CPUs whenever a valid entry is replaced by another valid entry
(see D4.7.1 in ARM DDI 0487A.j for more details).
The break-before-make sequence can be divided in the following steps:
1) Invalidate the old entry in the page table
2) Issue a TLB invalidation instruction for the address associated
to this entry
3) Write the new entry
The current P2M code implemented in apply_one_level does not respect
this sequence and may result to break coherency on some processors.
Adapting the current implementation to use the break-before-make
sequence would imply some code duplication and more TLBs invalidation
than necessary. For instance, if we are replacing a 4KB page and the
current mapping in the P2M is using a 1GB superpage, the following steps
will happen:
1) Shatter the 1GB superpage into a series of 2MB superpages
2) Shatter the 2MB superpage into a series of 4KB pages
3) Replace the 4KB page
As the current implementation is shattering while descending and install
the mapping, Xen would need to issue 3 TLB invalidation instructions
which is clearly inefficient.
Furthermore, all the operations which modify the page table are using
the same skeleton. It is more complicated to maintain different code paths
than having a generic function that set an entry and take care of the
break-before-make sequence.
The new implementation is based on the x86 EPT one which, I think,
fits quite well for the break-before-make sequence whilst keeping
the code simple.
The main function of the new implementation is __p2m_set_entry. It will
only work on mapping that are aligned to a block entry in the page table
(i.e 1GB, 2MB, 4KB when using a 4KB granularity).
Another function, p2m_set_entry, is provided to break down is region
into mapping that is aligned to a block entry or 4KB when memaccess is
enabled.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry
The function p2m_cache_flush can be re-implemented using the generic
function p2m_get_entry by iterating over the range and using the mapping
order given by the callee.
As the current implementation, no preemption is implemented, although
the comment in the current code claimed it. As the function is called by
a DOMCTL with a region of 1GB maximum, I think the preemption can be
left unimplemented for now.
Finally drop the operation CACHEFLUSH in apply_one_level as nobody is
using it anymore. Note that the function could have been dropped in one
go at the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that convert the last operation.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup
Currently, for a given GFN, the function __p2m_lookup will only return
the associated MFN and the p2m type of the mapping.
In some case we need the order of the mapping and the memaccess
permission. Rather than providing a separate function for this purpose,
it is better to implement a generic function to return all the
information.
To avoid passing dummy parameter, a caller that does not need a
specific information can use NULL instead.
The list of the informations retrieved is based on the x86 version. All
of them will be used in follow-up patches.
It might have been possible to extend __p2m_lookup, however I choose to
reimplement it from scratch to allow sharing some helpers with the
function that will update the P2M (will be added in a follow-up patch).
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m
Sometimes the invalidation of the TLBs can be deferred until the p2m is
unlocked. This is for instance the case when multiple mappings are
removed. In other case, such as shattering a superpage, an immediate
flush is required.
Keep track whether a flush is needed directly in the p2m_domain structure
to allow serializing multiple changes. The TLBs will be invalidated when
write unlocking the p2m if necessary.
Also a new helper, p2m_flush_sync, has been introduced to force a
synchronous TLB invalidation.
Finally, replace the call to p2m_flush_tlb by p2m_flush_tlb_sync in
apply_p2m_changes.
Note this patch is not useful today, however follow-up patches will make
advantage of it.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: traps: Check the P2M before injecting a data/instruction abort
A data/instruction abort may have occurred if another CPU was playing
with the stage-2 page table when following the break-before-make
sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
the fault to the guest, we need to check whether the mapping exists. If
it exists, return to the guest to replay the instruction.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: traps: Move MMIO emulation code in a separate helper
Currently, a stage-2 fault translation will likely access an emulated
region. All the checks are pre-sanitity check for MMIO emulation.
A follow-up patch will handle a new case that could lead to a stage-2
translation. To improve the clarity of the code and the changes, the
current implementation is move in a separate helper.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Use typesafe gfn in p2m_mem_access_radix_set
p2m_mem_access_radix_set is expecting a gfn in a parameter. Rename the
parameter 'pfn' to 'gfn' to match its content and use the typesafe gfn
to avoid possible misusage.
Also rename the parameter to gfn to match its content.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/arm: p2m: Store in p2m_domain whether we need to clean the entry
Each entry in the page table has to be cleaned when the IOMMU does not
support coherent walk. Rather than querying every time the page table is
updated, it is possible to do it only once when the p2m is initialized.
This is because this value can never change, Xen would be in big trouble
otherwise.
With this change, the initialization of the IOMMU for a given domain has
to be done earlier in order to know whether the page table entries need
to be cleaned. It is fine to move the call earlier because it has no
dependency.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Currently configure code doesn't define {SEABIOS/OVMF}_PATH when
--with-system-{ovmf/seabios} is used. Fix this by making sure those
defines are always set if the internal {ovmf/seabios}_path variables are
also set.
Tamas K Lengyel [Mon, 26 Sep 2016 16:04:11 +0000 (18:04 +0200)]
x86/vm_event: allow overwriting Xen's i-cache used for emulation
When emulating instructions Xen's emulator maintains a small i-cache fetched
from the guest memory. This patch extends the vm_event interface to allow
overwriting this i-cache via a buffer returned in the vm_event response.
When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
normally has to remove the INT3 from memory - singlestep - place back INT3
to allow the guest to continue execution. This routine however is susceptible
to a race-condition on multi-vCPU guests. By allowing the subscriber to return
the i-cache to be used for emulation it can side-step the problem by returning
a clean buffer without the INT3 present.
As part of this patch we rename hvm_mem_access_emulate_one to
hvm_emulate_one_vm_event to better reflect that it is used in various vm_event
scenarios now, not just in response to mem_access events.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Andrew Cooper [Mon, 26 Sep 2016 14:28:21 +0000 (14:28 +0000)]
x86/svm: Drop the set_segment_register() macro
Replace its sole users with a single piece of inline assembly which is more
flexable about its register constraints, rather than forcing the use of %ax.
While editing this area, reflow the comment to remove trailing whitespace and
use fewer lines.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
AMD F12h machines have an erratum which can cause DIV/IDIV to behave
unpredictably. The workaround is to set MSRC001_1029[31] but sometimes
there is no BIOS update containing that workaround so let's do it
ourselves unconditionally. It is simple enough.
Jan Beulich [Mon, 26 Sep 2016 15:27:06 +0000 (17:27 +0200)]
x86emul: don't allow null selector for LTR
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 26 Sep 2016 15:21:36 +0000 (17:21 +0200)]
x86emul: correct loading of %ss
- Instead of #NP, #SS needs to be raised for non-present descriptors.
- Loading a null selector is fine in 64-bit mode at CPL != 3, as long
as RPL == CPL.
- Don't lose the low two selector bits on null selector loads (also
applies to %ds, %es, %fs, %gs, and LDTR).
Since we need CPL earlier now, also switch to using get_cpl() (instead
of open coding it).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
While putting together another patch modifying the secondary exec
controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE
instead of going through the designated function. I assume that is not
how it should be.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any alignment information - hence they end up being the default
byte granularity.
On ARM32 it is paramount that the alignment is word-size (4)
otherwise if one tries to use (uint32_t*) access (such
as livepatch ELF relocations) we get a Data Abort.
Enforcing bug_frames to have the proper alignment across all
architectures and in both C and x86 makes them all the same.
Furthermore on x86 the bloat-o-meter detects that with this
change:
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new delta
On ARM32:
add/remove: 1/0 grow/shrink: 0/1 up/down: 384/-288 (96)
function old new delta
gnttab_unpopulate_status_frames - 384 +384
do_grant_table_op 10808 10520 -288
And ARM64:
add/remove: 1/2 grow/shrink: 0/1 up/down: 4164/-4236 (-72)
function old new delta
gnttab_map_grant_ref - 4164 +4164
do_grant_table_op 9892 9836 -56
grant_map_exists 300 - -300
__gnttab_map_grant_ref 3880 - -3880
Reviewed-by: Julien Grall <julien.grall@arm.com> Acked-by: Jan Beulich <jbeulich@suse.com> [x86 parts] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Creates a nice crash if one executes that code:
(XEN) CPU1: Unexpected Trap: Supervisor Call
But unfortunately that may not be a good choice either as in the future
we may want to implement support for it.
Julien suggested that we use a 4-byte insn instruction instead
of trying to work with one byte. To make sure nothing goes bad
we also require that the __init_[begin|end] be aligned properly.
As such on ARM 32 we use the udf instruction (see A8.8.247
in ARM DDI 0406C.c) and on ARM 64 use the AARCH64_BREAK_FAULT
instruction (aka brk instruction).
We don't have to worry about Thumb code so this instruction
is a safe to execute.
Reviewed-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
projects / xen.git / log