Windows guest will notitfy GVT-g to request more resources through g2v
interface, when its resources are not enough.
This patch is to handle this case and let vgpu enter failsafe mode to
avoid too many error messages.
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Lots of reduntant log info will be printed out during GPU reset,
including accessing untracked mmio register and fence register,
variable disable_warn_untrack is added previously to handle the
situation, but the accessing of fence register is ignored in the
previously patch, so add it back.

Besides, set the variable disable_warn_untrack to the defalut value
after GPU reset is finished.
Signed-off-by: NZhao, Xinda <xinda.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

New failsafe mode is introduced, when we detect guest not supporting
GVT-g.
In failsafe mode, we will ignore all the MMIO and cfg space read/write
from guest.

This patch can fix the issue that when guest kernel or graphics driver
version is too low, there will be a lot of kernel traces in host.

V5: rebased onto latest gvt-staging
V4: changed coding style by Zhenyu and Ping's advice
V3: modified coding style and error messages according to Zhenyu's comment
V2: 1) implemented MMIO/GTT/WP pages read/write logic; 2) used a unified
function to enter failsafe mode
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

GT reset and FLR share some operations and they are both implemented in
our new function intel_gvt_reset_vgpu_locked(). This patch rewrite the
gt reset handler using this new function.

Besides, this new implementation fixed the old issue in GT reset. The
old implementation reset GGTT entries which is illegal. We only clear
GGTT entries at PCI level reset.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Move the mmio space inititation function setup_vgpu_mmio()
and cleanup function clean_vgpu_mmio() in vgpu.c to dedicated
source file mmio.c, and rename them as intel_vgpu_init_mmio()
and intel_vgpu_clean_mmio() respectively.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

All mmio handlers should return a negetive value for failure, not 1.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Return ealier for a invalid access, else it would false set
tlb flag for RCS.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The current prototype of new_mmio_info() uses void* for parameters read
and write, which are functions with precise calling conventions
(argument types and return type). Write down these conventions in
new_mmio_info() definition.

This has been reported by the following warnings when clang is used to
build the kernel:

    drivers/gpu/drm/i915/gvt/handlers.c:124:21: error: pointer type
    mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int,
    void *, unsigned int)') [-Werror,-Wpointer-type-mismatch]
            info->read = read ? read : intel_vgpu_default_mmio_read;
                              ^ ~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/i915/gvt/handlers.c:125:23: error: pointer type
    mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int,
    void *, unsigned int)') [-Werror,-Wpointer-type-mismatch]
            info->write = write ? write : intel_vgpu_default_mmio_write;
                                ^ ~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This allows the compiler to detect that sbi_ctl_mmio_write() returns a
"bool" value instead of an expected "int" one. Fix this.
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: NRobert Bragg <robert@sixbynine.org>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NSourab Gupta <sourab.gupta@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-3-robert@sixbynine.org

We no longer cater for pre-production revisions of Skylake.

Fixes: d4362225 ("drm/i915/gvt: update misc ctl regs base on stepping info")
Cc: Ping Gao <ping.a.gao@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Add more MMIO regs with command access flag for whitelist as they are
accessed by command.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Emulate right behavior for tlb_control, set to ZERO upon write.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

When SW wishes to reset the render engine, it will program
engine's reset control register and wait response from HW.
We need emulate the behavior of this register so guest i915
driver could walk through the engine reset flow. The registers
are not emulated in gvt yet, this patch add the emulation
logic.

v2: add more desc info in commit message.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NDu, Changbin <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Misc ctl related registers are for WA purpose, should detect the
stepping info first before updating HW value.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Need a explicit write_vreg in TLB MMIO write handler, beside that
TLB vreg should update correspondingly following HW status to do
correct emulation.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Missing write_vreg in DMA_CTRL write handler would make obsolete
value return when read vreg.

v2: get data from vreg after updating it.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

throw error message in elsp emulation handler basing on execlist
submit result. guest will trigger tdr process for recovering, gvt
just follow guest's desire.

v2: populate error to top of mmio emulation logic, comments from
zhenyu
Signed-off-by: NBing Niu <bing.niu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Full vGPU reset need to release all the shadow PPGGT pages to avoid
unnecessary write-protect and also should re-initialize pvinfo after
resetting vregs to keep pvinfo correct.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The current_vgpu will set to NULL after stopping the scheduler when
the reset is triggered by current vgpu, so here need change the
judgement condition for current vgpu detection.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The emulation handler for MMIO GDRST miss vreg write in it, as result
the vreg cannot update correspondingly.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Switch to use new for_each_engine() helper to properly access
enabled intel_engine_cs as i915 core has changed that to be
dynamic managed. At GVT-g init time would still depend on ring
mask to determine engine list as it's earlier.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

v2: Fix per Chris's comment
- carefully handle dev_priv->gvt assignment
- add necessary bracket for macro helper
- forward declartion struct intel_gvt
- keep free operation within same file handling alloc

v3: fix use after free and remove intel_gvt.initialized

v4: change to_gvt() to an inline
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Change GVT-g code reference for intel_engine_cs from static array to
allocated pointer after commit 3b3f1650 ("drm/i915: Allocate
intel_engine_cs structure only for the enabled engines").
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161018014007.29369-1-zhenyuw@linux.intel.com

As different VM may configure different render MMIOs when executing
workload, to schedule workloads between different VM, the render MMIOs
have to be switched.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This patch introduces a vGPU schedule policy framework, with a timer based
schedule policy module for now
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This patch introduces the vGPU workload scheduler routines.

GVT workload scheduler is responsible for picking and executing GVT workload
from current scheduled vGPU. Before the workload is submitted to host i915,
the guest execlist context will be shadowed in the host GVT shadow context.
the instructions in guest ring buffer will be copied into GVT shadow ring
buffer. Then GVT-g workload scheduler will scan the instructions in guest
ring buffer and submit it to host i915.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

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: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This patch introduces the GVT-g display virtualization.

It consists a collection of display MMIO handlers, like power well register
handler, pipe register handler, plane register handler, which will emulate
all display MMIOs behavior to support virtual mode setting sequence for
guest.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

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: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This patch introduces a framework for tracking HW registers on different
GEN platforms.

Accesses to GEN HW registers from VMs will be trapped by hypervisor. It
will forward these emulation requests to GVT-g device model, which
requires this framework to search for related register descriptions.

Each MMIO entry in this framework describes a GEN HW registers, e.g.
offset, length, whether it contains RO bits, whether it can be accessed by
LRIs...and also emulation handlers for emulating register reading and
writing.

- Use i915 MMIO register definition & statement.(Joonas)
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>