How to decide which shim to use
		   ===============================

A work-around to Meltdown (aka "SP3" or "Variant 3") on Intel
processors is to run guests in HVM or PVH mode.

NB that these approaches leave the guest vulnerable to within-guest
information leaks based on Meltdown, *even if the guest OS has
KPTI/Kaiser or a similar Meltdown migitation*.

Some guests are difficult to convert to running in HVM or PVH mode,
either due to lack of partitioning / MBR, or due to kernel
compatibilities.  As an emergency backstop, there are two approaches,
which we've codenamed "Vixen" and "Comet".  Both involve running an
embedded copy of Xen (called a "shim") within the HVM or PVH guest to
provide the native PV interface.

Below describes the properties, and who might want to use each one.

NOTE: Both shims require host patches to boot on AMD hosts.  This
shouldn't be an issue, as SP3 does not affect systems running on AMD.

Vixen
-----

Vixen has the following properties:
 * Runs the shim in an HVM guest.
 * It requires no hypervisor or toolstack changes, nor does it require
   a host reboot.
 * It has been extensively tested in Amazon's deployment for versions
   of Xen going back to 3.4
 * Guest reboots are required
 * Guest configs must be fed through a converter program
 * The converter program spits out a small guest-specific .iso
   image (we call this a "sidecar") used for booting
 * Because the result is an HVM guest, this approach involves
   running qemu as a PC emulator (this is done automatically)
 * Some common features are not supported:
  - Ballooning
  - Migration
  - vcpu hotplug
  - bidirectional console support (console is write-only)
 * Direct-boot kernels and pvgrub (both pvgrub1 and pvgrub2) are
   supported by the conversion program.  'pygrub' is not supported.
 * xl and xm domain configs can be converted; libvirt domain
   configuration arrangements are not supported.
 * Guest userspace can read all of guest memory, within each guest,
   and a guest migitation for this is not possible.

You might consider this approach if:
- You want to deploy a fix immediately
- You can tolerate the loss of within-guest security
- You can't, or would like to avoid, updating to Xen 4.8 or newer
- You'd like to avoid patching and rebooting your host
- You are able to:
 - Run a script to modify each domain config
 - Afford an extra 80MiB per guest
 - Tolerate having an extra QEMU around
- You don't need migration, memory ballooning, vcpu hotplug,
  or a bi-directional console

To use this solution, see README.vixen.

Bi-directional console is available as an extra patch, but hasn't been
widely tested:

marc.info/?i=<1515604552-9205-1-git-send-email-srn@prgmr.com>

Comet
-----

Comet has the following properties:
 * Runs the shim in a PVH guest.
 * PVH mode is available in Xen 4.10, and will be backported to Xen
   4.9 and 4.8 but no farther
 * Requires host hypervisor and toolstack patches (and host reboot),
   even for Xen 4.10
 * Requires minimal guest config changes, and no "sidecar"
 * Bootloading is identical to native PV guests; direct-boot, pvgrub,
   and pygrub all work equally well
 * Because the result is a PVH guest, this approach involves no PC emulator.
 * The following features not available in Vixen are supported:
  - Memory ballooning
  - Guest migration
  - vcpu hotplug
  - bidirectional console support
 * Guest userspace can read all of guest memory, within each guest,
   and a guest migitation for this is not possible.

You might consider this approach if:
- You're on 4.8 or later already
- You can tolerate the loss of within-guest security
- You can patch and reboot your host
- You don't want an extra QEMU around
- You need migration, memory ballooning, or vcpu hotplug, or a
  bidirectional console
- You need pygrub
- You need to use libvirt

Unfortunately this solution is not yet available.  We expect to have
it available within a few working days.