Stop gvt scheduler timer if no vGPU exists, otherwise it keeps
gvt service thread busy to handle request schedule event but no
actual schedule activity required.
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Stop irq timer for virtual vblank timer emulation if no vGPU exists,
otherwise it will keep gvt service thread busy to handle virtual vblank
but no use.
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

According to commit (319c933c)
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 15 00:02:46 2013 +0200

    drm/prime: proper locking+refcounting for obj->dma_buf link

obj->dma_buf link should be reinstated at import time.

Gvt-g dma-buf buffer exposeing might be simpler, as there won't be much
racing during Gvt-g dma-buf exposing. In other words, Gvt-g dma-buf
exposing can guarantee exposing happens before gem close ioctl, and Gvt-g
is the only exporter of the guest framebuffer.

But following the drm prime scheme can give Gvt-g a chance to increase a
dma-buf reference count during importing. Otherwise, we have to increase
the reference during exposing, which will break the case that the only
reference userspace has held was through the dma-buf fd and the reference
count is one.
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Hang Yuan <hang.yuan@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The mocs reg array is defined locally but then we iterate over its
elements using I915_NUM_ENGINES. There is no 'hard' connection between
I915_NUM_ENGINES and the regs array and there will be problems if either
of them increases.

Use the size of the mocs reg array instead to safely iterate over it.
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Cc: Weinan Li <weinan.z.li@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

GVT may receive partial write on one guest PTE update. Validate gfn
not to translate incomplete gfn. This avoids some unnecessary error
messages incurred by the incomplete gfn translating. Also fix the
bug that the whole PPGTT shadow page update is aborted on any invalid
gfn entry.

gfn validation relys on hypervisor's help. Add one MPT module function
to provide the function.
Signed-off-by: NHang Yuan <hang.yuan@intel.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Running 4.15 Linux kernel in VM will cause host GVT reports
'untrack mmio 0x701a0' errror, which identifies the PLANE_KEYMAX
registers. Add them to track list.

v2: rebase to latest staging code.
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

while(mmio++) increase mmio to next, mmio[0] never take effect
in while loop.

This patch change while to for and fix the above issue.

v2: Correct Fixes format.(Zhenyu)
v3: Rebase to latest staging.(Zhenyu)

Fixes: 83164886("drm/i915/gvt: Select appropriate mmio list at initialization time")
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

for_each_set_bit() only accepts variable of type unsigned long, and we can
not cast it from smaller types.

