GitLab

Found by smatch:

drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error: dereferencing freed memory 'pos'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

i915_gem_gtt_insert may evict some vmas and access HW if ggtt
vm space is not enough. So add mmio_hw_access_pre before invoke
i915_gem_gtt_insert to avoid call trace like below in vgpu create/
destroy test.

WARNING: CPU: 6 PID: 8720 at drivers/gpu/drm/i915/intel_drv.h:1768
assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
RPM wakelock ref not held during HW access

Call Trace:
  [<ffffffff99af3b22>] dump_stack+0x19/0x1b
  [<ffffffff9948e338>] __warn+0xd8/0x100
  [<ffffffff9948e3bf>] warn_slowpath_fmt+0x5f/0x80
  [<ffffffffc0d5cc32>] assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
  [<ffffffffc0c7ffcf>] intel_runtime_pm_get_noresume+0x6f/0x80 [i915]
  [<ffffffffc0ca614d>] i915_gem_request_alloc+0x2dd/0x3c0 [i915]
  [<ffffffffc0c9056e>] i915_gem_switch_to_kernel_context+0xae/0x1d0 [i915]
  [<ffffffffc0c91572>] ggtt_flush+0x12/0x30 [i915]
  [<ffffffffc0c917ef>] i915_gem_evict_something+0x25f/0x470 [i915]
  [<ffffffffc0c9b62c>] i915_gem_gtt_insert+0x15c/0x1c0 [i915]
  [<ffffffffc0d35837>] alloc_gm+0xa7/0x160 [i915]
  [<ffffffffc0d35d8d>] intel_vgpu_alloc_resource+0x1ad/0x410 [i915]
  [<ffffffffc0d4819c>] intel_gvt_create_vgpu+0x16c/0x260 [i915]
  [<ffffffffc055d980>] intel_vgpu_create+0x50/0x140 [kvmgt]
  [<ffffffffc04fc6fa>] mdev_device_create+0x1aa/0x2e0 [mdev]

