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: NLonghe Zheng <longhe.zheng@intel.com>
Signed-off-by: NZhenyu 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: NXinyun Liu <xinyun.liu@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu 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: NHang 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: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NZhenyu 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: NZhipeng Gong <zhipeng.gong@intel.com>
Reviewed-by: NHang Yuan <hang.yuan@intel.com>
Signed-off-by: NZhenyu 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: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu 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: NHe, Min <min.he@intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu 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: NHe, Min <min.he@intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu 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: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu 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: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@intel.com>
Signed-off-by: NZhenyu 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: NColin Xu <Colin.Xu@intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu 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: NColin Xu <colin.xu@intel.com>
Acked-by: NZhao Yan <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu 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: NColin Xu <colin.xu@intel.com>
Reviewed-by: NHe, Min <min.he@intel.com>
Signed-off-by: NZhenyu 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: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

If the display has been disabled by modparam, we still want to connect
together the HW bits and bobs with the associated drivers so that we can
continue to manage their runtime power gating.

Fixes: 10810944 ("drm/i915: Check num_pipes before initializing audio component")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Elaine Wang <elaine.wang@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817100241.4628-1-chris@chris-wilson.co.uk
(cherry picked from commit 35a5fd9ebfa93758ca579e30f337b6c9126d995b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at boot or screen reconfiguration.
Empirical testing can reproduce the error up to a timeout of 190 ms. Basic
boot and stress testing at 200 ms has not (yet) failed.

Increase timeout to 400 ms to get some margin of error.

Changes from v1:
The initial suggestion of 1000 ms was lowered due to concerns about delaying
valid timeout cases.
Update patch metadata.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Fixes: 357c0ae9 ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v4.11+
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NFredrik Schön <fredrik.schon@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com
(cherry picked from commit 59f1c8ab30d6f9042562949f42cbd3f3cf69de94)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The context owns both the ppgtt and the vma within it, and our activity
tracking on the context ensures that we do not release active ppgtt. As
the context fulfils our obligations for active memory tracking, we can
relinquish the reference from the vma.

This fixes a silly transient refleak from closed vma being kept alive
until the entire system was idle, keeping all vm alive as well.
Reported-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/gem_ctx_create/files
Fixes: 3365e226 ("drm/i915: Lazily unbind vma on close")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816073448.19396-1-chris@chris-wilson.co.uk
(cherry picked from commit a4417b7b419a68540ad7945ac4efbb39d19afa63)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We use kzalloc to allocate the write_buf that we use for
i2c transfer on hdcp write. But it seems that we are forgetting
to free the memory that is not needed after i2c transfer is
completed.
Reported-by: NBrian J Wood <brian.j.wood@intel.com>
Fixes: 2320175f ("drm/i915: Implement HDCP for HDMI")
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180823205136.31310-1-rodrigo.vivi@intel.com
(cherry picked from commit 62d3a8de)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The workaround was supposed to look at the plane destination
coordinates. Currently it's looking at some mixture of src
and dst coordinates that doesn't make sense. Fix it up.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719182214.4323-2-ville.syrjala@linux.intel.com
Fixes: 394676f0 (drm/i915: Add WA for planes ending close to left screen edge)
Reviewed-by: NImre Deak <imre.deak@intel.com>
(cherry picked from commit b1f1c2c1)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Commit cafa0010 ("Raise the minimum required gcc version to 4.6")
recently exposed a brittle part of the build for supporting non-gcc
compilers.

Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and
__GNUC_PATCHLEVEL__ for quick compatibility with code bases that haven't
added compiler specific checks for __clang__ or __INTEL_COMPILER.

This is brittle, as they happened to get compatibility by posing as a
certain version of GCC.  This broke when upgrading the minimal version
of GCC required to build the kernel, to a version above what ICC and
Clang claim to be.

Rather than always including compiler-gcc.h then undefining or
redefining macros in compiler-intel.h or compiler-clang.h, let's
separate out the compiler specific macro definitions into mutually
exclusive headers, do more proper compiler detection, and keep shared
definitions in compiler_types.h.

Fixes: cafa0010 ("Raise the minimum required gcc version to 4.6")
Reported-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: NEli Friedman <efriedma@codeaurora.org>
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.

Currently we simply back off and mark an oom victim with blockable mmu
notifiers as done after a short sleep.  That can result in selecting a new
oom victim prematurely because the previous one still hasn't torn its
memory down yet.

We can do much better though.  Even if mmu notifiers use sleepable locks
there is no reason to automatically assume those locks are held.  Moreover
majority of notifiers only care about a portion of the address space and
there is absolutely zero reason to fail when we are unmapping an unrelated
range.  Many notifiers do really block and wait for HW which is harder to
handle and we have to bail out though.

This patch handles the low hanging fruit.
__mmu_notifier_invalidate_range_start gets a blockable flag and callbacks
are not allowed to sleep if the flag is set to false.  This is achieved by
using trylock instead of the sleepable lock for most callbacks and
continue as long as we do not block down the call chain.

I think we can improve that even further because there is a common pattern
to do a range lookup first and then do something about that.  The first
part can be done without a sleeping lock in most cases AFAICS.

The oom_reaper end then simply retries if there is at least one notifier
which couldn't make any progress in !blockable mode.  A retry loop is
already implemented to wait for the mmap_sem and this is basically the
same thing.

The simplest way for driver developers to test this code path is to wrap
userspace code which uses these notifiers into a memcg and set the hard
limit to hit the oom.  This can be done e.g.  after the test faults in all
the mmu notifier managed memory and set the hard limit to something really
small.  Then we are looking for a proper process tear down.

[akpm@linux-foundation.org: coding style fixes]
[akpm@linux-foundation.org: minor code simplification]
Link: http://lkml.kernel.org/r/20180716115058.5559-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Acked-by: Christian König <christian.koenig@amd.com> # AMD notifiers
Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx and umem_odp
Reported-by: NDavid Rientjes <rientjes@google.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.

Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae84799 ("drm/i915: add
intel_ddi_set_pipe_settings").

Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.

Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.

After all these years, the fix boils down to flipping one bit.

[Per testing reports, this fixes DP sinks, but not the LSPCON. My
 educated guess is that the LSPCON fails to turn the CEA range MSA into
 AVI infoframes for HDMI.]
Reported-by: NMichał Kopeć <mkopec12@gmail.com>
Reported-by: NN. W. <nw9165-3201@yahoo.com>
Reported-by: NNicholas Stommel <nicholas.stommel@gmail.com>
Reported-by: NTom Yan <tom.ty89@gmail.com>
Tested-by: NNicholas Stommel <nicholas.stommel@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.9+
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
(cherry picked from commit dc5977da)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The call to i915_gem_unpark() checks that we hold a rpm wakeref before
taking a long term wakeref for i915->gt.awake. We should therefore make
sure we do hold the wakeref when directly calling unpark to disable
the retire worker.

Fixes: 932cac10 ("drm/i915/selftests: Prevent background reaping of active objects")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180809063449.4474-1-chris@chris-wilson.co.uk
(cherry picked from commit 7b5ee80a)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon resume or else our accounting will be
off and we may not acquire the forcewake before we use it. So record
which domains we cleared on suspend and reacquire them early on resume.

v2: Hold the spinlock to appease our sanitychecks
v3: s/fw_domains_user/fw_domains_saved/ to convey intent more clearly
Reported-by: NImre Deak <imre.deak@linux.intel.com>
Fixes: b8473050 ("drm/i915: Fix forcewake active domain tracking")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808210842.3555-1-chris@chris-wilson.co.uk
(cherry picked from commit d60996ab430c8a6033a0944c068edc5ec5becb9b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

An oddity occurs on Sandybridge, Ivybridge and Haswell (and presumably
Valleyview) in that for the period following the GPU restart after a
reset, there are no GT interrupts received. From Ville's notes, bit 0 in
the HWSTAM corresponds to the render interrupt, and if we unmask it we
do see immediate resumption of GT interrupt delivery (via the master irq
handler) after the reset.

v2: Limit the w/a to the render interrupt from rcs

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107500
Fixes: c5498089 ("drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode")
References: d420a50c ("drm/i915: Clean up the HWSTAM mess")
Testcase: igt/gem_eio/reset-stress
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180808105101.913-2-chris@chris-wilson.co.uk
(cherry picked from commit a4a717010f4e8cacaa3f0cae8a22f25c39ae1d41)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The 'sparse' variable may leak when return in function
intel_vgpu_ioctl(), and this patch fix this.
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Reviewed-by: NJiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: NZhenyu 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: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NZhenyu 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: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NZhenyu 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: NZhao Yan <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NZhenyu 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: NHang Yuan <hang.yuan@linux.intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NZhenyu 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: NTomasz Lis <tomasz.lis@intel.com>
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Cc: Changbin Du <changbin.du@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com
(cherry picked from commit 4eaf317a60fbea0555b936035002ca9bd9b9105d)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The LPE audio is a child device of i915, it is powered up and down
alongside the igfx and presents no independent runtime interface. This
aptly fulfils the description of a "No-Callback" Device, so mark it
thus.

Fixes: 183c0035 ("drm/i915: Fix runtime PM for LPE audio")
Testcase: igt/pm_rpm/basic-pci-d3-state
Testcase: igt/pm_rpm/basic-rte
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180802140416.6062-1-chris@chris-wilson.co.uk
(cherry picked from commit 46e831abe864a6b59fa3de253a681c0f2ee1bf2f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The register for 0xe420 is unable to hold any value, including
this bit. The documentation is also mixed between having a
register bit for toggle and having a state command setup
for it. Apparently the register toggle is deprecated.

Remove the register toggle as evidence shows it's futile.

The thing remaining is an apology and humble request for
Mesa folks to resurrect their state setup for this as they
were on right track from start.

This reverts commit 0bf059f3.

Fixes: 0bf059f3 ("drm/i915/icl: WaEnableFloatBlendOptimization")
References: HSDES#1406393558
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730120636.26958-1-mika.kuoppala@linux.intel.com
(cherry picked from commit c358514ba8da9e235876db1628cedd19a35803c6)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high load, and low despite occasional glitches under steady
low load, and inbetween. However, we run into situations like kodi where
we want to stay at low power (video decoding is done efficiently
inside the fixed function HW and doesn't need high clocks even for high
bitrate streams), but just occasionally the pipeline is more complex
than a video decode and we need a smidgen of extra GPU power to present
on time. In the high power regime, we sample at sub frame intervals with
a bias to upclocking, and conversely at low power we sample over a few
frames worth to provide what we consider to be the right levels of
responsiveness respectively. At low power, we more or less expect to be
kicked out to high power at the start of a busy sequence by waitboosting.

Prior to commit e9af4ea2 ("drm/i915: Avoid waitboosting on the active
request") whenever we missed the frame or stalled, we would immediate go
full throttle and upclock the GPU to max. But in commit e9af4ea2, we
relaxed the waitboosting to only apply if the pipeline was deep to avoid
over-committing resources for a near miss. Sadly though, a near miss is
still a miss, and perceptible as jitter in the frame delivery.

To try and prevent the near miss before having to resort to boosting
after the fact, we use the pageflip queue as an indication that we are
in an "interactive" regime and so should sample the load more frequently
to provide power before the frame misses it vblank. This will make us
more favorable to providing a small power increase (one or two bins) as
required rather than going all the way to maximum and then having to
work back down again. (We still keep the waitboosting mechanism around
just in case a dramatic change in system load requires urgent uplocking,
faster than we can provide in a few evaluation intervals.)

v2: Reduce rps_set_interactive to a boolean parameter to avoid the
confusion of what if they wanted a new power mode after pinning to a
different mode (which to choose?)
v3: Only reprogram RPS while the GT is awake, it will be set when we
wake the GT, and while off warns about being used outside of rpm.
v4: Fix deferred application of interactive mode
v5: s/state/interactive/
v6: Group the mutex with its principle in a substruct

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
Fixes: e9af4ea2 ("drm/i915: Avoid waitboosting on the active request")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk
(cherry picked from commit 60548c554be2830d29d2533dad0ac8133347ee51)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

First of all don't try to read dpcd if PSR is not even supported.

But also, if read failed return -EIO instead of reporting via a
backchannel.

v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
    don't convert dpcd read errors to EIO. (DK)

Fixes: 5b7b3086 ("drm/i915/psr: Split sink status into a separate debugfs node")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
(cherry picked from commit 7a72c78bdd0a1ea1d879610542679cc680398220)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>