libxl: Fix libxl_postfork_child_noexec deadlock etc.

libxl_postfork_child_noexec would nestedly reaquire the non-recursive
"no_forking" mutex: atfork_lock uses it, as does sigchld_user_remove.
The result on Linux is that the process always deadlocks before
returning from this function.

This is used by xl's console child.  So, the ultimate effect is that
xl with pygrub does not manage to connect to the pygrub console.
This behaviour was reported by Michael Young in Xen 4.4.0 RC5.

Also, the use of sigchld_user_remove in libxl_postfork_child_noexec is
not correct with SIGCHLD sharing.  libxl_postfork_child_noexec is
documented to suffice if called only on one ctx.  So deregistering the
ctx it's called on is not sufficient.  Instead, we need a new approach
which discards the whole sigchld_user list and unconditionally removes
our SIGCHLD handler if we had one.

Prompted by this, clarify the semantics of
libxl_postfork_child_noexec.  Specifically, expand on the meaning of
"quickly" by explaining what operations are not permitted; and
document the fact that the function doesn't reclaim the resources in
the ctxs.

And add a comment in libxl_postfork_child_noexec explaining the
internal concurrency situation.

This is an important bugfix.  IMO the bug is a blocker for Xen 4.4.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: M A Young <m.a.young@durham.ac.uk>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Config.mk: update QEMU_TAG and QEMU_UPSTREAM_REVISION

Update these to the -rc6 tags.  These refer to the same commits as the
previously-referenced tags.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
README, xen/Makefile: Change in-tree version numbers

Change these to 4.4.0 in preparation for the release.  (We can still
make a change to the released codebase if something turns up between
now and the actual release.)

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Config.mk: update QEMU_TAG and QEMU_UPSTREAM_REVISION

Update these to the Xen 4.4.0 tags.  These refer to the same commits
as the previously-referenced tags.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
4.4 release: Update README

Update paragraph bragging about the features.  Also, remove the ".0"
from the end of the banner, so we don't have to keep updating it every
point release.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Config.mk: switch QEMU_UPSTREAM_REVISION back to master

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
update Xen version to 4.4.1-pre

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
update MAINTAINERS for stable branch
x86/MCE: Fix race condition in mctelem_reserve