v2: use mmio_hw_access_pre/post <Zhenyu>
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Some engines are not available for all Gens. eg, Gen11 introduced
VCS3/VCS4/VECS2, and VCS2 is not supported on some Gen9 machines. So need to
add check before access them.
Signed-off-by: Xinyun Liu <xinyun.liu@intel.com>
Signed-off-by: Yakui Zhao <Yakui.Zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Beware mixing unsigned long constants and 64b values, as on 32b the
constant will be zero extended and discard the high 32b when used as
a mask!
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108282Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025091823.20571-2-chris@chris-wilson.co.uk
(cherry picked from commit 6fc4e48f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

GVT-g only simulates DP port for guest and leaves EDP_PSR_IMR
and EDP_PSR_IIR registers as default MMIO read/write.
So guest won't get expected initial values of these registers when
initializing the gpu driver, which results in following warning and logs.

--------
Interrupt register 0x64838 is not zero: 0xffffffff
WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/i915/i915_irq.c:177
gen3_assert_iir_is_zero+0x38/0xa0

Call Trace:
gen8_de_irq_postinstall+0xa7/0x400
gen8_irq_postinstall+0x27/0x80
drm_irq_install+0xbc/0x140
i915_driver_load+0xa9d/0xd50
--------
Because GVT-g does not handle EDP(embedded DP) simulation for guests,
always set EDP_PSR_IMR and EDP_PSR_IIR to value 0.
Signed-off-by: Longhe Zheng <longhe.zheng@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

CSFE_CHICKEN1(0x20d4) needs access with mask. This is caught in AcrnGT
conformance check test:

[drm:intel_gvt_vgpu_conformance_check]
	*ERROR* gvt: vgpu1 unconformance mmio 0x20d4:0x40004,0x4
Signed-off-by: Xinyun Liu <xinyun.liu@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Previously we assumed two 4-byte writes to the same PTE coming in sequence.
But recently we observed inconsecutive partial write happening as well. So
this patch enhances the previous solution. It now uses a list to save more
partial writes. If one partial write can be combined with another one in
the list to construct a full PTE, update its shadow entry. Otherwise, save
the partial write in the list.

v2: invalidate old entry and flush ggtt (Zhenyu)
v3: split old ggtt page unmap to another patch (Zhenyu)
v4: refine codes (Zhenyu)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>
Cc: Xiaolin Zhang <xiaolin.zhang@intel.com>
Cc: Zhenyu Wang <zhenyu.z.wang@intel.com>
Reviewed-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Previously only cancelled dma map of a ggtt page when the ggtt entry was
cleared. This patch will cancel dma map of an old ggtt page as well when
the ggtt entry is updated with new page address.

Fixes: 7598e870(drm/i915/gvt: Missed to cancel dma map for ggtt entries)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

When one vgpu is destroyed, its ggtt entries are not cleared.
This patch clears ggtt entries to avoid information leak.

v2: add 'Fixes' tag (Zhenyu)

Fixes: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Fix the suspicious RCU usage issue in intel_vgpu_emulate_mmio_write.
Here need to request the srcu read lock of kvm->srcu before doing
gfn_to_memslot(). The detailed log is as below:
[  218.710688] =============================
[  218.710690] WARNING: suspicious RCU usage
[  218.710693] 4.14.15-dd+ #314 Tainted: G     U
[  218.710695] -----------------------------
[  218.710697] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage!
[  218.710699]
               other info that might help us debug this:

[  218.710702]
               rcu_scheduler_active = 2, debug_locks = 1
[  218.710704] 1 lock held by qemu-system-x86/2144:
[  218.710706]  #0:  (&gvt->lock){+.+.}, at: [<ffffffff816a1eea>] intel_vgpu_emulate_mmio_write+0x5a/0x2d0
[  218.710721]
               stack backtrace:
[  218.710724] CPU: 0 PID: 2144 Comm: qemu-system-x86 Tainted: G     U 4.14.15-dd+ #314
[  218.710727] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015
[  218.710729] Call Trace:
[  218.710734]  dump_stack+0x7c/0xb3
[  218.710739]  gfn_to_memslot+0x15f/0x170
[  218.710743]  kvm_is_visible_gfn+0xa/0x30
[  218.710746]  intel_vgpu_emulate_gtt_mmio_write+0x267/0x3c0
[  218.710751]  ? __mutex_unlock_slowpath+0x3b/0x260
[  218.710754]  intel_vgpu_emulate_mmio_write+0x182/0x2d0
[  218.710759]  intel_vgpu_rw+0xba/0x170 [kvmgt]
[  218.710763]  intel_vgpu_write+0x14d/0x1a0 [kvmgt]
[  218.710767]  __vfs_write+0x23/0x130
[  218.710770]  vfs_write+0xb0/0x1b0
[  218.710774]  SyS_pwrite64+0x73/0x90
[  218.710777]  entry_SYSCALL_64_fastpath+0x25/0x9c
[  218.710780] RIP: 0033:0x7f33e8a91da3
[  218.710783] RSP: 002b:00007f33dddc8700 EFLAGS: 00000293

v2: add 'Fixes' tag, refine log format.(Zhenyu)
Fixes: cc753fbe ("drm/i915/gvt: validate gfn before set shadow page")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Host prints lots of untracked MMIO at 0x4653c when creating linux guest.
"gvt: vgpu 2: untracked MMIO 0004653c len 4"

GEN9_CLKGATE_DIS_4 (0x4653c) is accessed by i915 for gmbus clockgating.
However vgpu doesn't support any clockgating powergating operations
on related mmio access trap so need add it to default handler.
GEN9_CLKGATE_DIS_4 is accessed in bxt_gmbus_clock_gating() which only
applies to GEN9_LP so doens't show the warning on other platforms.

The solution is to add it to default handler init_bxt_mmio_info().
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Recent patch fixed the call trace
"ERROR Port B enabled but PHY powered down? (PHY_CTL 00000000)".
but introduced another similar call trace shown as:
"ERROR Port C enabled but PHY powered down? (PHY_CTL 00000200)".
The call trace will appear when host and guest enabled different ports,
i.e. host using PORT C or neither PORT is enabled, while guest is always
using PORT B as simulated by gvt. The issue is actually covered previously
before the commit and reverals now when the commit do the right thing.

On BXT, some PHY registers are initialized by vbios, before i915 loaded.
Later i915 will re-program some, or skip some based on the implementation.
The initialized mmio for guest i915 is done by gvt, based on the snapshot
taken from host. If host and guest have different PORT enabled, some
DPIO PHY mmios that gvt initialized for guest i915 will not match the
simualted monitor for guest, which leads to guest i915 print the calltrace
when it's trying to enable PHY and PORT.

The solution is to init these DPIO PHY registers to default value, then
guest i915 will program them to reasonable value based on the default
powerwell table and enabled PORT. Together with the old patch, all similar
call trace in guest kernel on BXT can be resolved.

v2: Move PHY register init to intel_vgpu_reset_mmio (Min)
v3: Do not delete empty line in issue fix patch. (zhenyu)

Fixes: c8ab5ac3 ("drm/i915/gvt: Make correct handling to vreg
BXT_PHY_CTL_FAMILY")
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

GVT-g emualte the opregion for guest with bdb version as '186' which
child_device_config length should be '33'.

v2: split into 2 patch. 1st for issue fix, 2nd for code clean up.(Zhenyu)
v3: add fixes tag.(Zhenyu)

Fixes: 4023f301 ("drm/i915/gvt: opregion virtualization for win")
CC: Xiaolin Zhang <xiaolin.zhang@intel.com>
Reviewed-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Handle guest mm access life cycle properly with mmget()/mmput().
As noted by Linus, use_mm() depends on valid live page table but
KVM's mmgrab() doesn't guarantee that. As vGPU usage depends on
guest VM life cycle, need to make sure to use mmget()/mmput() to
guarantee VM address access.

v3: fix build

v2: v1 caused a weird dependence issue which failed for vfio
device release, which result invalid mdev vgpu and kvm state
without proper release taken. This trys to put right reference
around VM address space access instead.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

This trys to give new born vGPU with higher scheduling chance
not only with adding to sched list head and also have higher
priority for workload sched for 2 seconds after starting to
schedule it. In order for fast GPU execution during VM boot,
and ensure guest driver setup with required state given in time.

This fixes recent failure seen on one VM with multiple linux VMs
running on kernel with commit 2621cefa("drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup"),
which had shorter setup timeout that caused context state init failed.

v2: change to 2s for higher scheduling period

Cc: Yuan Hang <hang.yuan@intel.com>
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Physical plane's tiling mode value is given directly as
drm_format_mod for plane query, which is not correct fourcc
code. Fix it by using correct intel tiling fourcc mod definition.

Current qemu seems also doesn't correctly utilize drm_format_mod
for plane object setting. Anyway this is required to fix the usage.

v3: use DRM_FORMAT_MOD_LINEAR, fix comment

v2: Fix missed old 'tiled' use for stride calculation

Fixes: e546e281 ("drm/i915/gvt: Dmabuf support for GVT-g")
Cc: Tina Zhang <tina.zhang@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Colin Xu <Colin.Xu@intel.com>
Reviewed-by: Colin Xu <Colin.Xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915
device is not active. When stop vgpu schedule, the device may be
inactive. So need to move runtime_pm_get out of spin_lock/unlock.

Fixes: b24881e0("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
Cc: <stable@vger.kernel.org>
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Recent patch introduce strict check on scanning cmd:
Commit 8d458ea0 ("drm/i915/gvt: return error on cmd access")

Before 8d458ea0, if cmd_reg_handler() checks that a cmd access a mmio
that not marked as F_CMD_ACCESS, it simply returns 0 and log an error.
Now it will return -EBADRQC which will cause the workload fail to submit.

On BXT, i915 applies WaClearHIZ_WM_CHICKEN3 which will program
GEN9_WM_CHICKEN3 by LRI when init wa ctx. If it has no F_CMD_ACCESS flag,
vgpu will fail to start. Also add F_MODE_MASK since it's mode mask reg.

v2: Refresh commit message to elaborate issue symptom in detail.
v3: Make SKL_PLUS share same handling since GEN9_WM_CHICKEN3 should be
    F_CMD_ACCESS from HW aspect. (yan, zhenyu)
Signed-off-by: Colin Xu <colin.xu@intel.com>
Acked-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Guest kernel will write to BXT_PHY_CTL_FAMILY to reset DDI PHY
and pull BXT_PHY_CTL to check PHY status. Previous handling will
set/reset BXT_PHY_CTL of all PHYs at same time on receiving vreg
write to some BXT_PHY_CTL_FAMILY. If some BXT_PHY_CTL is already
enabled, following reset to another BXT_PHY_CTL_FAMILY will clear
the enabled BXT_PHY_CTL, which result in guest kernel print:

-----------------------------------
[drm:intel_ddi_get_hw_state [i915]]
*ERROR* Port B enabled but PHY powered down? (PHY_CTL 00000000)
-----------------------------------

The correct handling should operate BXT_PHY_CTL_FAMILY and
BXT_PHY_CTL on the same DDI.

v2: Use correct reg define. The naming looks confusing, however
    current i915_reg.h bind DPIO_PHY0 to _PHY_CTL_FAMILY_DDI and
    bind DPIO_PHY1 to _PHY_CTL_FAMILY_EDP, pairing to
    _BXT_PHY_CTL_DDI_A and _BXT_PHY_CTL_DDI_B respectively.
v3: v2 incorrectly map _PHY_CTL_FAMILY_EDP to _BXT_PHY_CTL_DDI_A.
    BXT_PHY_CTL() looks up DDI using PORTx but not PHYx. Based on
    DPIO_PHY to DDI mapping, make correct vreg handle to BXT_PHY_CTL
    on receiving vreg write to BXT_PHY_CTL_FAMILY. (He, Min)

Current mapping according to bxt_power_wells:
dpio-common-a:
    >>> DPIO_PHY1
    >>> BXT_DPIO_CMN_A_POWER_DOMAINS
    >>> POWER_DOMAIN_PORT_DDI_A_LANES
    >>> PORT_A

dpio-common-bc:
    >>> DPIO_PHY0
    >>> BXT_DPIO_CMN_BC_POWER_DOMAINS
    >>> POWER_DOMAIN_PORT_DDI_B_LANES | POWER_DOMAIN_PORT_DDI_C_LANES
    >>> PORT_B or PORT_C
Signed-off-by: Colin Xu <colin.xu@intel.com>
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

there is below call track at boot time when booting guest
with kabylake vgpu with specifal configuration and this try to fix it.

[drm:gen9_dbuf_enable [i915]] *ERROR* DBuf power enable timeout
------------[ cut here ]------------
WARNING: gen9_dc_off_power_well_enable+0x224/0x230 [i915]
Unexpected DBuf power power state (0x8000000a)
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
 [<ffffffff99d24408>] dump_stack+0x19/0x1b
 [<ffffffff996926d8>] __warn+0xd8/0x100
 [<ffffffff9969275f>] warn_slowpath_fmt+0x5f/0x80
 [<ffffffffc07bbae4>] gen9_dc_off_power_well_enable+0x224/0x230 [i915]
 [<ffffffffc07ba9d2>] intel_power_well_enable+0x42/0x50 [i915]
 [<ffffffffc07baa6a>] __intel_display_power_get_domain+0x8a/0xb0 [i915]
 [<ffffffffc07bdb93>] intel_display_power_get+0x33/0x50 [i915]
 [<ffffffffc07bdf95>] intel_display_set_init_power+0x45/0x50 [i915]
 [<ffffffffc07be003>] intel_power_domains_init_hw+0x63/0x8a0 [i915]
 [<ffffffffc07995c3>] i915_driver_load+0xae3/0x1760 [i915]
 [<ffffffff99bd6580>] ? nvmem_register+0x500/0x500
 [<ffffffffc07a476c>] i915_pci_probe+0x2c/0x50 [i915]
 [<ffffffff9999cfea>] local_pci_probe+0x4a/0xb0
 [<ffffffff9999e729>] pci_device_probe+0x109/0x160
 [<ffffffff99a79aa5>] driver_probe_device+0xc5/0x3e0
 [<ffffffff99a79ea3>] __driver_attach+0x93/0xa0
 [<ffffffff99a79e10>] ? __device_attach+0x50/0x50
 [<ffffffff99a77645>] bus_for_each_dev+0x75/0xc0
 [<ffffffff99a7941e>] driver_attach+0x1e/0x20
 [<ffffffff99a78ec0>] bus_add_driver+0x200/0x2d0
 [<ffffffff99a7a534>] driver_register+0x64/0xf0
 [<ffffffff9999df65>] __pci_register_driver+0xa5/0xc0
 [<ffffffffc0929000>] ? 0xffffffffc0928fff
 [<ffffffffc0929059>] i915_init+0x59/0x5c [i915]
 [<ffffffff9960210a>] do_one_initcall+0xba/0x240
 [<ffffffff9971108c>] load_module+0x272c/0x2bc0
 [<ffffffff9997b990>] ? ddebug_proc_write+0xf0/0xf0
 [<ffffffff997115e5>] SyS_init_module+0xc5/0x110
 [<ffffffff99d36795>] system_call_fastpath+0x1c/0x21
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

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

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

The 'sparse' variable may leak when return in function
intel_vgpu_ioctl(), and this patch fix this.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

The > should be >= here so that we don't read one element beyond the
end of the array.

Fixes: 28a60dee ("drm/i915/gvt: vGPU HW resource management")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]

Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

If a register is not cmd accessible, should not just print error
message. Return error here so as not to deliver this cmd.

v2: return -EBADRQC to align with return value elsewhere. (kevin tian)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Currently, the mutex used in GVT dmabuf support is not initialized until
vgpu device is opened. If one vgpu device is opened and then removed, the
mutex will be used in vgpu remove operation without initialization. This
patch initializes the mutex in vgpu create operation to avoid the problem.

Fixes: e546e281("drm/i915/gvt: Dmabuf support for GVT-g")
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Create one vGPU and then unbind IGD device from i915 driver. The following
oops will happen. This patch will free vgpu resource first and then gvt
resource to remove these oops.

BUG: unable to handle kernel NULL pointer dereference at       00000000000000a8
  PGD 80000003c9d2c067 P4D 80000003c9d2c067 PUD 3c817c067 P      MD 0
  Oops: 0002 [#1] SMP PTI
  RIP: 0010:down_write+0x1b/0x40
Call Trace:
  debugfs_remove_recursive+0x46/0x1a0
  intel_gvt_debugfs_remove_vgpu+0x15/0x30 [i915]
  intel_gvt_destroy_vgpu+0x2d/0xf0 [i915]
  intel_vgpu_remove+0x2c/0x30 [kvmgt]
  mdev_device_remove_ops+0x23/0x50 [mdev]
  mdev_device_remove+0xdb/0x190 [mdev]
  mdev_device_remove+0x190/0x190 [mdev]
  device_for_each_child+0x47/0x90
  mdev_unregister_device+0xd5/0x120 [mdev]
  intel_gvt_clean_device+0x91/0x120 [i915]
  i915_driver_unload+0x9d/0x120 [i915]
  i915_pci_remove+0x15/0x20 [i915]
  pci_device_remove+0x3b/0xc0
  device_release_driver_internal+0x157/0x230
  unbind_store+0xfc/0x150
  kernfs_fop_write+0x10f/0x180
  __vfs_write+0x36/0x180
  ? common_file_perm+0x41/0x130
  ? _cond_resched+0x16/0x40
  vfs_write+0xb3/0x1a0
  ksys_write+0x52/0xc0
  do_syscall_64+0x55/0x100
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

BUG: unable to handle kernel NULL pointer dereference at 0      000000000000038
  PGD 8000000405bce067 P4D 8000000405bce067 PUD 405bcd067 PM      D 0
  Oops: 0000 [#1] SMP PTI
  RIP: 0010:hrtimer_active+0x5/0x40
Call Trace:
  hrtimer_try_to_cancel+0x25/0x120
  ? tbs_sched_clean_vgpu+0x1f/0x50 [i915]
  hrtimer_cancel+0x15/0x20
  intel_gvt_destroy_vgpu+0x4c/0xf0 [i915]
  intel_vgpu_remove+0x2c/0x30 [kvmgt]
  mdev_device_remove_ops+0x23/0x50 [mdev]
  mdev_device_remove+0xdb/0x190 [mdev]
  ? mdev_device_remove+0x190/0x190 [mdev]
  device_for_each_child+0x47/0x90
  mdev_unregister_device+0xd5/0x120 [mdev]
  intel_gvt_clean_device+0x89/0x120 [i915]
  i915_driver_unload+0x9d/0x120 [i915]
  i915_pci_remove+0x15/0x20 [i915]
  pci_device_remove+0x3b/0xc0
  device_release_driver_internal+0x157/0x230
  unbind_store+0xfc/0x150
  kernfs_fop_write+0x10f/0x180
  __vfs_write+0x36/0x180
  ? common_file_perm+0x41/0x130
  ? _cond_resched+0x16/0x40
  vfs_write+0xb3/0x1a0
  ksys_write+0x52/0xc0
  do_syscall_64+0x55/0x100
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: bc7b0be3("drm/i915/gvt: Add basic debugfs infrastructure")
Fixes: afe04fbe("drm/i915/gvt: create an idle vGPU")
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Some workloads may be prepared in vgpu's queue but not be scheduled
to run yet. If vgpu is released at this time, they will not be freed
in workload complete callback and so need to be freed in vgpu release
operation.

Add new vgpu_release operation in gvt_ops to stop vgpu and release
runtime resources. gvt_ops vgpu_deactivate operation will only stop
vgpu.

v2: add new gvt ops to clean vgpu running status (Xiong Zhang)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.

Also clarify a bit the code comment describing the function and layout
of the control registers.

This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.

v2:
- Clarify platform range tags in code comments. (Paulo)
- Fix line over 80 chars checkpatch warning.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com

The dma_mapping_error() returns true on error but we want to return
-ENOMEM here.

Fixes: 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

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>

Caught by W=1 to fix left wrong function comment doc.
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Make kvmgt_dma_map/unmap_guest_page as static function.
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality:
commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages")

And yet, part of it was reintroduced in:
commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages")

Causing kvmgt part to no longer build. Let's remove it.
Reported-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Changbin Du <changbin.du@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com
(cherry picked from commit 4eaf317a)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

if a context is a restore inhibit context, gfx hw only load the first page
for ring context, so we only need to copy from guest the 1 page too.

v3: use "return" instead of "goto" for inhibit case. (zhenyu wang)
v2: move judgement of restore inhibit to a macro in  mmio_context.h
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Acked-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

MI_NOOP is a common command appearing in almost all command buffers, put it
into a fastpath can improve perfomance, especially in command buffers
contains lots of MI_NOOPs (0s).

Take glmark2 as an example, 3% performance increase is observed after
introduced this patch. Meanwhile, in case where abundant in MI_NOOPs,
up to 12% performance increase is measured.

v2: use lowercase for index of MI_NOOP in cmd_info (zhenyu wang)
Signed-off-by: Li Weinan <weinan.z.li@intel.com>
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality:
commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages")

And yet, part of it was reintroduced in:
commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages")

Causing kvmgt part to no longer build. Let's remove it.
Reported-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Changbin Du <changbin.du@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com

This helps initramfs builder and other tools to know the full dependencies
of i915 and have gvt module loaded with i915.

v2: add condition and change to pre-dependency (Chris)
v3: move declaration to gvt.c. (Chris)
v4: remove xengt (Zhenyu)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

BXT supports EDP. However since GVT-g only simulate DP monitor
to guest and handles EDP_PSR_IMR and EDP_PSR_IIR as default MMIO
r/w. If guest r/w these IMR/IIR, GVT-g won't simulate the real
HW behavior and below warning is printed:
--------
Interrupt register 0x64838 is not zero: 0xffffffff
WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:161
gen3_assert_iir_is_zero+0x34/0xa0

Call Trace:
gen8_de_irq_postinstall+0xad/0x330
gen8_irq_postinstall+0x23/0x80
drm_irq_install+0xb5/0x130
i915_driver_load+0xafd/0xf70
--------
Since GVT-g won't simulate EDP to guest, always set EDP_PSR_IMR
and EDP_PSR_IIR IMR/IIR to 0.
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>