[   16.499365] ==================================================================
[   16.506655] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x1d/0x70
[   16.513313] Read of size 8 at addr ffff8803616cf510 by task systemd-udevd/180
[   16.521998] CPU: 0 PID: 180 Comm: systemd-udevd Tainted: G     U     O     4.15.0-rc3+ #14
[   16.530317] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016
[   16.537760] Call Trace:
[   16.540230]  dump_stack+0x7c/0xbb
[   16.543569]  print_address_description+0x6b/0x290
[   16.548306]  kasan_report+0x28a/0x370
[   16.551993]  ? find_first_bit+0x1d/0x70
[   16.555858]  find_first_bit+0x1d/0x70
[   16.559625]  intel_gvt_init_cmd_parser+0x127/0x3c0 [i915]
[   16.565060]  ? __lock_is_held+0x8f/0xf0
[   16.568990]  ? intel_gvt_clean_cmd_parser+0x10/0x10 [i915]
[   16.574514]  ? __hrtimer_init+0x5d/0xb0
[   16.578445]  intel_gvt_init_device+0x2c3/0x690 [i915]
[   16.583537]  ? unregister_module_notifier+0x20/0x20
[   16.588515]  intel_gvt_init+0x89/0x100 [i915]
[   16.592962]  i915_driver_load+0x1992/0x1c70 [i915]
[   16.597846]  ? __i915_printk+0x210/0x210 [i915]
[   16.602410]  ? wait_for_completion+0x280/0x280
[   16.606883]  ? lock_downgrade+0x2c0/0x2c0
[   16.610923]  ? __pm_runtime_resume+0x46/0x90
[   16.615238]  ? acpi_dev_found+0x76/0x80
[   16.619162]  ? i915_pci_remove+0x30/0x30 [i915]
[   16.623733]  local_pci_probe+0x74/0xe0
[   16.627518]  pci_device_probe+0x208/0x310
[   16.631561]  ? pci_device_remove+0x100/0x100
[   16.635871]  ? __list_add_valid+0x29/0xa0
[   16.639919]  driver_probe_device+0x40b/0x6b0
[   16.644223]  ? driver_probe_device+0x6b0/0x6b0
[   16.648696]  __driver_attach+0x11d/0x130
[   16.652649]  bus_for_each_dev+0xe7/0x160
[   16.656600]  ? subsys_dev_iter_exit+0x10/0x10
[   16.660987]  ? __list_add_valid+0x29/0xa0
[   16.665028]  bus_add_driver+0x31d/0x3a0
[   16.668893]  driver_register+0xc6/0x170
[   16.672758]  ? 0xffffffffc0ad8000
[   16.676108]  do_one_initcall+0x9c/0x206
[   16.679984]  ? initcall_blacklisted+0x150/0x150
[   16.684545]  ? do_init_module+0x35/0x33b
[   16.688494]  ? kasan_unpoison_shadow+0x31/0x40
[   16.692968]  ? kasan_kmalloc+0xa6/0xd0
[   16.696743]  ? do_init_module+0x35/0x33b
[   16.700694]  ? kasan_unpoison_shadow+0x31/0x40
[   16.705168]  ? __asan_register_globals+0x82/0xa0
[   16.709819]  do_init_module+0xe7/0x33b
[   16.713597]  load_module+0x4481/0x4ce0
[   16.717397]  ? module_frob_arch_sections+0x20/0x20
[   16.722228]  ? vfs_read+0x13b/0x190
[   16.725742]  ? kernel_read+0x74/0xa0
[   16.729351]  ? get_user_arg_ptr.isra.17+0x70/0x70
[   16.734099]  ? SYSC_finit_module+0x175/0x1b0
[   16.738399]  SYSC_finit_module+0x175/0x1b0
[   16.742524]  ? SYSC_init_module+0x1e0/0x1e0
[   16.746741]  ? __fget+0x157/0x240
[   16.750090]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[   16.754747]  entry_SYSCALL_64_fastpath+0x23/0x9a
[   16.759397] RIP: 0033:0x7f8fbc837499
[   16.762996] RSP: 002b:00007ffead76c138 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   16.770618] RAX: ffffffffffffffda RBX: 0000000000000012 RCX: 00007f8fbc837499
[   16.777800] RDX: 0000000000000000 RSI: 000056484e67b080 RDI: 0000000000000012
[   16.784979] RBP: 00007ffead76b140 R08: 0000000000000000 R09: 0000000000000021
[   16.792164] R10: 0000000000000012 R11: 0000000000000246 R12: 000056484e67b460
[   16.799345] R13: 00007ffead76b120 R14: 0000000000000005 R15: 0000000000000000
[   16.808052] The buggy address belongs to the page:
[   16.812876] page:00000000dc4b8c1e count:0 mapcount:0 mapping:          (null) index:0x0
[   16.820934] flags: 0x17ffffc0000000()
[   16.824621] raw: 0017ffffc0000000 0000000000000000 0000000000000000 00000000ffffffff
[   16.832416] raw: ffffea000d85b3e0 ffffea000d85b3e0 0000000000000000 0000000000000000
[   16.840208] page dumped because: kasan: bad access detected
[   16.847318] Memory state around the buggy address:
[   16.852143]  ffff8803616cf400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   16.859427]  ffff8803616cf480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
[   16.866708] >ffff8803616cf500: f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00
[   16.873988]                          ^
[   16.877770]  ffff8803616cf580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   16.885042]  ffff8803616cf600: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[   16.892312] ==================================================================
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

A shadow page table entry needs to be cleared after being set as
post-sync. This patch fixes the recent error reported in Win7-32 test.

Fixes: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

It's a bit confusing that page write protect handler is live in
mmio emulation handler. This moves it to stand alone gvt ops.

Also remove unnecessary check of write protected page access
in mmio read handler and cleanup handling of failsafe case.

v2: rebase
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

We had previous hack that tried to accept either i915_reg_t or offset
value to access vGPU virtual/shadow regs which broke that purpose to
be type safe in context. This one trys to explicitly separate the usage
of typed mmio reg with real offset.

