docs: Give advice on dealing with quoting special characters

The man page mentions passing config snippets key=val in xl create.
Unfortunately, the config syntax contain characters which are
interpreted (and often discarded) by the shell before getting passed
in, resulting in a parsing error.

For example:

xl create hvm.cfg cpus="0-3"

The shell will eat the quotes and pass 'cpus=0-3' to xl, which won't
parse properly without the quotes.

Mention this in the man page, and recommend the use of single quotes, as well
as separating multiple arguments with a semicolon, thus:

xl create hvm.cfg 'cpus="0-3"; pci=["1.0","1.1"]'

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
docs: Mention the semicolon as a valid statement end

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
x86/EPT: fix super page splitting when resolving EPT_MISCONFIG VM exits

Reported-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
vtpmmgr: fix 32-bit compilation

The internal MPI word size matches the word size of the platform rather
than using uint32_t/uint64_t, so constant MPI objects need to be
initialized with that in mind.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/P2M: simplify write_p2m_entry()

The "table_mfn" parameter really isn't needed anywhere, so it gets
dropped.

The "struct vcpu *" one was always bogus (as was being made up by
paging_write_p2m_entry()), and is not commonly used. It can be easily
enough made up in the one place (sh_unshadow_for_p2m_change()) it is
needed, and we can otherwise pass "struct domain *" instead, properly
reflecting that P2M operations are per-domain.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/P2M: cleanup

- don't abuse __PAGE_HYPERVISOR
- don't use bogus constructs like mfn_x(_mfn())

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper<andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
VT-d: suppress UR signaling for server chipsets

Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the server chipsets dealt with here.

IDs 0xe00, 0xe01, and 0xe04 ... 0xe0b (Ivytown) aren't needed here -
Intel confirmed the issue to be fixed in hardware there.

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
VT-d: suppress UR signaling for desktop chipsets

Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the desktop chipsets dealt with here.

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
passthrough: allow to suppress SERR and PERR signaling altogether

This is just to have a workaround at hand in case other chipsets (not
covered by the previous two patches) also have similar issues.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
x86/HVM: replace open-coded non-local cache flushing

We accumulated quite a number of these, despite having a pre-canned
interface for it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
x86/boot: remove high_start and ret_point

They are not needed.  This form is a few bytes leaner overall, but
usefully removes pieces of data from the middle of the code section.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/HVM: correct the SMEP logic for HVM_CR0_GUEST_RESERVED_BITS

When checking the SMEP feature for HVM guests, we should check the
VCPU instead of the host CPU.

Signed-off-by: Feng Wu <feng.wu@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/HVM: restrict HVMOP_set_mem_type

Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.

Along with that drop a bogus (and otherwise becoming stale) log
message.

Afaict the similar operation in p2m_set_mem_access() is safe.

This is XSA-92.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/boot: early data should live in init.rodata

No real change as these were already in the init section, but does move it out
of a text section.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: move some __high_start code and data into init sections

Half of __high_start is strictly for the BSP and will only be run once on
boot.  To complement 'start_secondary', create 'start_bsp' and move it into
the init.text section.

The interrupt handler 'ignore_int' is patched into the BSPs IDT, but fully
replaced with real handlers early during boot.  The BSPs IDT is used by APs
until midway through start_secondary, but after the real handlers have been
installed.  Therefore, 'ignore_int' can move to init.text.  Furthermore, its
strings can move to init.rodata.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: use 'hlt' inside terminal loops

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/mem: introduce XENMEM_machphys_compat_mfn_list

To correctly migrate a PV guest, the toolstack must remove Xen mappings from
the guest pagetables.  For 32bit PV guests, the pagetables cannot be walked
from the top so upon encountering an L2 table, the toolstack must decide
whether it contains Xen mappings or not, to avoid corrupting L2s without Xen
mappings.

The migration code performs this search efficiently by knowing that the Xen
mappings will start at a known L2e and point to a known mfn, which will be the
first mfn in the m2p table.

Unfortunately there are two m2p tables in use; the regular and the
compatibility one.  The toolstack looks for the first mfn of its own m2p table
in the guest pagetables.  This only works if the toolstack is the same bitness
as the 32bit domain being migrated, and leaves a problem for 64bit toolstacks
which will never be able to find its regular m2p in a compat guest.

It appears that this bug for 64bit toolstacks was discovered, but hacked
around in an unsafe manner.  The code currently shoots any invalid L2es and
doesn't report a failure for L2 tables in a 32 bit guest, even after the guest
is paused.  This means that non Xen entries which should fail the migration
don't, and the guest will resume on the far side with unexpectedly fewer
present pagetable entries.

This patch introduces XENMEM_machphys_compat_mfn_list which permits a 64bit
toolstack to access the compat m2p mfn list, for the purpose of correctly
identifying Xen entries in a 32bit guest.

It is worth noting for completeness that 64bit PV guests don't have any of
these games to play.  The Xen mappings are present at a known location in all
L4 tables, so can be safely shot by 32 and 64bit toolstacks without looking at
where the mapping points to.

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