VGPU: Fixed conflicts

Imported from xen-api.git 44c984c5dbc4dff2f806f76e362d7533b4743e35

Signed-off-by: Vincent Bernardoff <vincent.bernardoff@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Add 'vgpu' option to vga platform key

Imported from xen-api.git 92a8eec96e67664609ab1cdfdf15e7b9e7ec1ed8

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Whitespace: Neaten preliminary vGPU Xenops support

$ camlp4o /.../pa_type_conv.cma /.../pa_rpc.cma -printer \
  o -no_comments xc/xenops_server_xen.ml | md5sum
93090dee8ab20ecb035bc5ab6e1badc6  -

Imported from xen-api.git cefe0d2b435d86f4f5ec75525242bd38ff2cac86

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-5596: Move VGPU startup logic to Device module

VGPU emulator now gets started alongside Qemu since it's really part of
the emulation model.

Imported from xen-api.git 5724e8cbe8579bec8f0ce94d032637378b9f218e

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-5596: Have VM_start fail if vgpu fails to start

Factored out the code to start Qemu into a function that forks a daemon
and waits for it to finish initialising (with a write to XenStore). This
has then be reused to kick off the vgpu emulator binary which can now
fail in the same way if it doesn't initialise. vgpu is kicked off in
conjuction with Qemu since it's part of the device model.

Imported from xen-api.git 620069e60130e35eba8823c7538eb72fb3b36940

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Fix a pattern match

It's only by chance that this pattern match worked as intended.

Imported from xen-api.git e9dfc845c82e68410184e76bdd9cd89d16963623

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-5599: Allocate vGPU on VM start

Find a pGPU on which the vGPU can be allocated as part of the Vgpuops
performed by VM.start.

The strings used for the platform map have been added to
Xenops_interface to avoid transcription errors.

Imported from xen-api.git 5676980f5f75c54f5fc0f39b61445f5c8f4b689a

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Log some more information about daemons started by xenopsd

Imported from xen-api.git 5fe42e5c6026d5bf41f9fcf9a22147331a3ca85c

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-5931: Add flag to enable/disable the VNC console with vGPU

Setting VM.platform:vgpu_vnc_enabled to "true" or "false" will enable or
disable copying of the vGPU's framebuffer to the VNC console. The
setting will default to enabled if the platform key is not present.

Imported from xen-api.git aaae0111e4cc72c258e54d18616088bf5ce23d57

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-6853: Add a means of passing arbitrary arguments to vgpu

The contents of VM.platform:vgpu_extra_args (if any) will be passed to
the vgpu process (and in turn to the NVIDIA plugin).

This change also removes the vgpu_vnc_enabled key, since it can be
passed via the new mechanism (and is also mostly obsolete, since VNC
disabling is now automatic).

Imported from xen-api.git fcbbfb751493cd607d65d18018684087fd566e93

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Re-use the dev type in device.mli

Plus some minor whitespace fixes

Imported from xen-api.git b745d135abdb1f32ff160cb948e3de9ceb73344f

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-6968: Add mechanism for binding PCI devices to the NVIDIA drivers

Imported from xen-api.git f334de664254d7409f812920483d14e9a4dcd9a1

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-6968: Bind GPUs to the NVIDIA driver when required

When creating a vGPU, make sure the target physical GPU is bound to the
NVIDIA driver first.

Imported from xen-api.git c3b6069aa5c752be70b40f6261496ab7a3505504

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CP-6968: Lock NVIDIA devices before unbinding

Imported from xen-api.git 31aa6af9a9f833d86075f4f39305e823a4fc20e9

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Workaround inconsistent device naming

Imported from xen-api.git 1812a93608b9282227af862aa8bad7d8b5a279d8

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
Support both GPU PCI bus address formats

The NVIDIA procfs file currently uses the format:

xxxx:xx.xx.x

But everywhere else (lspci, sysfs, xapi/xenopsd) uses the format:

xxxx:xx:xx.x

This change means that the NVIDIA unbind code understands both
formats,
in case the procfs file changes in future to use the format used
elsewhere.

Imported from xen-api.git 2826ac93c70bdf0de600fbfd1b68325661c882e6

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CA-122661: Disable persistence mode before unbinding from nvidia

Imported from xen-api.git 2dede13790f3b27e4ca152ea0e305c8dcb8085bd

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>
CA-123007: Hold a mutex inside Device.PCI.unbind_from_nvidia

If multiple threads are trying to unbind different devices in parallel,
there is a chance that some of the nodes under /proc/driver/nvidia/ will
disappear after a thread has retrieved the list of nodes but before that
thread has accessed their contents.

Holding a mutex for the duration of the (find device,lock device,unbind)
sequence means this should no longer happen.

Imported from xen-api.git ce643b2c09116674af98ed99aa0d9c9384d3c724

Signed-off-by: John Else <john.else@citrix.com>
Imported-by: John Else <john.else@citrix.com>