Old vgpu_vreg(offset) helper is used only for offset now with new
vgpu_vreg_t(reg) is used for i915_reg_t only. Convert left usage
of that to new helper.

Also fixed left KASAN warning issues caused by previous hack.

v2: rebase, fixup against recent mmio switch change
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

observed igt drv_module_reload test case failure on 4.15.0
rc2 kernel with panic due to no active pipe available.

the gpu will reset during unload/load and make pipe config reg
lost which can cause kernel panic issue happen.

this patch is to move pipe enabling to emulate_mointor_status_chagne
to handle vgpu reset case as well.

Fixes: 7e605902 ("drm/i915/gvt: enabled pipe A default on creating vgpu")
Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit f5f00e7d)

Always requires properly defined i915_reg_t type for MMIO handler
definition.

Fix kasan warning of "drivers/gpu/drm/i915/gvt/handlers.c:2397:1: error: the frame size of 32120 bytes is larger than 8192 bytes"
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Load host render mocs registers once for delta update of mocs switch, it
reduces mmio read times obviously, then brings performance improvement
during multi-vms switch.
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Save and restore the mocs regs of one VM in GVT-g burning too much CPU
utilization. Add LRI command scan to monitor the change of mocs registers,
save the state in vreg, and use delta update policy to restore them.
It can obviously reduce the MMIO r/w count, and improve the performance
of context switch.
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Now mmio switch between vGPUs need to switch to host first then to expected
vGPU, it waste one time mmio save/restore. r/w mmio usually is
time-consuming, and there are so many mocs registers need to save/restore
during vGPU switch. Combine the switch_to_host and switch_to_vgpu can
reduce 1 time mmio save/restore, it will reduce the CPU utilization and
performance while there is multi VMs with heavy work load.
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Refine trace_render_mmio to show the vm id before and after vgpu switch,
tag host id as '0', this patch will be used in the future patch for refine
mocs switch policy.
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Now that we are using struct resource to track the stolen region, it is
more convenient if we track the mappable region in a resource as well.

v2: prefer iomap and gmadr naming scheme
    prefer DEFINE_RES_MEM
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171211151822.20953-8-matthew.auld@intel.com

observed igt drv_module_reload test case failure on 4.15.0
rc2 kernel with panic due to no active pipe available.

the gpu will reset during unload/load and make pipe config reg
lost which can cause kernel panic issue happen.

this patch is to move pipe enabling to emulate_mointor_status_chagne
to handle vgpu reset case as well.

Fixes: 7e605902 ("drm/i915/gvt: enabled pipe A default on creating vgpu")
Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge
number as fmt is of type u32, hence there is an out-of-bounds read when
using fmt as an index for array skl_pixel_formats at line 225:
plane->bpp = skl_pixel_formats[fmt].bpp;

Fix this by comparing the value returned by function skl_format_to_drm
against the size of array skl_pixel_formats, so in case it is greater than
or equal to the number of items contained in skl_pixel_formats, print an
error message and return -EINVAL.

Addresses-Coverity-ID: 1462495
Addresses-Coverity-ID: 1462502 ("Out-of-bounds read")
Fixes: 9f31d106 ("drm/i915/gvt: Add framebuffer decoder support")
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

These 2 functions are coded by multiple person in multiple patches. The
'return' and 'goto err' are mix-used in same place, which cause the
function looks disorder. Unify to use only 'goto' so that the gvt lock
is acquired in one place and released in one place.
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

In the process of dmabuf_obj cleanup, the dmabuf_obj might be freed during
dmabuf_obj_put leaking intel_gvt_hypervisor_put_vfio_device.

Move intel_gvt_hypervisor_put_vfio_device and all the other dmabuf_obj ops
in front of dmabuf_obj_put and let every dmabuf_obj have a chance to call
intel_gvt_hypervisor_put_vfio_device to fix this leaking issue.

Fixes: e3a0d7976c53 ("drm/i915/gvt: Handle orphan dmabuf_objs")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Both ROM/VGA region are not supported for vGPU in GVT. But if the device
model want to get those region, we should return the correct information
but not leave the structure with random data. Change to same operation
of BAR3-BAR5 which are also not supported by vGPU.

