x86: enforce preemption in HVM_set_mem_access / p2m_set_mem_access()

Processing up to 4G PFNs may take almost arbitrarily long, so
preemption is needed here.

This is CVE-2014-2599 / XSA-89.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 0fe53c4f279e1a8ef913e71ed000236d21ce96de
master date: 2014-03-25 15:23:57 +0100
x86: call pit_init for pvh also

During halt of a pvh guest, the guest may do speaker shutdown. This
results in call to handle_speaker_io in xen. It will hang on the vpit
spin lock because it has not been initialized.
Since, pit_init is also called for both pv and hvm, the call is
moved to a more generic place.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: c30c544b199f70eada597c7352cdcb44648f6dcd
master date: 2014-03-11 13:56:50 +0100
x86: fix pirq path for pvh

Just like hvm, pirq eoi shared page is not there for pvh. pvh should
not touch any pv_domain fields.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
master commit: bea8ee1a5ff2bbe04fcc6297db45fac178a5abc9
master date: 2014-03-13 14:24:19 +0100
x86/pvh: disallow PHYSDEVOP_pirq_eoi_gmfn_v2/v1

A call to do_physdev_op with PHYSDEVOP_pirq_eoi_gmfn_v2/v1 will corrupt
struct hvm_domain when it writes to domain->arch.pv_domain.pirq_eoi_map.
Disallow that. Currently, such a path exists for linux dom0 pvh.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
master commit: a7ca5c402e8cf61c5e8dd6e6797a627863f5a243
master date: 2014-03-24 09:47:59 +0100
common: make hypercall preemption checks consistent

- never preempt on the first iteration (ensure forward progress)
- do cheap checks first

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 8c0eed2cc8d8a2ccccdffe4c386b625b672dc12a
master date: 2014-03-13 14:26:35 +0100
x86: make hypercall preemption checks consistent

- never preempt on the first iteration (ensure forward progress)
- never preempt on the last iteration (pointless/wasteful)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: fd7bfce0395ace266159760e35dc49f7af3b90ce
master date: 2014-03-13 14:27:51 +0100
VT-d: fix RMRR handling

Removing mapped RMRR tracking structures in dma_pte_clear_one() is
wrong for two reasons: First, these regions may cover more than a
single page. And second, multiple devices (and hence multiple devices
assigned to any particular guest) may share a single RMRR (whether
assigning such devices to distinct guests is a safe thing to do is
another question).

Therefore move the removal of the tracking structures into the
counterpart function to the one doing the insertion -
intel_iommu_remove_device(), and add a reference count to the tracking
structure.

Further, for the handling of the mappings of the respective memory
regions to be correct, RMRRs must not overlap. Add a respective check
to acpi_parse_one_rmrr().

And finally, with all of this being VT-d specific, move the cleanup
of the list as well as the structure type definition where it belongs -
in VT-d specific rather than IOMMU generic code.

Note that this doesn't address yet another issue associated with RMRR
handling: The purpose of the RMRRs as well as the way the respective
IOMMU page table mappings get inserted both suggest that these regions
would need to be marked E820_RESERVED in all (HVM?) guests' memory
maps, yet nothing like this is being done in hvmloader. (For PV guests
this would also seem to be necessary, but may conflict with PV guests
possibly assuming there to be just a single E820 entry representing all
of its RAM.)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: dd527061770789d8152b1dea68056987b202d87a
master date: 2014-03-17 16:45:04 +0100
x86/Intel: work around Xeon 7400 series erratum AAI65

Linux commit 40e2d7f9b5dae048789c64672bf3027fbb663ffa ("x86 idle:
Repair large-server 50-watt idle-power regression") tells us that this
applies not just to the named Xeon 7400 series, but also NHM-EX and
WSM-EX; sadly Intel's documentation is so badly searchable that I
wasn't able to locate the respective errata (and hence can't quote
their numbers here).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
master commit: 96d1b237ae9b2f2718bb1c59820701f17d3d86e0
master date: 2014-03-17 16:47:22 +0100
x86: fix determination of bit count for struct domain allocations

