Add missing file: bootloader.mli

From xen-api c/s f45d493e7ed9b5a60fed1db64ce52708c76465a6

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-100685: When domain disappears during VM shutdown operation, just go ahead instead of rasing any cancellation error

Import xen-api c/s 96cad346b8af1c98d253ee98e180fad4e5e98768

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
CA-86568: Kill only the vncterm parent process

Do not kill the process group.

vncterm will now catch SIGTERM, pass it on to its child process,
wait for it to exit, clean up, and finally exit itself.

Signed-off-by: Miëtek Bak <mietek.bak@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-81449: Take VCPUs_at_startup into account when starting a guest.

Previously we were creating all the CPU devices as online.

n.b. adding the "online" option to Device.Vcpu.add means it's
functionally identical to Device.Vcpu.set

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CP-4145: Allow configuration of QEMU parallel port emulation

By default the toolstack does not instruct QEMU at all about parallel
port emulation. This causes QEMU to emulate a parallel port by default.
This commit allows for a "parallel" key to be specified in the platform
VM record parameter. The string used as this key will be passed to QEMU
as "-parallel <string>". For example, one can disable the parallel
port emulation completely by issuing:
xe vm-param-set uuid=<vm-uuid> platform:parallel=none

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CP-4147: Change the USB emulation platform flag semantics

Instead of having a single flag, "nousb", which turns off all USB
emulation, we now have two flags:

  - "usb", which controls USB emulation
  - "usb_tablet", which controls USB emulation, as long as USB emulation
    is turned on

xapi defaults to both keys being true, whereas xenopsd defaults to both
keys being false.

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-109035: Remove the correct xenstore key when PCI unplugging.

We were always attempting to remove dev-0 instead of dev-n. This
led to multiple attempts to e.g. deassign_device for all but the
first passed through device. It also led to a cancelled shutdown
attempting to unplug everything again without any exception handler,
leading to an infinite loop.

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
CA-105903: vbd-unplug --force works regardless of surprise-remove state

This is just acknowledging the changes that were introduced in Tampa, and not a
change in behaviour since Tampa.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Attempt to reset PCI device by writing to device reset file if present.

Signed-off-by: Siddharth Vinothkumar <siddharth.vinothkumar@citrix.com>
CA-105159: Wait for ack of shutdown request for HVM guests with PV drivers

The code paths only handled fully-PV guests and HVM guests without PV drivers.
In the case of PV drivers we did not wait for the shutdown request to be
acknowledged. This did not enable early exit if the request was not
acknowledged.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-105002: Robustify against domains that are unkillable

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-92550: Update xenstore permissions on /vm/<uuid> tree to reflect the new domain ID when a domain is rebooted or migrated to localhost

Signed-off-by: Euan Harris <euan.harris@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-113055: Take the right code path when domain is HVM.

Signed-off-by: Vincent Bernardoff <vincent.bernardoff@citrix.com>
Allow alternative implementations of the device-model and domain builder (aka xenguest)

To use an alternative device model, first put a new executable in

  /opt/xensource/alternatives/device-model/name

and then set VM.platform:device-model=name

To use an alternative xenguest, first put a new executable in

  /opt/xensource/alternatives/xenguest/name

and then set VM.platform:xenguest=name

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-88267: if a critical xenstore key is missing, the udev vif script will signal failure

Rather than ignoring keys (such as vm/uuid) which should always be
present, the udev script will log the problem and signal the error
directly to the toolstack by writing

  hotplug-error = some error string

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-85940: when "cancelling" a xenguest subprocess, raise the Cancelled exception

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Fix logic at the conclusion of Xenguest for domain creation and migration.

As part of the control protocol, Xenguest is expected to write the string

  "result: <xenstore mfn> <console mfn>\n"

to the a pipe back into xenops.  forkexecutioner has already executed a
waitpid() on the xenguest process, waiting for it to exit.

Unfortunately, as soon as xenops receives the result string, it decides to
SIGTERM the xenguest process.

This begins a race condition.  If xenguest finishes executing and exits
cleanly (which it will do, given the result string) in a timely fashion, fe
will record success and the domain creation/migration will be all good.

If however xenguest gets killed with the SIGTERM before it has exited cleanly
(such as actually having valgrind wrapped around xenguest, and the recipient
of the SIGTERM), fe will record a failure at which point xenops will clean up
the domain, despite it having actually been created/migrated successfully.

This could likely explain some spurious failures seen in high-load situation
but not reliably enough to investigate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Do not try deleting the old xenguest log file.

The only time where this will succeed is when performing localhost
migrations.  This action is a deliberate choice on behalf of the user,
suggesting that they are also likely to want the log files.

Specifically, in the case of a localhost migrate, the logs for the transmit
half of the migrate are deleted.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CA-94406: VDI reset only on epoch begin

This resolves a bug where VDIs were reset after migration, because the act of
plugging a VBD will reset the VDI. A corresponding change in the storage
managers moves the reset_leaf call (which resets VDIs) to the SR command
"vdi_epoch_begin", which was recently added to Xapi's SMAPIv2.

This commit just adds the plumbing necessary to call epoch_begin and epoch_end
on VDIs in the storage layer. The corresponding commit in sm.hg adds those
commands to the storage layer, and also moves the reset_leaf call into
vdi_epoch_begin.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Remove erroneous extra call to VDI.epoch_end

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>