Refer to function @intel_vgpu_rw.
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Rename the files to reflect their real role - to switch the mmio context of
each vGPU engine.

v2: update Makefile.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

After engine mmio switched, software still need write workload
submission registers. So we can remove the MMIO barriar in MMIO
switch.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Select appropriate mmio list at initialization time, so we don't need to
do duplicated work at where requires the mmio list.

V2:
  - Add a termination mark of mmio list.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

To improve the readability, let's remove the hard code for each mmio
definition. The raw offset remained as a comment, which give us an
offset based view.

This refine is to make it convenient for new platform enabling.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This is to workaround guest driver hang regression after
preemption enable that gvt hasn't enabled handling of that
for guest workload. So in effect this disables preemption
for gvt context now.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit 1603660b)

We shouldn't mark inactive for vGPU context if preempted,
which would still be re-scheduled later. So keep active state.

Fixes: d6c05113 ("drm/i915/execlists: Distinguish the incomplete context notifies")
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit da5f99ea)

mmio_read_from_hw() let vgpu could read hw reg, if vgpu's workload
is running on hw, things is good. Otherwise vgpu will get other
vgpu's reg val, it is unsafe.

This patch limit such hw access to active vgpu. If vgpu isn't
running on hw, the reg read of this vgpu will get the last active
val which saved at schedule_out.

v2: ring timestamp is walking continuously even if the ring is idle.
    so read hw directly. (Zhenyu)
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit 295764cd)

Since many emulation logic needs to convert the offset of ring registers
into ring id, we export it for other caller which might need it.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
(cherry picked from commit 62a6a537)

Our vGPU doesn't have a device ROM, we need follow the PCI spec to
report this info to drivers. Otherwise, we would see below errors.

Inspecting possible rom at 0xfe049000 (vd=8086:1912 bdf=00:10.0)
qemu-system-x86_64: vfio-pci: Cannot read device rom at 00000000-0000-0000-0000-000000000001
Device option ROM contents are probably invalid (check dmesg).
Skip option ROM probe with rombar=0, or load from file with romfile=No option rom signature (got 4860)

I will also send a improvement patch to PCI subsystem related to PCI ROM.
But no idea to omit below error, since no pattern to detect vbios shadow
without touch its content.
0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit c4270d12)

The ring_id maximum boundary is being compared using the > operator
instead of >=, leading to an off-by-one error and an out of bounds
write into array vgpu->hws_pga[].  Fix this by simply using the
correct comparison operator. Also re-work another comparison that
uses the comparison > I915_NUM_ENGINES - 1 to use the >= idiom using
to keep this consistent in this code.

Detected by CoverityScan, CID#1462404 ("Out-of-bounds write")

Fixes: a2ae95af ("drm/i915/gvt: update CSB and CSB write pointer in virtual HWSP")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The switch statement is missing breaks for the cases of
GVT_FAILSAFE_INSUFFICIENT_RESOURCE and GVT_FAILSAFE_GUEST_ERR. Add them
in.

Detected by CoverityScan, CID#1462416 ("Missing break in switch")

Fixes: e011c6ce ("drm/i915/gvt: Add VM healthy check for workload_thread")
Fixes: a33fc7a0 ("drm/i915/gvt: enter failsafe mode when guest requires more resources")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This is to workaround guest driver hang regression after
preemption enable that gvt hasn't enabled handling of that
for guest workload. So in effect this disables preemption
for gvt context now.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

We shouldn't mark inactive for vGPU context if preempted,
which would still be re-scheduled later. So keep active state.

Fixes: d6c05113 ("drm/i915/execlists: Distinguish the incomplete context notifies")
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The current schedule policy rely on a 1ms timer to execute workload. This
can introduce maximum 1ms unnecessary latency. This is especially bad for
small media workloads.

And I don't think we need this timer for QoS, but the change is not simply
remove the code. So I made a new API intel_gvt_kick_schedule() for future
change.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Convert the macro to a function which should always be preferred.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The per vGPU dmabuf_obj list should be released in intel_vgpu_dmabuf_
cleanup, which is invoked either in the process of closing a VM or in
the process of removing a vGPU.

Fixes: e3a0d7976c53 ("drm/i915/gvt: Handle orphan dmabuf_objs")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This patch introduces KBL platform to dma-buf on Gvt-g.
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>