x86/xsave: also save/restore XCR0 across suspend (ACPI S3)

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: e47a90e6dca491c0ceea6ffa18055e7e32565e8e
master date: 2013-10-21 17:26:16 +0200
x86: refine address validity checks before accessing page tables

In commit 40d66baa ("x86: correct LDT checks") and d06a0d71 ("x86: add
address validity check to guest_map_l1e()") I didn't really pay
attention to the fact that these checks would better be done before the
paging_mode_translate() ones, as there's also no equivalent check down
the shadow code paths involved here (at least not up to the first use
of the address), and such generic checks shouldn't really be done by
particular backend functions anyway.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 343cad8c70585c4dba8afc75e1ec1b7610605ab2
master date: 2013-10-28 12:00:36 +0100
x86/ACPI/x2APIC: guard against out of range ACPI or APIC IDs

Other than for the legacy APIC, the x2APIC MADT entries have valid
ranges possibly extending beyond what our internal arrays can handle,
and hence we need to guard ourselves against corrupting memory here.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Keir Fraser <keir@xen.org>
master commit: 2c24cdcce3269f3286790c63821951a1de93c66a
master date: 2013-11-04 10:10:04 +0100
x86: make sure memory block is RAM before passing to the allocator

Memory blocks outside of the always visible 1:1 mapping range get
passed to the allocator separately (once enough other setup was done).
Skipping non-RAM regions, however, was forgotten in adc5afbf ("x86:
support up to 16Tb").

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 227258983401b7e6091967ffaf22ad83f4ebaf6f
master date: 2013-11-04 14:29:24 +0100
x86/HVM: 32-bit IN result must be zero-extended to 64 bits

Just like for all other operations with 32-bit operand size.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>

x86/HVM: 32-bit IN result must be zero-extended to 64 bits (part 2)

Just spotted a counterpart of what commit 9d89100b (same title) dealt
with.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 9d89100ba8b7b02adb7c2e89ef7c81e734942e7c
master date: 2013-11-05 14:51:53 +0100
master commit: 1e521eddeb51a9f1bf0e4dd1d17efc873eafae41
master date: 2013-11-15 11:01:49 +0100
call sched_destroy_domain before cpupool_rm_domain

The domain destruction code, removes a domain from its cpupool
before attempting to destroy its scheduler information.  Since
the scheduler framework uses the domain's cpupool information
to decide on which scheduler ops to use, this results in the
the wrong scheduler's destroy domain function being called
when the cpupool scheduler and the initial scheduler are
different.

Correct this by destroying the domain's scheduling information
before removing it from the pool.

Signed-off-by: Nathan Studer <nate.studer@dornerworks.com>
Reviewed-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 117f67350fd18b11ab09d628b4edea3364b09441
master date: 2013-11-06 10:21:09 +0100
x86/hvm: fix restart of RTC periodic timer with vpt_align=1

The commit 58afa7ef "x86/hvm: Run the RTC periodic timer on a
consistent time series" aligns the RTC periodic timer to the VM's boot time.
However, it's aligned later again to the system time in create_periodic_time()
with vpt_align=1. The next tick might be skipped.

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 48535f5798e3e237d9920a74c1ce3802958136c0
master date: 2013-11-08 11:07:14 +0100
x86/EFI: make trampoline allocation more flexible

Certain UEFI implementations reserve all memory below 1Mb at boot time,
making it impossible to properly allocate the chunk necessary for the
trampoline. Fall back to simply grabbing a chunk from EfiBootServices*
regions immediately prior to calling ExitBootServices().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: c1f2dfe8f6a559bc28935f24e31bb33d17d9713d
master date: 2013-11-08 11:08:32 +0100
numa-sched: leave node-affinity alone if not in "auto" mode

If the domain's NUMA node-affinity is being specified by the
user/toolstack (instead of being automatically computed by Xen),
we really should stick to that. This means domain_update_node_affinity()
is wrong when it filters out some stuff from there even in "!auto"
mode.

This commit fixes that. Of course, this does not mean node-affinity
is always honoured (e.g., a vcpu won't run on a pcpu of a different
cpupool) but the necessary logic for taking into account all the
possible situations lives in the scheduler code, where it belongs.

What could happen without this change is that, under certain
circumstances, the node-affinity of a domain may change when the
user modifies the vcpu-affinity of the domain's vcpus. This, even
if probably not a real bug, is at least something the user does
not expect, so let's avoid it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 67348c3ac700b8bc9147638c719c3035c5ef20f5
master date: 2013-11-12 10:54:28 +0100
nested SVM: adjust guest handling of structure mappings

For one, nestedsvm_vmcb_map() error checking must not consist of using
assertions: Global (permanent) mappings can fail, and hence failure
needs to be dealt with properly. And non-global (transient) mappings
can't fail anyway.

And then the I/O port access bitmap handling was broken: It checked
only to first of the accessed ports rather than each of them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Christoph Egger <chegger@amazon.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: b1e87805bf37b446dade93a7eb922bb7d1269756
master date: 2013-11-12 11:51:15 +0100
VMX: don't crash processing 'd' debug key

There's a window during scheduling where "current" and the active VMCS
may disagree: The former gets set much earlier than the latter. Since
both vmx_vmcs_enter() and vmx_vmcs_exit() immediately return when the
subject vCPU is "current", accessing VMCS fields would, depending on
whether there is any currently active VMCS, either read wrong data, or
cause a crash.

Going forward we might want to consider reducing the window during
which vmx_vmcs_enter() might fail (e.g. doing a plain __vmptrld() when
v->arch.hvm_vmx.vmcs != this_cpu(current_vmcs) but arch_vmx->active_cpu
== -1), but that would add complexities (acquiring and - more
importantly - properly dropping v->arch.hvm_vmx.vmcs_lock) that don't
look worthwhile adding right now.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 58929248461ecadce13e92eb5a5d9ef718a7c88e
master date: 2013-11-12 11:52:19 +0100
x86: eliminate has_arch_mmios()

... as being generally insufficient: Either has_arch_pdevs() or
cache_flush_permitted() should be used (in particular, it is
insufficient to consider MMIO ranges alone - I/O port ranges have the
same requirements if available to a guest).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 79233938ab2a8f273fd5dcdbf8e8381b9eb3a461
master date: 2013-11-12 16:28:47 +0100
VT-d: fix TLB flushing in dma_pte_clear_one()

The third parameter of __intel_iommu_iotlb_flush() is to indicate
whether the to be flushed entry was a present one. A few lines before,
we bailed if !dma_pte_present(*pte), so there's no need to check the
flag here again - we can simply always pass TRUE here.

This is XSA-78.

Suggested-by: Cheng Yueqiang <yqcheng.2008@phdis.smu.edu.sg>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 85c72f9fe764ed96f5c149efcdd69ab7c18bfe3d
master date: 2013-11-18 13:55:55 +0100
libxl: save/restore errno in SIGCHLD handler

Without this, code interrupted by SIGCHLD may experience strange
values of errno.  (As far as I know this is not the cause of any
reported bugs.)

This fix should be backported in due course.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 704d10289bcaee46a3ef6cdc7966186e3b8033fa)
libxl: Do not generate short block in libxl__datacopier_prefixdata

libxl__datacopier_prefixdata would prepend a deliberately short block
(not just a half-full one, but one with a short buffer) to the
dc->bufs queue.  However, this is wrong because datacopier_readable
will find it and try to continue to fill it up.

Instead, allocate a full-sized buffer.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Tested-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit f6d2a87f051456bddb7a47922c8cf60f37073063)
libxl: Avoid realloc(,0) when libxl__xs_directory returns empty list