These lines (in mctelem_reserve)

        newhead = oldhead->mcte_next;
        if (cmpxchgptr(freelp, oldhead, newhead) == oldhead) {

are racy. After you read the newhead pointer it can happen that another
flow (thread or recursive invocation) change all the list but set head
with same value. So oldhead is the same as *freelp but you are setting
a new head that could point to whatever element (even already used).

This patch use instead a bit array and atomic bit operations.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
master commit: 60ea3a3ac3d2bcd8e85b250fdbfc46b3b9dc7085
master date: 2014-02-24 12:07:41 +0100
Nested VMX: update nested paging mode on vmexit

Since SVM and VMX use different mechanism to emulate the virtual-vmentry
and virtual-vmexit, it's hard to update the nested paging mode correctly in
common code. So we need to update the nested paging mode in their respective
code path.
SVM already updates the nested paging mode on vmexit. This patch adds the same
logic in VMX side.

Previous discussion is here:
http://lists.xen.org/archives/html/xen-devel/2013-12/msg01759.html

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Reviewed-by: Christoph Egger <chegger@amazon.de>
master commit: fd1864f48d8914fb8eeb6841cd08c2c09b368909
master date: 2014-02-24 12:09:52 +0100
x86/MSI: don't risk division by zero

The check in question is redundant with the one in the immediately
following if(), where dividing by zero gets carefully avoided.

Spotted-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
master commit: 5d160d913e03b581bdddde73535c18ac670cf0a9
master date: 2014-02-24 12:11:01 +0100
x86/mce: Reduce boot-time logspam

When booting with "no-mce", the user does not need to be told that "MCE
support [was] disabled by bootparam" for each cpu.  Furthermore, a file:line
reference is unnecessary.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a5ab9c9fa29cda7e1b18dbcaa69a5dbded96de32
master date: 2014-02-25 09:30:59 +0100
IOMMU: generalize and correct softirq processing during Dom0 device setup

c/s 21039:95f5a4ce8f24 ("VT-d: reduce default verbosity") having put a
call to process_pending_softirqs() in VT-d's domain_context_mapping()
was wrong in two ways: For one we shouldn't be doing this when setting
up a device during DomU assignment. And then - I didn't check whether
that was the case already back then - we shouldn't call that function
with the pcidevs_lock (or in fact any spin lock) held.

Move the "preemption" into generic code, at once dealing with further
actual (too much output elsewhere - particularly on systems with very
many host bridge like devices - having been observed to still cause the
watchdog to trigger when enabled) and potential (other IOMMU code may
also end up being too verbose) issues.

Do the "preemption" once per device actually being set up when in
verbose mode, and once per bus otherwise.

Note that dropping pcidevs_lock around the process_pending_softirqs()
invocation is specifically not a problem here: We're in an __init
function and aren't racing with potential additions/removals of PCI
devices. Not acquiring the lock in setup_dom0_pci_devices() otoh is not
an option, as there are too many places that assert the lock being
held.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: 9ef5aa944a6a0df7f5938983043c7e46f158bbc6
master date: 2014-03-04 10:52:20 +0100
x86/hvm: refine the judgment on IDENT_PT for EMT

When trying to get the EPT EMT type, the judgment on
HVM_PARAM_IDENT_PT is not correct which always returns WB type if
the parameter is not set. Remove the related code.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>

We can't fully drop the dependency yet, but we should certainly avoid
overriding cases already properly handled. The reason for this is that
the guest setting up its MTRRs happens _after_ the EPT tables got
already constructed, and no code is in place to propagate this to the
EPT code. Without this check we're forcing the guest to run with all of
its memory uncachable until something happens to re-write every single
EPT entry. But of course this has to be just a temporary solution.

In the same spirit we should defer the "very early" (when the guest is
still being constructed and has no vCPU yet) override to the last
possible point.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: cadfd7bca999c0a795dc27be72d43c92e8943a0b
master date: 2014-03-10 11:02:25 +0100
x86/HVM: fix memory type merging in epte_get_entry_emt()

Using the minimum numeric value of guest and host specified memory
types is too simplistic - it works only correctly for a subset of
types. It is in particular the WT/WP combination that needs conversion
to UC if the two types conflict.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: b99113b9d5fac5149de8496f55afa00e285b1ff3
master date: 2014-03-10 11:03:53 +0100
x86/HVM: consolidate passthrough handling in epte_get_entry_emt()

It is inconsistent to depend on iommu_enabled alone: For a guest
without devices passed through to it, it is of no concern whether the
IOMMU is enabled.

There's one rather special case to take care of: VMX code marks the
LAPIC access page as MMIO. The added assertion needs to take this into
consideration, and the subsequent handling of the direct MMIO case was
inconsistent too: That page would have been WB in the absence of an
IOMMU, but UC in the presence of it, while in fact the cachabilty of
this page is entirely unrelated to an IOMMU being in use.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 3089a6d82bdf3112ccb1dd074ce34a8cbdc4ccd8
master date: 2014-03-10 11:04:36 +0100
kexec: identify which cpu the kexec image is being executed on

A patch to this effect has been in XenServer for a little while, and has
proved to be a useful debugging point for servers which have different
behaviours depending when crashing on the non-bootstrap processor.

Moving the printk() from kexec_panic() to one_cpu_only() means that it will
only be printed for the cpu which wins the race along the kexec path.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
master commit: 4509ada6ba1f09cc8f4fa23e009e7e5a963b6086
master date: 2014-03-10 11:11:28 +0100
xmalloc: handle correctly page allocation when align > size

When align is superior to size, we need to retrieve the order from
align during multiple page allocation. I guess it was the goal of the commit
fb034f42 "xmalloc: make close-to-PAGE_SIZE allocations more efficient".

Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: ac2cba2901779f66bbfab298faa15c956e91393a
master date: 2014-03-10 14:40:50 +0100
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