Commit Graph

12 Commits

Author SHA1 Message Date
Joonas Lahtinen
5781cf8255 Merge tag 'gvt-next-2018-09-04' of https://github.com/intel/gvt-linux into drm-intel-next-queued
gvt-next-2018-09-04

- guest context shadow optimization for restore inhibit one (Yan)
- cmd parser optimization (Yan)
- W=1 warning fixes (Zhenyu)

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

# Conflicts:
#	drivers/gpu/drm/i915/gvt/reg.h
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180904030154.GG20737@zhen-hp.sh.intel.com
2018-09-06 16:51:50 +03:00
Lucas De Marchi
336662e5e3 drm/i915/gvt: use its own define for gpio
The definition on i915_reg.h is going to change to depend on
dev_priv->gpio_mmio_base being properly initialized. Define our own
macros since init_generic_mmio_info() is called before than
gpio_mmio_base being set.

Cc: intel-gvt-dev@lists.freedesktop.org
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-2-lucas.demarchi@intel.com
2018-08-16 11:52:06 -07:00
Lucas De Marchi
f5133cca38 drm/i915: make PCH_GMBUS* definitions private to gvt
This is the only place that they are being used - the others use the
GMBUS* macros that rely on dev_priv being already properly initialized.

Cc: intel-gvt-dev@lists.freedesktop.org
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180727193647.8639-1-lucas.demarchi@intel.com
2018-08-16 11:52:05 -07:00
Zhenyu Wang
69ca5af4ff drm/i915/gvt: Move some MMIO definitions to reg.h
To consolidate all gvt private MMIO definition in one place,
this moves some not yet used in i915 to reg.h.

Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-08-07 10:40:11 +08:00
Zhi Wang
9556e11888 drm/i915/gvt: Use I915_GTT_PAGE_SIZE
As there is already an I915_GTT_PAGE_SIZE marco in i915, let GVT-g use it
as well. Also this patch re-names some GTT marcos with additional prefix.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
2017-11-16 11:48:22 +08:00
Xiaolin Zhang
a58c38aa6c drm/i915/gvt: Add support for opregion virtualization
opregion emulated with a copy from host which leads to some display
bugs such as guest resolution adjustment failure due to host opregion
fail to claim port D support. with a fake opregion table provided
to fully emulate opregion to meet guest port requirement.

v1 - initial patch
v2 - reforamt opregion arrary with 0x02x output
v3 - opregion array removed with opregion generation on host initizaiton
v4 - rebased v3 patch from stable branch to staging branch which also has
     different struct child_device_config and addressed v3 review comments.

Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-11-16 11:46:07 +08:00
Zhi Wang
edee7ecdb4 drm/i915/gvt: Refine MMIO_RING_F()
Inspect if the host has VCS2 ring by host i915 macro in MMIO_RING_F().
Also this helps on reducing some LOCs.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
2017-10-27 01:38:56 +08:00
Jike Song
03551e971f drm/i915/gvt: cleanup opregion memory allocation code
According to the spec, ACPI OpRegion must be placed at a physical address
below 4G. That is, for a vGPU it must be associated with a GPA below 4G,
but on host side, it doesn't matter where the backing pages actually are.
So when allocating pages from host, the GFP_DMA32 flag is unnecessary.

Also the allocation is from a sleepable context, so GFP_ATOMIC is also
unnecessary.

This patch also removes INTEL_GVT_OPREGION_PORDER and use get_order()
instead.

Signed-off-by: Jike Song <jike.song@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-01-09 11:11:32 +08:00
Zhi Wang
28c4c6ca7f drm/i915/gvt: vGPU workload submission
This patch introduces the vGPU workload submission logics.

Under virtualization environment, guest will submit workload through
virtual execlist submit port. The submitted workload load will be wrapped
into an gvt workload which will be picked by GVT workload scheduler and
executed on host i915 later.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-14 18:14:37 +08:00
Zhi Wang
e39c5add32 drm/i915/gvt: vGPU MMIO virtualization
This patch introduces the generic vGPU MMIO emulation intercept
framework.  The MPT modules will request GVT-g core logic to
emulate MMIO read/write through IO emulation operations
callback when hypervisor trapped a guest GTTMMIO read/write.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-14 18:12:59 +08:00
Zhi Wang
4d60c5fd3f drm/i915/gvt: vGPU PCI configuration space virtualization
This patch introduces vGPU PCI configuration space virtualization.

- Adjust the trapped GPFN(Guest Page Frame Number) window of virtual GEN
PCI BAR 0 when guest initializes PCI BAR 0 address.

- Emulate OpRegion when guest touches OpRegion.

- Pass-through a part of aperture to guest when guest initializes
aperture BAR.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-14 18:12:46 +08:00
Zhi Wang
82d375d1b5 drm/i915/gvt: Introduce basic vGPU life cycle management
A vGPU represents a virtual Intel GEN hardware, which consists following
virtual resources:

- Configuration space (virtualized)
- HW registers (virtualized)
- GGTT memory space (partitioned)
- GPU page table (shadowed)
- Fence registers (partitioned)

* virtualized: fully emulated by GVT-g.
* partitioned: Only a part of the HW resource is allowed to be accessed
by VM.
* shadowed: Resource needs to be translated and shadowed before getting
applied into HW.

This patch introduces vGPU life cycle management framework, which is
responsible for creating/destroying a vGPU and preparing/free resources
related to a vGPU.

Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2016-10-14 18:11:59 +08:00