If the named path is a leaf node, libxl__xs_directory can succeed,
returning non-null, but set *nb to 0.

In three places in libxl this may result in a zero size argument being
passed to malloc() or realloc(), which is not adviseable.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 48249a140379b6a66cd32438c344a57fa21e00ed)
QEMU_TAG update
x86: restrict XEN_DOMCTL_getmemlist

Coverity ID 1055652

(See the code comment.)

This is CVE-2013-4553 / XSA-74.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 19f027cc5daff4a37fd0a28bca2514c721852dd0
master date: 2013-11-27 09:00:41 +0100
x86/HVM: only allow ring 0 guest code to make hypercalls

Anything else would allow for privilege escalation.

This is CVE-2013-4554 / XSA-76.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: 5c447caaf49192c7b2c057ffbb565ce72aac666d
master date: 2013-11-27 09:01:49 +0100
credit: Update other parameters when setting tslice_ms

Add a utility function to update the rest of the timeslice
accounting fields when updating the timeslice of the
credit scheduler, so that capped CPUs behave correctly.

Before this patch changing the timeslice to a value higher
than the default would result in a domain not utilizing
its full capacity and changing the timeslice to a value
lower than the default would result in a domain exceeding
its capacity.

Signed-off-by: Nate Studer <nate.studer@dornerworks.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
master commit: 1320b8100c2ed390fc640557a050f5c700d8338d
master date: 2013-11-15 17:38:10 +0100