x86/paging: make log-dirty operations preemptible

Both the freeing and the inspection of the bitmap get done in (nested)
loops which - besides having a rather high iteration count in general,
albeit that would be covered by XSA-77 - have the number of non-trivial
iterations they need to perform (indirectly) controllable by both the
guest they are for and any domain controlling the guest (including the
one running qemu for it).

This is CVE-2014-5146 / XSA-97.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
xen: arm: handle AArch32 userspace when dumping 64-bit guest state.

A 64-bit guest can still be in 32-bit mode when running userspace,
handle this case by dumping the correct 32-bit state.

Note that on ARM it is not possible to change mode without the help
of the next exception level, hence there is no way a 64-bit guest can
be running in 32-bit kernel modes.

This is part of CVE-2014-5147 / XSA-102.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Correctly handle exception injection from userspace on 64-bit.

Firstly we must be prepared to propagate traps from 32-bit userspace even for
64-bit guests, so wrap the existing inject_undef??_exception into
inject_undef_exception and use that when injecting an undef exception. The
various other exception cases (aborts etc) already do this.

Secondly when injecting the trap we must pick the correct exception vector
depending on whether the source of the trap was 32-bit EL0, 64-bit EL0 or EL1.

This is part of CVE-2014-5147 / XSA-102.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Handle traps from 32-bit userspace on 64-bit kernel as undef

We are not setup to handle these properly. This turns a host crash
into a trap to the guest kernel which will likely result in killing
the offending process.

This is part of CVE-2014-5147 / XSA-102.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
xen: arm: Correctly handle do_sysreg exception injection from 64-bit userspace

The do_sysreg case was missing a return, so it would increment PC and
inject the trap to the second instruction of the handler.

This is CVE-2014-5148 / XSA-103.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Revert "x86/paging: make log-dirty operations preemptible"

This reverts commit 95e6d82224689fdfd967a093a4d69efc24c17e91.

This fix has been discovered to cause regressions.  Investigations are
ongoing.

Revert-reqeuested-by: Jan Beulich <JBeulich@suse.com>
xen/arm : emulation of arm's PSCI v0.2 standard

Arm based virtual machines dom0/guest will request power related functionality
from xen through PSCI interface. This patch implements version 0.2 of
PSCI standard specified by arm for 64bit and 32 bit arm machines.

Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- switch include n vpsci.c from asm-arm/event.h to asm/event.h ]
tools: remove duplicate -g from CFLAGS

CFLAGS+=-g is already provided by Config.mk.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools: remove duplicate -Wall from CFLAGS

CFLAGS+=-Wall is already provided by Config.mk
WARN_FLAGS is not used.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl: don't print out function name in log twice

The LOG macro already prints out function names. No need to explictly
use "__func__" in log message.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen/arm: mark do_unexpected_trap as noreturn

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools: libxc: fix Remus failover regression

commit: c2ba706c "tools/libxc: goto correct label on error paths" by Andrew
Cooper broke Remus in Xen 4.4 or earlier versions that has this commit
backported.

With Remus, this jump essentially discards the current incomplete checkpoint
received by the backup and restore backup from the last complete checkpoint.
This is required for Remus to work and this does not break live migration.  It
has been around since Xen 4.0.

CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
tools/hotplug/Linux/init.d: fix wrong path in xendomains init

Fixed wrong path in xendomains init that make it not working, introduced
in commit d8bad9df2544291a0fdc8e4d826b16f9f5394462 (tools/xendomains:
move to libexec and use a smaller init helper).

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/intel: protect set_cpuidmask() against #GP faults

Virtual environments such as Xen HVM containers and VirtualBox do not
necessarily provide support for feature masking MSRs.

As their presence is detected by model numbers alone, and their use predicated
on command line parameters, use the safe() variants of {wr,rd}msr() to avoid
dying with an early #GP fault.

While playing in this function, make some further improvements.

* Rename the masking MSR names for consistency, and name the CPU models for
  the benefit of humans reading the code.
* Correct the CPU selection as specified in the flexmigration document.  All
  steppings of 0x17 and 0x1a are stated to have masking MSRs.
* Provide log messages indicating the masks applied, or lack of masking
  capabilities.
* In the case of faulting support being available and masking command line
  options specified, provide a log message indicating the lack of masking.

References:
http://www.intel.com/content/www/us/en/virtualization/virtualization-technology-flexmigration-application-note.html
http://software.intel.com/en-us/articles/intel-architecture-and-processor-identification-with-cpuid-model-and-family-numbers

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
VMX: fix DebugCtl MSR clearing

The previous shortcut was wrong, as it bypassed the necessary vmwrite:
All we really want to avoid if the guest writes zero is to add the MSR
to the host-load list.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
VMX/vPMU: fix DebugCtl MSR handling

- writes with one of the vPMU-supported flags and some unsupported one
  set got accepted, leading to a VM entry failure
- writes with one of the vPMU-supported flags set but the Debug Store
  feature unavailable produced a #GP (other than other writes to this
  MSR with unsupported bits set)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
VMX: allow RTM advanced debugging to be used by guests

All that is needed here is allowing the respective DebugCtl MSR bit to
be set by the guest.

At once - even if PV guests can't currently use it due to missing
DebugCtl MSR virtualization - make the respective adjustments to
debugreg.h.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
VMX/vPMU: reduce core2_vpmu_initialise() verbosity

No need to print these messages for each vCPU, even more, no need to
print them for each domain - they all depend on CPU features that are
either there or not.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/irq: process softirqs in irq keyhandlers

Large machines with lots of interrupts can trip over the Xen watchdog.

Suggested-by: Santosh Jodh <Santosh.Jodh@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Santosh Jodh <Santosh.Jodh@citrix.com>
x86/alternatives: force inline stac() and clac()

In this case, we know better than the compiler.

gcc 4.7 (Debian Wheezy) chooses to create translation-unit-local functions
(even for non-debug builds) named stac() and clac(), and calls them.

$ objdump -d xen-syms | grep -c "<stac>:"
6

$ objdump -d xen-syms | grep -o "callq  [0-9a-f]\+ <stac>" | uniq -c
      5 callq  ffff82d0801166c9 <stac>
     20 callq  ffff82d08015ef99 <stac>
      4 callq  ffff82d080165169 <stac>
      8 callq  ffff82d080188cb9 <stac>
      3 callq  ffff82d080228779 <stac>
      4 callq  ffff82d08022c5c9 <stac>

Forcing always_inline removes these functions, and replaces each of the callqs
with the expected 3byte nops.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>