Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:
Jan Beulich [Tue, 6 Feb 2018 16:29:33 +0000 (17:29 +0100)]
libxc: don't fail domain creation when unpacking initrd fails
At least Linux kernels have been able to work with gzip-ed initrd for
quite some time; initrd compressed with other methods aren't even being
attempted to unpack. Furthermore the unzip-ing routine used here isn't
capable of dealing with various forms of concatenated files, each of
which was gzip-ed separately (it is this particular case which has been
the source of observed VM creation failures).
Hence, if unpacking fails, simply hand the compressed blob to the guest
as is.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Fri, 2 Feb 2018 16:10:17 +0000 (16:10 +0000)]
x86/emul: Fix the emulation of invlpga
The instruction requires EFER.SVME set to be usable in the first place.
Furthermore, the emulation doesn't handle ASIDs, so avoid giving the
impression that they work. Permit ASID 0 which is reserved for non-root
mode (in which case the instruction is identical to invlpg), but raise #UD for
any other ASID.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Brian Woods [Mon, 5 Feb 2018 09:15:25 +0000 (10:15 +0100)]
x86/svm: correct EFER.SVME intercept checks
Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section
15.4 for more details. VMMCALL isn't checked due to guests needing it
to boot.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Brian Woods <brian.woods@amd.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Brian Woods [Mon, 5 Feb 2018 09:14:48 +0000 (10:14 +0100)]
x86/svm: update VGIF support
There are places where the GIF value is checked. A guest with VGIF
enabled can change the GIF value without the host being involved,
therefore it needs to check the GIF value in the VMCB rather the one in
the nestedsvm struct.
Signed-off-by: Brian Woods <brian.woods@amd.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Jan Beulich [Mon, 5 Feb 2018 09:14:15 +0000 (10:14 +0100)]
x86emul: add missing suffixes in test harness
I'm in the process of putting together a gas change issuing at least
warnings when the intended size of a memory operation can't be deduced
from another (register) operand. Add missing suffixes to silence such
future diagnostics.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Julien Grall [Fri, 2 Feb 2018 10:14:44 +0000 (10:14 +0000)]
xen/arm: Don't crash the domain on invalid HVC immediate
domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in a better
position to provide helpful information (stack trace...).
Julien Grall [Fri, 2 Feb 2018 10:14:43 +0000 (10:14 +0000)]
xen/arm: Don't crash domain on bad MMIO emulation
Now the MMIO emulation is able to distinguish unhandled IO from aborted
one, there are no need to crash the domain when the region is access
with a bad width.
Instead let Xen inject a data abort to the guest and decide what to do.
Julien Grall [Fri, 2 Feb 2018 10:14:42 +0000 (10:14 +0000)]
xen/arm: io: Distinguish unhandled IO from aborted one
Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.
However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
should avoid to try another way and directly inject a guest data abort.
Introduce a tri-state return to distinguish the following state:
* IO_ABORT: The IO was handled but resulted in an abort
* IO_HANDLED: The IO was handled
* IO_UNHANDLED: The IO was unhandled
For now, it is considered that an IO belonging to an emulated range
could either be handled or inject an abort. This could be revisit in the
future if overlapped region exist (or we want to try another way to
resolve the abort).
Julien Grall [Fri, 2 Feb 2018 10:14:41 +0000 (10:14 +0000)]
xen/arm: traps: Merge try_handle_mmio() and handle_mmio()
At the moment, try_handle_mmio() will do check on the HSR and bail out
if one check fail. This means that another method will be tried to
handle the fault even for bad access on emulated region. While this
should not be an issue, this is not future proof.
Move the checks of try_handle_mmio() in handle_mmio() after we identified
the fault to target an emulated MMIO. While this does not fix the potential
fall-through, a follow-up patch will do by distinguish the potential error.
Note that the handle_mmio() was renamed to try_handle_mmio() and the
prototype adapted.
While merging the 2 functions, remove the check whether the fault is
stage-2 abort on stage-1 translation walk because the instruction
syndrome will always be invalid (see B3-1433 in DDI 0406C.c and
D10-2460 in DDI 0487C.a).
Julien Grall [Fri, 2 Feb 2018 14:19:25 +0000 (14:19 +0000)]
xen/arm32: entry: Document the purpose of r11 in the traps handler
It took me a bit of time to understand why __DEFINE_TRAP_ENTRY is
storing the original stack pointer in r11. It is working in pair with
return_traps_entry where sp will be restored from r11.
This is fine because per the AAPCS r11 must be preserved by the
subroutine. So in return_from_trap, r11 will still contain the original
stack pointer.
Add some documentation in the code to point the 2 sides to each other.
Julien Grall [Fri, 2 Feb 2018 14:19:24 +0000 (14:19 +0000)]
xen/arm32: Invalidate icache on guest exist for Cortex-A15
In order to avoid aliasing attacks against the branch predictor on
Cortex A-15, let's invalidate the BTB on guest exit, which can only be
done by invalidating the icache (with ACTLR[0] being set).
We use the same hack as for A12/A17 to perform the vector decoding.
This is based on Linux patch from the kpti branch in [1].
Julien Grall [Fri, 2 Feb 2018 14:19:23 +0000 (14:19 +0000)]
xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.
This is based on the fourth version posted by Marc Zyngier on Linux-arm
mailing list (see [1]).
Julien Grall [Fri, 2 Feb 2018 14:19:22 +0000 (14:19 +0000)]
xen/arm32: Add skeleton to harden branch predictor aliasing attacks
Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.
This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementation-specific mitigations against these attacks
for CPUs that are affected.
Most of mitigations will have to be applied when entering to the
hypervisor from the guest context.
Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore this has to be done in the vector entry before jump to the
helper handling a given exception.
However, on arm32, each vector contain a single instruction. This means
that the hardened vector tables may rely on the state of registers that
does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
Therefore hypervisor code running with guest vectors table should be
minimized and always have IRQs and SErrors masked to reduce the risk to
use them.
This patch provides an infrastructure to switch vector tables before
entering to the guest and when leaving it.
Note that alternative could have been used, but older Xen (4.8 or
earlier) doesn't have support. So avoid using alternative to ease
backporting.
Julien Grall [Fri, 2 Feb 2018 14:19:21 +0000 (14:19 +0000)]
xen/arm32: entry: Add missing trap_reset entry
At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).
This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and will generate an
error message in the unlikely case that reset will be called.
Andrew Cooper [Tue, 30 Jan 2018 11:08:45 +0000 (11:08 +0000)]
arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure
ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to the point
of failing to compile.
Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Andrew Cooper [Thu, 11 Jan 2018 12:42:59 +0000 (12:42 +0000)]
x86/ioemul: Misc improvements to ioport_emulate.c
Put the opcode into an array and use memcpy. This allows the compiled code to
be written with two movs, rather than 10 mov $imm8's. Also, drop trailing
whitespace in the file.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 1 Feb 2018 10:32:45 +0000 (11:32 +0100)]
x86/shim: don't use 32-bit compare on boolean variable
Current upstream gas silently assumes 32-bit operand size for most
operations where the size can't be inferred from an involved register
(my own one doesn't anymore, which is how I've noticed this). It is pure
luck that the 3 bytes following pvh_boot are currently padding ones.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Thu, 25 Jan 2018 12:16:12 +0000 (12:16 +0000)]
x86/emul: Improvements to internal users of decode_register()
Most users of decode_register() can be replaced with decode_gpr() right away.
For the few sites which do care about possibly using the legacy byteop
encoding, rename decode_register() to _decode_gpr() (to match its non-legacy
counterpart), and adjust its 'int highbyte_regs' parameter to the more correct
'bool legacy'.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 25 Jan 2018 12:16:12 +0000 (12:16 +0000)]
x86/hvm: Improvements to external users of decode_register()
* Rename to decode_gpr() to be more specific as to its purpose
* Drop the highbyte encoding handling, as no users currently care, and it
unlikely that future users would care.
* Change to a static inline, returning an unsigned long pointer.
Doing so highlights that the "invalid gpr" paths in hvm_mov_{to,from}_cr()
were actually unreachable. All callers already passed in-range GPRs, and
out-of-range GPRs would have hit the BUG() previously.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 25 Jan 2018 12:16:12 +0000 (12:16 +0000)]
x86/emul: Optimise decode_register() somewhat
The positions of GPRs inside struct cpu_user_regs doesn't follow any
particular order, so as compiled, decode_register() becomes a jump table to 16
blocks which calculate the appropriate offset, at a total of 207 bytes.
Instead, pre-compute the offsets at build time and use pointer arithmetic to
calculate the result. By observation, most callers in x86_emulate() inline
and constant-propagate the highbyte_regs value of 0.
The splitting of the general and legacy byte-op cases means that we will now
hit an ASSERT if any code path tries to use the legacy byte-op encoding with a
REX prefix.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Wed, 31 Jan 2018 11:36:38 +0000 (12:36 +0100)]
x86: move declaration of the exception_table to C
This makes the code cleaner because there's no need to declare the
exception_table in assembly, and also fixes the following error when
using clang's integrated assembler:
Andre Przywara [Tue, 30 Jan 2018 09:35:05 +0000 (09:35 +0000)]
ARM: GICv3: copy Dom0 GICv3 reg property from host DT
At the moment we re-generate the Dom0 GICv3 DT node, by creating the
"reg" property from scratch using our previously parsed and
translated(!) host addresses. However we then write the *absolute*
addresses into the new node, not considering possible "range" mappings
in any of the GIC's parent nodes. So whenever one of the parents has a
non-empty ranges property, Dom0 will wrongly translate the addresses.
Properly incorporating the ranges properties sounds tedious, so let's
just copy the first part of the reg property instead (as we do for GICv2),
since the addresses for Dom0 are identical to those from the hardware.
The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
has the GIC in such an translated bus, so this patch allows this board
to boot properly (after adding support for the SoC's UART).
Julien Grall [Wed, 24 Jan 2018 18:26:16 +0000 (18:26 +0000)]
xen/arm: GICv3: Only initialize ITS when the distributor supports LPIs.
There are firmware tables out describing the ITS but does not support
LPIs. This will result to a data abort when trying to initialize ITS.
While this can be consider a bug in the Device-Tree, same configuration
boots on Linux. So gate the ITS initialization with the support of LPIs
in the distributor.
Julien Grall [Wed, 24 Jan 2018 18:26:15 +0000 (18:26 +0000)]
xen/arm: GICv3: Parse ITS information from the firmware tables later on
There are Device Tree (e.g for the Foundation Model) out that describes the
ITS but LPIs is not supported by the platform. Booting with such DT will
result to an early Data Abort. The same DT is booting fine with a
baremetal Linux because ITS will be initialized only when LPIs is
supported.
While this is a bug in the DT, I think Xen should be boot with the same
hardware level support (e.g ITS will not be used) as with a baremetal
Linux.
The slight problem is Xen is relying on gicv3_its_host_has_its() to know
if ITS can be used. The list is populated by gicv3_its_{dt,acpi}_init().
It would be theoretically possible to gate those with a check of
GICD_TYPER.LPIS because we don't know yet whether the HW is an actual
GICv3/GICv4.
Looking at the callers of gicv3_its_host_has_its(), they will only be
done after gicv3_its_init() is called. Therefore move the parsing of ITS
information from firmware tables later on.
Note that gicv3_its_init() has been moved at the end of the file to
avoid forward declaration.
Andrew Cooper [Sat, 27 Jan 2018 21:09:10 +0000 (21:09 +0000)]
x86/hvm: Drop hvm_set_mode() and associated vmx hooks
This is more vestigial rementants of PVHv1.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Sun, 21 Jan 2018 17:21:05 +0000 (17:21 +0000)]
xen/evtchn: Cleanup for virq_is_global() infrastructure
Switch it, and the arch infrastructure, to return bool. Drop the unnecessary
rc variable, and remove a redundant assertion from send_global_virq().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 29 Jan 2018 18:01:35 +0000 (18:01 +0000)]
x86/asm: Drop __GET_CURRENT()
__GET_CURRENT() is dangerous to use, as is easy to confuse with GET_CURRENT(),
but strictly depends on the regster parameter already having the STACK_END
value in it. Also, there is no reason to special case accesses of
current_vcpu differently to other cpuinfo fields.
Expand __GET_CURRENT() in its current users, and remove the macro.
Take the opportunity to replace the GET_CURRENT() in the cstar path which
doesn't need to recalculate STACK_END.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
This happens because initiate_domain_create() checks for type != HVM, then
pokes at the hvm union. Check for == HVM instead so the union access is
correctly guarded.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Andrew Cooper [Fri, 26 Jan 2018 19:33:40 +0000 (19:33 +0000)]
xen: Fix XSM build after dropping XEN_DOMCTL_getmemlist
c/s 94450e36bfbb removed XEN_DOMCTL_getmemlist entirely, but missed adjusting
the XSM side of things. As far as I can tell, 'pagelist' wasn't even offered
to dom0 in default policy.
Also, drop the stale struct xen_domctl_getmemlist which was missed from the
same changeset.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
x86/boot: turn the selftests ASSERT into a warning
On selftests failure, print a very visible warning instead of crashing
over an ASSERT.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Adjust to print extra information in the case of a failure
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 26 Jan 2018 15:59:51 +0000 (15:59 +0000)]
x86/boot: Make the "Building Dom0" messages consistent
Switch the PV message to match the wording of the PVH side, use the same
number of ***'s, explicitly identify PV vs PVH, set the log level at INFO, and
print the real domid (which won't be 0 in pv-shim mode).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 15 Jan 2018 10:00:51 +0000 (10:00 +0000)]
xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()
c/s 4ddf474e2 "tools/xen-mceinj: Pass in GPA when injecting through
MSR_MCI_ADDR" removed the remaining user of hypercall.
It has been listed as broken, deprecated and wont-fix since XSA-74, so take
this opportunity to remove it completely.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Christian Lindig <christian.lindig@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monne [Fri, 26 Jan 2018 15:29:10 +0000 (15:29 +0000)]
xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP
Disable SMAP in the shim before bouncing the hypercall, or else L0
will fail to get the hypercall buffer.
Reported-by: Fatih Acar <fatih.acar@gandi.net> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Fri, 3 Nov 2017 16:43:02 +0000 (16:43 +0000)]
x86/idle: Clear SPEC_CTRL while idle
On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads. It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.
Care must be taken to ensure there are no ret or indirect branch instructions
between spec_ctrl_{enter,exit}_idle() invocations, which are forced always
inline. Care must also be taken to avoid using spec_ctrl_enter_idle() between
flushing caches and becoming idle, in cases where that matters.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 16 Nov 2017 18:35:11 +0000 (18:35 +0000)]
x86/ctxt: Issue a speculation barrier between vcpu contexts
Issuing an IBPB command flushes the Branch Target Buffer, so that any poison
left by one vcpu won't remain when beginning to execute the next.
The cost of IBPB is substantial, and skipped on transition to idle, as Xen's
idle code is robust already. All transitions into vcpu context are fully
serialising in practice (and under consideration for being retroactively
declared architecturally serialising), so a cunning attacker cannot use SP1 to
try and skip the flush.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 19 Dec 2017 13:59:21 +0000 (13:59 +0000)]
x86/boot: Calculate the most appropriate BTI mitigation to use
See the logic and comments in init_speculation_mitigations() for further
details.
There are two controls for RSB overwriting, because in principle there are
cases where it might be safe to forego rsb_native (Off the top of my head,
SMEP active, no 32bit PV guests at all, no use of vmevent/paging subsystems
for HVM guests, but I make no guarantees that this list of restrictions is
exhaustive).
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 22 Jan 2018 14:41:33 +0000 (14:41 +0000)]
x86/entry: Avoid using alternatives in NMI/#MC paths
This patch is deliberately arranged to be easy to revert if/when alternatives
patching becomes NMI/#MC safe.
For safety, there must be a dispatch serialising instruction in (what is
logically) DO_SPEC_CTRL_ENTRY so that, in the case that Xen needs IBRS set in
context, an attacker can't speculate around the WRMSR and reach an indirect
branch within the speculation window.
Using conditionals opens this attack vector up, so the else clause gets an
LFENCE to force the pipeline to catch up before continuing. This also covers
the safety of RSB conditional, as execution it is guaranteed to either hit the
WRMSR or LFENCE.
One downside of not using alternatives is that there unconditionally an LFENCE
in the IST path in cases where we are not using the features from IBRS-capable
microcode.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 3 Nov 2017 16:39:42 +0000 (16:39 +0000)]
x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen
ret instructions are speculated directly to values recorded in the Return
Stack Buffer/Return Address Stack, as there is no uncertainty in well-formed
code. Guests can take advantage of this in two ways:
1) If they can find a path in Xen which executes more ret instructions than
call instructions. (At least one in the waitqueue infrastructure,
probably others.)
2) Use the fact that the RSB/RAS in hardware is actually a circular stack
without a concept of empty. (When it logically empties, stale values
will start being used.)
To mitigate, overwrite the RSB on entry to Xen with gadgets which will capture
and contain rogue speculation.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Fri, 3 Nov 2017 16:17:00 +0000 (16:17 +0000)]
x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point
We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context. See the documentation in
asm-x86/spec_ctrl_asm.h for details.
With the contemporary microcode, writes to %cr3 are slower when SPEC_CTRL.IBRS
is set. Therefore, the positioning of SPEC_CTRL_{ENTRY/EXIT}* is important.
Ideally, the IBRS_SET/IBRS_CLEAR hunks might be positioned either side of the
%cr3 change, but that is rather more complicated to arrange, and could still
result in a guest controlled value in SPEC_CTRL during the %cr3 change,
negating the saving if the guest chose to have IBRS set.
Therefore, we optimise for the pre-Skylake case (being far more common in the
field than Skylake and later, at the moment), where we have a Xen-preferred
value of IBRS clear when switching %cr3.
There is a semi-unrelated bugfix, where various asm_defn.h macros have a
hidden dependency on PAGE_SIZE, which results in an assembler error if used in
a .macro definition.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 14 Nov 2017 19:22:28 +0000 (19:22 +0000)]
x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL,PRED_CMD}
For performance reasons, HVM guests should have direct access to these MSRs
when possible.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is
implemented as a straight #GP for now to avoid being leaky when new hardware
arrives.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 16 Jan 2018 15:45:51 +0000 (15:45 +0000)]
x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests
Intel specifies IBRS/IBPB (combined, in a single bit) and STIBP as a separate
bit. AMD specifies IBPB alone in a 3rd bit.
AMD's IBPB is a subset of Intel's combined IBRS/IBPB. For performance
reasons, administrators might wish to express "IBPB only" even on Intel
hardware, so we allow the AMD bit to be used for this purpose.
The behaviour of STIBP is more complicated.
It is our current understanding that STIBP will be advertised on HT-capable
hardware irrespective of whether HT is enabled, but not advertised on
HT-incapable hardware. However, for ease of virtualisation, STIBP's
functionality is ignored rather than reserved by microcode/hardware on
HT-incapable hardware.
For guest safety, we treat STIBP as special, always override the toolstack
choice, and always advertise STIBP if IBRS is available. This removes the
corner case where STIBP is not advertised, but the guest is running on
HT-capable hardware where it does matter.
Finally as a bugfix, update the libxc CPUID logic to understand the e8b
feature leaf, which has the side effect of also offering CLZERO to guests on
applicable hardware.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 25 Jan 2018 18:38:17 +0000 (18:38 +0000)]
xen/build: Untangle CONFIG_DEBUG and CONFIG_FRAME_POINTER
Both options are independently choseable in KConfig, but currently a DEBUG
build without FRAME_POINTER is left to the compilers default choice, not the
users choice.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 26 Jan 2018 12:26:57 +0000 (13:26 +0100)]
x86/p2m: force return value checking of p2m_set_entry()
As XSAs 246 and 247 have shown, not doing so is rather dangerous.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Wei Liu [Thu, 25 Jan 2018 13:14:24 +0000 (13:14 +0000)]
xen: Fix xsm build after [g]cov renaming
Commit e8d461497d9 renamed gcov_op to coverage_op but forgot to change
XSM handles.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl: use libxl__device_kind to get device XS entry
On adding to XS name of device is taken from
libxl__device_kind enum. On getting device from XS
the name is hardcoded. It leads to potential
mistmatch errors. The patch is using libxl__device_kind
everywere to have one source of device name.
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Wei Liu [Wed, 24 Jan 2018 20:26:26 +0000 (20:26 +0000)]
x86: fix GET_STACK_END
AIUI the purpose of having the .if directive is to make GET_STACK_END
work with any general purpose registers. The code as-is would produce
the wrong result for r8. Fix it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monné [Thu, 25 Jan 2018 11:30:01 +0000 (12:30 +0100)]
coverage: introduce generic file
It will contain the generic implementation of sysctl_cov_op, which
will be shared between all the coverage implementations.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monné [Thu, 25 Jan 2018 11:27:44 +0000 (12:27 +0100)]
gcov: rename sysctl and functions
Change gcov to cov (for internal interfaces) or coverage (for the
public ones).
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:26:55 +0000 (12:26 +0100)]
x86/domctl: remove XEN_DOMCTL_pin_mem_cacheattr
Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has
been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so
that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and
have it call the new dmop. Leave the definitions of
XEN_DOMCTL_MEM_CACHEATTR_* since they are still used by QEMU.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:26:36 +0000 (12:26 +0100)]
libxendevicemodel: provide xendevicemodel_pin_memory_cacheattr
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:26:23 +0000 (12:26 +0100)]
libxendevicemodel: provide xendevicemodel_relocate_memory
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:25:22 +0000 (12:25 +0100)]
x86/hvm: provide XEN_DMOP_pin_memory_cacheattr
Provide XEN_DMOP_pin_memory_cacheattr to allow a deprivileged QEMU to
pin the caching type of RAM after moving the VRAM. It is equivalent to
XEN_DOMCTL_pin_memory_cacheattr.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:24:14 +0000 (12:24 +0100)]
x86/hvm: provide XEN_DMOP_relocate_memory
Provide XEN_DMOP_relocate_memory, a limited version of
XENMEM_add_to_physmap to allow a deprivileged QEMU to move VRAM when a
guest programs its BAR. It is equivalent to XENMEM_add_to_physmap with
space == XENMAPSPACE_gmfn_range.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Ross Lagerwall [Thu, 25 Jan 2018 11:23:35 +0000 (12:23 +0100)]
mm: make xenmem_add_to_physmap global
Make it global in preparation to be called by a new dmop.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Wed, 24 Jan 2018 14:11:16 +0000 (14:11 +0000)]
xen/VT-d: Remove the use of __LINE__ from IOMMU_WAIT_OP()
The use of __LINE__ in printk()'s is problematic for livepatching, as it tends
to cause unnecessary binary differences.
Take this opportunity to provide some rather more useful information than just
file/line/func in the form of the full register/stack trace leading to the
problem (which I've needed in the past for debugging).
Also, drop the unnecessary else clause while editing here here.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Wed, 24 Jan 2018 12:01:55 +0000 (12:01 +0000)]
x86/pv: Export pv_hypercall_table[] rather than working around it in several ways
The functions in compat.c are thing wrappers around the main hypercalls,
massaging certain parameters. However, they second-guess the content of
pv_hypercall_table[], which is problematic for the shim case. Instead,
arrange for them to call via function pointer, which removes the need for
pv_get_hypercall_handler().
With pv_hypercall_table[] exported, there is no need for
pv_hypercall_table_replace(), so its single callsite gets modified to cope.
The backing code behind __va(__pa()) is substantial, and there is no need to
calculate it repeatedly (Xen's .rodata is also contiguous in the directmap).
While adjusting the declarations, guard content in arch/x86/pv with CONFIG_PV.
The net difference is:
add/remove: 0/2 grow/shrink: 4/1 up/down: 176/-321 (-145)
function old new delta
pv_shim_setup_dom 1130 1266 +136
do_sched_op_compat 176 192 +16
compat_physdev_op_compat 90 106 +16
do_physdev_op_compat 98 106 +8
do_event_channel_op_compat 145 123 -22
pv_get_hypercall_handler 28 - -28
pv_hypercall_table_replace 271 - -271
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Wed, 24 Jan 2018 17:02:14 +0000 (18:02 +0100)]
x86/acpi: process softirqs while printing CPU ACPI data
Or else the watchdog triggers on boxes with a huge number of CPUs
Reported-by: Simon Crowe <simon.crowe@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Wed, 24 Jan 2018 17:01:33 +0000 (18:01 +0100)]
x86/compat: fix compilation errors with clang 6
The following errors are generated when compiling Xen with clang 6:
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
In file included from /root/src/xen/xen/include/compat/arch-x86/../xen.h:9:
/root/src/xen/xen/include/compat/arch-x86/xen.h:10:10: error: the current #pragma pack aligment
value is modified in the included file [-Werror,-Wpragma-pack]
#include "xen-x86_32.h"
^
/root/src/xen/xen/include/compat/arch-x86/xen-x86_32.h:40:9: note: previous '#pragma pack'
directive that modifies alignment is here
#pragma pack()
^
In file included from x86_64/asm-offsets.c:9:
In file included from /root/src/xen/xen/include/xen/sched.h:8:
In file included from /root/src/xen/xen/include/xen/shared.h:6:
/root/src/xen/xen/include/compat/arch-x86/../xen.h:9:10: error: the current #pragma pack aligment
value is modified in the included file [-Werror,-Wpragma-pack]
#include "arch-x86/xen.h"
^
/root/src/xen/xen/include/compat/arch-x86/xen.h:71:9: note: previous '#pragma pack' directive that
modifies alignment is here
#pragma pack()
^
2 errors generated.
Fix this by using pragma push/pop in order to store the current pragma
value in the compiler stack and later restoring it when using clang.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Ross Lagerwall [Wed, 24 Jan 2018 17:01:00 +0000 (18:01 +0100)]
x86/shutdown: use ACPI reboot method for Dell PowerEdge R740
When EFI booting the Dell PowerEdge R740, it consistently wanders into the
weeds and gets an invalid opcode in the EFI ResetSystem call.
Quirk this hardware to use the ACPI reboot method instead.
Jan Beulich [Wed, 24 Jan 2018 17:00:01 +0000 (18:00 +0100)]
drop "domain_" prefix from struct domain's dirty CPU mask
It being a field of struct domain is sufficient to recognize its
purpose.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@linaro.org> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Wed, 24 Jan 2018 16:59:22 +0000 (17:59 +0100)]
x86: avoid explicit TLB flush when saving exec state
Now that it's obvious that only a single dirty CPU can exist for a vCPU,
it becomes clear that flush_mask() doesn't need to be invoked when
sync_local_execstate() was already run. And with the IPI handler
clearing FLUSH_TLB from the passed flags anyway if
__sync_local_execstate() returns true, it also becomes clear that
FLUSH_TLB doesn't need to be passed here in the first place; neither of
the two places actually have a need to flush the TLB in any event (quite
possibly FLUSH_TLB was being passed there solely for flush_area_mask()
to make it past its no-op check).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 24 Jan 2018 16:58:45 +0000 (17:58 +0100)]
replace vCPU's dirty CPU mask by numeric ID
At most one bit can be set in the masks, so especially on larger systems
it's quite a bit of unnecessary memory and processing overhead to track
the information as a mask. Store the numeric ID of the respective CPU
instead, or VCPU_CPU_CLEAN if no dirty state exists.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Julien Grall <julien.grall@linaro.org>
Jan Beulich [Tue, 23 Jan 2018 09:44:11 +0000 (10:44 +0100)]
x86: make CPU state flush requests explicit
Having this be an implied side effect of a TLB flush is not very nice:
It could (at least in theory) lead to unintended state flushes (see e.g.
https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg00187.html
for context). Introduce a flag to be used in the two places actually
wanting the state flushed, and conditionalize the
__sync_local_execstate() invocation in the IPI handler accordingly.
At the same time also conditionalize the flush_area_local() invocations,
to short-circuit the function ending up as a no-op anyway.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 23 Jan 2018 09:43:39 +0000 (10:43 +0100)]
x86: move invocations of hvm_flush_guest_tlbs()
Their need is not tied to the actual flushing of TLBs, but the ticking
of the TLB clock. Make this more obvious by folding the two invocations
into a single one in pre_flush().
Also defer the latching of CR4 in write_cr3() until after pre_flush()
(and hence implicitly until after IRQs are off), making operation
sequence the same in both cases (eliminating the theoretical risk of
pre_flush() altering CR4). This then also improves register allocation,
as the compiler doesn't need to use a callee-saved register for "cr4"
anymore.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Daniel Kiper [Tue, 23 Jan 2018 09:42:10 +0000 (10:42 +0100)]
x86/setup: do not relocate Xen over current Xen image placement
Otherwise, due to Xen code/data changes under CPU feet, Xen may crash
silently at boot.
We were hit by the issue in OVS Xen 4.4 with my earlier version of
EFI/Multiboot2 patches. Initially its implementation allowed relocation
of Xen even if it was relocated by the bootloader. This led to the
crashes on some new Oracle machines because copy destination partially
overlapped with the end of current/initial Xen image placement.
After some discussion on Xen-devel we decided to disable Xen relocation in
my EFI/Multiboot2 upstream patches if the booloader did the work for us.
Though one case is still not covered. If Xen is not relocated by the
booloader then it tries to do that by itself. If all RAM regions above
currently occupied one are unsuitable for relocation then Xen tries to move
itself higher in it. And if (end - reloc_size + XEN_IMG_OFFSET) goes below
__pa(_end) then copy/relocation destination overlaps, at least partially,
with its source.
I can agree that this should not happen on todays machines very often.
If at all. It is rather unusual to not have usable RAM regions above
~5 MiB nowadays. Though I think that we should at least consider putting
such safety measure here. Otherwise Xen may crash mysteriously without
any stack trace. It is very confusing and impairs further debugging.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Julien Grall [Mon, 22 Jan 2018 14:35:42 +0000 (14:35 +0000)]
xen/arm: cpuerrata: Remove percpu.h include
The include percpu.h was added by mistake in cpuerrata.h (see commit 4c4fddc166 "xen/arm64: Add skeleton to harden the branch aliasing
attacks"). So remove it.
Wei Liu [Mon, 22 Jan 2018 16:28:30 +0000 (16:28 +0000)]
xen/shim: stash RSDP address for ACPI driver
It used to the case that we placed RSDP under 1MB and let Xen search
for it. We moved the placement to under 4GB in 4a5733771, so the
search wouldn't work.
Introduce rsdp_hint to ACPI code and set that variable in
convert_pvh_info.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
projects / people / dariof / xen.git / log