We can't just add in the hole shift value, as the hole may be at or
above the 44-bit boundary. Instead we need to determine the total bit
count until reaching 32 significant (not squashed out) bits in PFN
representations.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: b3d2f8b2cba9fce5bc8995612d0d13fcefec7769
master date: 2014-03-24 10:48:03 +0100
x86/HVM: correct CPUID leaf 80000008 handling

CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].

Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.

In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.

This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: ef437690af8b75e6758dce77af75a22b63982883
master date: 2014-03-28 13:33:34 +0100
x86/EPT: relax treatment of APIC MFN

There's no point in this being mapped UC by the guest due to using a
respective PAT index - set the ignore-PAT flag to true.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 1f8b57779785bf9f55c16312bb1ec679929c314b
master date: 2014-03-28 13:43:25 +0100
kexec: propagate ENOMEM result in error handling

...otherwise if kimage_alloc_control_page fails (presumably due to
out-of-memory; see the invocation just before this one), the caller of
do_kimage_alloc will think the call was successful.

Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
master commit: 66c6349265d6536d0b77cd958ee3e5074e86233a
master date: 2014-04-01 16:48:02 +0200
VMX: fix PAT value seen by guest

The XSA-60 fixes introduced a window during which the guest PAT gets
forced to all zeros. This shouldn't be visible to the guest. Therefore
we need to intercept PAT MSR accesses during that time period.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
master commit: fce79f8ce91dc45f3a4d699ee67c49e6cbeb1197
master date: 2014-04-01 16:49:18 +0200
libxl: Hold the atfork lock while closing carefd

This avoids the process being forked while a carefd is recorded in the
list but the actual fd has been closed.  If that happened, a
subsequent libxl_postfork_child_noexec would attempt to close the fd
again.  If we are lucky that results in a harmless warning; but if we
are unlucky the fd number has been reused and we close an unrelated
fd.

This race has not been observed anywhere as far as we are aware.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
(cherry picked from commit 2a0c3a62ea4ad6c6bcbf80122b070f3ff3fe7dae)
libxl: Fix carefd lock leak in save callout

If libxl_pipe fails we leave the carefd locked, which translates to
the atfork lock remaining held.  This would probably cause the process
to deadlock shortly afterwards.

Of course libxl_pipe is very unlikely to fail unless things are
already going very badly.  This bug has not been observed anywhere as
far as we are aware.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
(cherry picked from commit 7eb73add5de5839f160b902dd894d3aecc10ba0c)
tools: update config.{sub,guess}

Update to versions from Debian Wheezy's autotools-dev package (20120608.1)

Adds ARM aarch64 support.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 0c68ddf3085b90d72b7d3b6affd1fe8fa16eb6be)
libxl: arm: do not create /chosen/bootargs in DTB if no cmdline is specified

Otherwise we deference a NULL pointer.

I saw this while experimenting with libvirt on Xen on ARM, xl already checks
that the command line is non NULL and provides "" as a default.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: george.dunlap@citrix.com>
(cherry picked from commit 3647a486ec05b1e01930ff299b18fc2b632e2cb0)
xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry

menuentry in grub2/grub.cfg uses linux16 and initrd16 commands
instead of linux and initrd. Due to this RHEL 7 (beta) guest failed to
boot after the installation.

In addition to this, RHEL 7 menu entries have two different single-quote
delimited strings on the same line, and the greedy grouping for menuentry
parsing gets both strings, and the options inbetween.

Signed-off-by: Joby Poriyath <joby.poriyath@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: george.dunlap@citrix.com
(cherry picked from commit dd03048708af072374963d6d0721cc6d4c5f52cf)
PV-GRUB: fix blk access at end of disk

GRUB usually always loads a whole disk track, even if that means going
beyond the end of the disk.  We thus have to gracefully return an error,
instead of letting the blkfront go panic.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 51e18e41e39a682de5a2e60ad86048dc6344efec)