drivers: hv: dxgkrnl: core code

- Add support for a Hyper-V based vGPU implementation that exposes the
  DirectX API to Linux userspace.

- Register a new device type with vmbus.

- Switch to the VM bus protocol version 40 to allow async messages.

1. PCI driver registration is added.

A PCI device is created for each virtual GPU (vGPU) device, projected by the host.
The device vendor is PCI_VENDOR_ID_MICROSOFT and device id is
PCI_DEVICE_ID_VIRTUAL_RENDER. dxg_pci_probe_device handles arrival of such devices
and it creates dxgadapter objects. The PCI config space of the vGPU device has
luid of the corresponding per GPU VM bus channel. This is how the adapters are
linked to VM bus channels.

2. dxgadapter initialization is changed to wait until VM bus channels are created.

A dxgadapter object represents a virtual GPU, projected to the VM by the
host. This object can start functioning only when the global VM bus channel
and the corresponding per vGPU VM bus channel are initialized in the guest.
Notifications about arrival of vGPU PCI device and VM bus channels can happen in
any order. Therefore, the initial dxgadapter object state is
DXGADAPTER_STATE_WAITING_VMBUS. A list of VM bus channels and a list of
dxgadapter objects are created. When dxgkrnl is notified about a VM bus channel
arrival, if tries to start all adapters, which are not started yet.

2. VM bus interface version is exchanged by reading/writing the PCI config space
of the vGPU device.

3. Implement the latest VM bus protocol version.

The protocol version 40 added a new header to VM bus messages. All VM bus
messages need to be changed to accomodate the new format.

The new protocol allows asynchronouse messages to improve performance. When
asynchronous messages are enabled, all messages need to be sent via the global
VM bus channel to preserve correct order on the host.

- Read the host virtual GPU (vGPU) luid from the PCI config space.

A virtual GPU object in the host is created for every virtual
GPU in the guest. It is identified by a luid.
When asynchronous VM bus messages are enabled, all messages are sent
via the global VM bus channel instead of a vGPU VM bus channel.
Therefore, each VM bus vGPU message needs to have a host vGPU luid to
which the message should be delivered..

- Remove the ISERROR macto.
- Add comments to struct d3dkmthandle and struct ntstatus.
- Removed the TRACE_DEBUG macro
- Removed the dxgmem_alloc layer.
- Remove dxgmutex and call Linux mutex APIs directly
- Add CONFIG_DXGKRNL_DEBUG to control adding more debug information to the driver
- Remove lock order tracking from released code
- Add more comments for NTSTATUS and D3DKMTHANDLE
- Remove unused NTSTATUS definitions
- Replace refcount_t by struct kref
- Added more comments
- Fix comments in Makefile
- Removed dxg_copy_from_user
- Removed cast to u64 when compairing winluid
- Fixed the issue where incorrect size is used to copy standard allocation private driver data to the allocation.
- Fixed re-initialization of the global VM bus channel.
- Fixed false positive in detecting memory leak for DXGMEM_VMBUS.

- Return correct total private driver size for a shared resource to the caller.

- Remove the assume_not_in_use flag when destroying allocation. Using the flag could lead to a GPU page fault.
- Fix setting the paravirtualized flag from query_adapter_info
- Call vmbus_submit_packet in a loop with delay when there is no space in the ring buffer.

- Optimize the dxgk_get_device_state implementation.

The dxgdevice execution state is cached in the guest to avoid sending a messgage
to the host for every call.. The DXGK_VMBCOMMAND_SETGUESTDATA VM bus message
is sent from the host when the device state is changed. The next call to
dxgk_get_device_state will query the state from the host.

- Fixed the issue where the hardware process fence object handle is not assigned.
   As the result, D3DKMTWaitForSynchronizationObjectFromGpu with this fence handle will fail.

- Removed timeout when waiting for internal CPU event in dxgk_wait_sync_object_cpu.
   By design, the WDDM API does not have a timeout.

- Fixed validation when creating a standard allocation.

- Coding style fixes.

- Fixed incorrect reference to system memory pointer when creating an allocations

- Increased the limit on number of allocations in MakeResident and other APIs

- Remove support for sharing of DXG objects by using global handles.

- Using the global handles is not secure. Sharing should be done using FDs (NT security sharing).

Signed-off-by: Iouri Tarassov <iourit@microsoft.com>

Author: Sasha Levin

drivers/hv/dxgkrnl/Kconfig

@@ -0,0 +1,25 @@
+#
+# dxgkrnl configuration
+#
+
+config DXGKRNL
+	tristate "Microsoft Paravirtualized GPU support"
+	depends on HYPERV
+	help
+	  This driver supports paravirtualized virtual GPU devices, exposed by
+	  Microsoft Hyper-V when Linux is running inside of a virtual machine
+	  hosted by Windows. The virtual machines needs to be configured to use
+	  host GPU adapters. The driver name is dxgkrnl.
+
+	  An example of such virtual machine is a  Windows Subsystem for
+	  Linux container. When such container is instantiated, the Windows host
+	  assigns compatible host GPU adapters to the container. The corresponding
+	  virtual GPU devices appear on the PCI bus in the container. These
+	  devices are enumerated and accessed by this driver.
+
+	  Communications with the driver are done by using the Microsoft libdxcore
+	  library, which translates the D3DKMT interface
+	  <https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/>
+	  to the driver IOCTLs. The virtual GPU devices are paravirtualized,
+	  which means that access to the hardware is done in the host. The driver
+	  communicates with the host using Hyper-V VM bus communication channels.

drivers/hv/dxgkrnl/Makefile

@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for the Linux video drivers.
+
+obj-$(CONFIG_DXGKRNL)	+= dxgkrnl.o
+dxgkrnl-y		:= dxgmodule.o hmgr.o misc.o dxgadapter.o ioctl.o dxgvmbus.o dxgprocess.o