x86, idle: add barriers to CLFLUSH workaround

... since the documentation is explicit that CLFLUSH is only ordered
with respect to MFENCE.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: 48d32458bcd453e31b458bca868a079a6d0a38af
master date: 2014-09-09 18:09:08 +0200
VMX: don't unintentionally leave x2APIC MSR intercepts disabled

These should be re-enabled in particular when the virtualized APIC
transitions to HW-disabled state.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
master commit: 72af6f455ac6afcd46d9a556f90349f2397507e8
master date: 2014-09-16 13:58:20 +0200
x86/EFI: fix freeing of uninitialized pointer

The only valid response from the LocateHandle() call is EFI_BUFFER_TOO_SMALL,
so exit if we get anything else.  We pass a 0 size/NULL pointer buffer, so the
only other returns we will get is an error.  Return right away as there is
nothing to do.  Also return if there is an error allocating the buffer, as the
previous code path also allowed for an undefined pointer to be freed.

Signed-off-by: Roy Franz <roy.franz@linaro.org>

Re-structure the change.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: c61690fb76f9a51a8c932d76929b67bd0940febe
master date: 2014-09-24 11:09:11 +0200
x86/MSI: fix MSI-X case of freeing IRQ

Commit d1b6d0a024 ("x86: enable multi-vector MSI") went a little too
far with moving things around in msi_free_irqs() in order to streamline
the code: We shouldn't drop the MSI-X control page reference before
calling destroy_irq(), as the latter will call us back via
desc->handler->shutdown() (effectively invoking to msi_set_mask_bit()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 44d20c69516f8d5e71fc14bf216e230a9910d729
master date: 2014-10-06 11:11:28 +0200
x86: restore reserving of IO-APIC pages in XENMEM_machine_memory_map output

Commit d1222afda4 ("x86: allow Dom0 read-only access to IO-APICs") had
an unintended side effect: By no longer adding IO-APIC pages to Dom0's
iomem_caps these also no longer get reported as reserved in the machine
memory map presented to it (which got added there intentionally by
commit b8a456caed ["x86: improve reporting through
XENMEM_machine_memory_map"] because many BIOSes fail to add these).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 9d8edc5a8b4a0937193f80da72abdb44c5aeaec6
master date: 2014-10-06 11:13:19 +0200
don't allow Dom0 access to IOMMUs' MMIO pages

Just like for LAPIC, IO-APIC, MSI, and HT we shouldn't be granting Dom0
access to these. This implicitly results in these pages also getting
marked reserved in the machine memory map Dom0 uses to determine the
ranges where PCI devices can have their MMIO ranges placed.

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: fdf30377fbc4fa6798bfda7d69e5d448c2b8e834
master date: 2014-10-06 11:15:01 +0200
AMD/guest_iommu: properly disable guest iommu support

AMD Guest IOMMU support was added to allow correct use of PASID and PRI
hardware support with an ATS-aware guest driver.

However, support cannot possibly function as guest_iommu_set_base() has no
callers.  This means that its MMIO region's P2M pages are not set to
p2m_mmio_dm, preventing any invocation of the MMIO read/write handlers.

c/s fd186384 "x86/HVM: extend LAPIC shortcuts around P2M lookups" introduces a
path (via hvm_mmio_internal()) where iommu_mmio_handler claims its MMIO range,
and causes __hvm_copy() to fail with HVMCOPY_bad_gfn_to_mfn.

iommu->mmio_base defaults to 0, with a range of 8 pages, and is unilaterally
enabled in any HVM guests when the host IOMMU(s) supports any extended
features.

Unfortunately, HVMLoader's AP boot trampoline executes an `lmsw` instruction
at linear address 0x100c which unconditionally requires emulation.  The
instruction fetch in turn fails as __hvm_copy() fails with
HVMCOPY_bad_gfn_to_mfn.

The result is that multi-vcpu HVM guests do not work on newer AMD hardware, if
IOMMU support is enabled in the BIOS.

Change the default mmio_base address to ~0ULL.  This prevents
guest_iommu_mmio_range() from actually claiming any physical range
whatsoever, which allows the emulation of `lmsw` to succeed.

Reported-by: Roberto Luongo <rluongo@ready.it>
Suggested-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roberto Luongo <rluongo@ready.it>
Acked-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
master commit: 02e4c89b2cc3c1f19ef42ed4fcb1931d8d704bb5
master date: 2014-10-06 11:20:12 +0200
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).

Note that the tying of the continuations to the invoking domain (which
previously [wrongly] used the invoking vCPU instead) implies that the
tools requesting such operations have to make sure they don't issue
multiple similar operations in parallel.

Note further that this breaks supervisor-mode kernel assumptions in
hypercall_create_continuation() (where regs->eip gets rewound to the
current hypercall stub beginning), but otoh
hypercall_cancel_continuation() doesn't work in that mode either.
Perhaps time to rip out all the remains of that feature?

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

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 070493dfd2788e061b53f074b7ba97507fbcbf65
master date: 2014-10-06 11:22:04 +0200