commit 7366aeb77cd840f3edea02c65065d40affaa7f45 upstream.

GPU hang observed during the guest OCL conformance test which is caused
by THP GTT feature used durning the test.

It was observed the same GFN with different size (4K and 2M) requested
from the guest in GVT. So during the guest page dma map stage, it is
required to unmap first with orginal size and then remap again with
requested size.

Fixes: b901b252 ("drm/i915/gvt: Add 2M huge gtt support")
Cc: stable@vger.kernel.org
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51b00d8509dc69c98740da2ad07308b630d3eb7d upstream.

This is to fix missed mmap range check on vGPU bar2 region
and only allow to map vGPU allocated GMADDR range, which means
user space should support sparse mmap to get proper offset for
mmap vGPU aperture. And this takes care of actual pgoff in mmap
request as original code always does from beginning of vGPU
aperture.

Fixes: 659643f7 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com>
Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com>
Cc: stable@vger.kernel.org # v4.10+
Reviewed-by: NHang Yuan <hang.yuan@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

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>

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>

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>

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>

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>

To support huge gtt, we need to support huge pages in kvmgt first.
This patch adds a 'size' param to the intel_gvt_mpt::dma_map_guest_page
API and implements it in kvmgt.

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

This can fix below oops. The target pfn must be mem backed.

[ 3639.109674] BUG: unable to handle kernel paging request at ffff8c44832a3000
[ 3639.109681] IP: memcpy_erms+0x6/0x10
[ 3639.109682] PGD 0 P4D 0
[ 3639.109685] Oops: 0000 1 SMP PTI
[ 3639.109726] CPU: 2 PID: 1724 Comm: qemu-system-x86 Not tainted 4.16.0-rc5+ #1
[ 3639.109727] Hardware name: /NUC7i7BNB, BIOS BNKBL357.86A.0050.2017.0816.2002 08/16/2017
[ 3639.109729] RIP: 0010:memcpy_erms+0x6/0x10
[ 3639.109730] RSP: 0018:ffffb1b7c3fbbbf0 EFLAGS: 00010246
[ 3639.109731] RAX: ffff8a44b6460000 RBX: 0000000036460000 RCX: 0000000000001000
[ 3639.109732] RDX: 0000000000001000 RSI: ffff8c44832a3000 RDI: ffff8a44b6460000
[ 3639.109733] RBP: 000000000006c8c0 R08: ffff8a44b6460000 R09: 0000000000000000
[ 3639.109734] R10: ffffb1b7c3fbbcd0 R11: ffff8a4d102018c0 R12: 0000000000000000
[ 3639.109734] R13: 0000000000000002 R14: 0000000000200000 R15: 0000000000000000
[ 3639.109736] FS: 00007f37f6d09700(0000) GS:ffff8a4d36d00000(0000) knlGS:0000000000000000
[ 3639.109737] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3639.109738] CR2: ffff8c44832a3000 CR3: 000000088b7b8004 CR4: 00000000003626e0
[ 3639.109739] Call Trace:
[ 3639.109743] swiotlb_tbl_map_single+0x2bb/0x300
[ 3639.109746] map_single+0x30/0x80
[ 3639.109748] swiotlb_map_page+0x87/0x150
[ 3639.109751] kvmgt_dma_map_guest_page+0x329/0x3a0 [kvmgt]
[ 3639.109764] ? kvm_write_guest_offset_cached+0x84/0xe0 [kvm]
[ 3639.109789] intel_vgpu_emulate_ggtt_mmio_write+0x1f4/0x250 [i915]
[ 3639.109808] intel_vgpu_emulate_mmio_write+0x162/0x230 [i915]
[ 3639.109811] intel_vgpu_rw+0x1fc/0x240 [kvmgt]
[ 3639.109813] intel_vgpu_write+0x164/0x1f0 [kvmgt]
[ 3639.109816] __vfs_write+0x33/0x170
[ 3639.109818] ? do_vfs_ioctl+0x9f/0x5f0
[ 3639.109820] vfs_write+0xb3/0x1a0
[ 3639.109822] SyS_pwrite64+0x90/0xb0
[ 3639.109825] do_syscall_64+0x68/0x120
[ 3639.109827] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 3639.109829] RIP: 0033:0x7f3802b2d873
[ 3639.109830] RSP: 002b:00007f37f6d08670 EFLAGS: 00000293 ORIG_RAX: 0000000000000012
[ 3639.109831] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f3802b2d873
[ 3639.109832] RDX: 0000000000000008 RSI: 00007f37f6d086a0 RDI: 000000000000001a
[ 3639.109833] RBP: 00007f37f6d086c0 R08: 0000000000000008 R09: ffffffffffffffff
[ 3639.109834] R10: 00000000008041c8 R11: 0000000000000293 R12: 00007ffd8bbf92ae
[ 3639.109835] R13: 00007ffd8bbf92af R14: 00007f37f6d09700 R15: 00007f37f6d099c0

v2: add Fixes tag.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Fixes: cf4ee73f ("drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup overhead")
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

kvmgt get msi eventfd_ctx at qemu vfio set irq eventfd, then
msi eventfd_ctx should be put at some point.
The first point is kvmgt handle qemu vfio_disable_irqindex()
call which has DATA_NONE and ACTION_TRIGGER in flags.
If qemu doesn't call vfio_disable_irqindex(), the second point
is vgpu release function.

v2: Don't inject msi interrupt into guest if eventfd_ctx is dereferenced
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

On unknown/unhandled ioctls the driver should return an error, so
userspace knows it tried to use something unsupported.

Cc: stable@vger.kernel.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Out-of-memory error must be handled correctly.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Add a new debugfs entry kvmgt_nr_cache_entries under vgpu which shows
the number of entry in dma cache.

$ cat /sys/kernel/debug/gvt/vgpu1/kvmgt_nr_cache_entries
10101

v3: fix compiling error for some configuration. (Xiong Zhang <xiong.y.zhang@intel.com>)
v2: keep debugfs layout flat.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The implementation of current kvmgt implicitly setup dma mapping at MPT
API gfn_to_mfn. First this design against the API's original purpose.
Second, there is no unmap hit in this design. The result is that the
dma mapping keep growing larger and larger. For mutl-vm case, they will
consume IOMMU IOVA low 4GB address space quickly and so tons of rbtree
entries crated in the IOMMU IOVA allocator. Finally, single IOVA
allocation can take as long as ~70ms. Such latency is intolerable.

To address both above issues, this patch introduced two new MPT API:
  o dma_map_guest_page - setup dma map for guest page
  o dma_unmap_guest_page - cancel dma map for guest page

The kvmgt implements these 2 API. And to reduce dma setup overhead for
duplicated pages (eg. scratch pages), two caches are used: one is for
mapping gfn to struct gvt_dma, another is for mapping dma addr to
struct gvt_dma.

With these 2 new API, the gtt now is able to cancel dma mapping when page
table is invalidated. The dma mapping is not in a gradual increase now.

v2: follow the old logic for VFIO_IOMMU_NOTIFY_DMA_UNMAP at this point.

Cc: Hang Yuan <hang.yuan@intel.com>
Cc: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Fix check error at

  CHECK   drivers/gpu/drm/i915//gvt/kvmgt.c
drivers/gpu/drm/i915//gvt/kvmgt.c:455 intel_vgpu_create() error: we previously assumed 'vgpu' could be null (see line 454)

For failed vgpu create, just show error return in failure message.
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The kvmgt's implementation of mpt api {set,unset}_wp_page is not real
write-protection - the data get written before invoke this two api.
As discussed, change the mpt api to match the real behavior.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

GGTT is in BAR0 with 8 bytes aligned. With a qemu patch (commit:
38d49e8c1523d97d2191190d3f7b4ce7a0ab5aa3), VFIO can use 8-byte reads/
writes to access it.

This patch is to support the 8-byte GGTT reads/writes.

Ideally, we would like to support 8-byte reads/writes for the total BAR0.
But it needs more work for handling 8-byte MMIO reads/writes.

This patch can fix the issue caused by partial updating GGTT entry, during
guest booting up.

v3:
- Use intel_vgpu_get_bar_gpa() stead. (Zhenyu)
- Include all the GGTT checking logic in gtt_entry(). (Zhenyu)

v2:
- Limit to GGTT entry. (Zhenyu)
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest
is emulated. But the vgpu_aperture_rw() function take wrong offset when
do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture.
This mistake cause GPU command in guest get lost and so the seqno is not
updated in engine HWSP.

This patch fix this, and it also move the emulation code to kvmgt.
Because only vfio need to emulate it. Put aperture rw to MMIO emulation
path breaks assumptions in xengt.

v2: Remove PAGE_ALIGN for size (zhenyu)

Fixes: f090a00d ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach")
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@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>

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>

The vfio_info_add_capability() helper requires the caller to pass a
capability ID, which it then uses to fill in header fields, assuming
hard coded versions.  This makes for an awkward and rigid interface.
The only thing we want this helper to do is allocate sufficient
space in the caps buffer and chain this capability into the list.
Reduce it to that simple task.
Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NKirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.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>

This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared between guest VM and host.

v17:
- modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex)

v16:
- add x_hot and y_hot. (Gerd)
- add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex)
- rebase 4.14.0-rc6.

v15:
- add VFIO_DEVICE_GET_GFX_DMABUF ABI. (Gerd)
- add intel_vgpu_dmabuf_cleanup() to clean up the vGPU's dmabuf. (Gerd)

v14:
- add PROBE, DMABUF and REGION flags. (Alex)

v12:
- refine the lifecycle of dmabuf.

v9:
- remove dma-buf management. (Alex)
- track the dma-buf create and release in kernel mode. (Gerd) (Daniel)

v8:
- refine the dma-buf ioctl definition.(Alex)
- add a lock to protect the dmabuf list. (Alex)

v7:
- release dma-buf related allocations in dma-buf's associated release
  function. (Alex)
- refine ioctl interface for querying plane info or create dma-buf.
  (Alex)

v6:
- align the dma-buf life cycle with the vfio device. (Alex)
- add the dma-buf related operations in a separate patch. (Gerd)
- i915 related changes. (Chris)

v5:
- fix bug while checking whether the gem obj is gvt's dma-buf when user
  change caching mode or domains. Add a helper function to do it.
  (Xiaoguang)
- add definition for the query plane and create dma-buf. (Xiaoguang)

v4:
- fix bug while checking whether the gem obj is gvt's dma-buf when set
  caching mode or doamins. (Xiaoguang)

v3:
- declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object
  to represent the gem obj for gvt's dma-buf. The tiling mode, caching
  mode and domains can not be changed for this kind of gem object. (Alex)
- change dma-buf related information to be more generic. So other vendor
  can use the same interface. (Alex)

v2:
- create a management fd for dma-buf operations. (Alex)
- alloc gem object's backing storage in gem obj's get_pages() callback.
  (Chris)
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Windows guest driver needs vbt in opregion, to configure the setting
for display. Without opregion support, the display registers won't
be set and this blocks display model to get the correct information
of the guest display plane.

This patch is to provide a virtual opregion for guest. The original
author of this patch is Xiaoguang Chen.

This patch is split from the "Dma-buf support for GVT-g" patch set,
with being rebased to the latest gvt-staging branch.

v3:
- add checking region index during intel_vgpu_rw. (Xiong)

v2:
- refine intel_vgpu_reg_release_opregion. (Xiong)

Here are the previous version comments:

v18:
- unmap vgpu's opregion when destroying vgpu.

v16:
- rebase to 4.14.0-rc6.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Tested-by: NXiong Zhang <xiong.y.zhang@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

all the vGPU type related code in kvmgt will be moved into
gvt.c/gvt.h files while the common vGPU type related interfaces
will be called.

v2:
- intel_gvt_{init,cleanup}_vgpu_type_groups are initialized in
  gvt part. (Wang, Zhi)
Signed-off-by: Nfred gao <fred.gao@intel.com>
Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>

Introduce intel_vgpu_submission to hold all members related to submission
in struct intel_vgpu before.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>

IGD is PCIe device and has extended configuration space. Checking
the binary dump, we can see we have Caps located out of PCI compatible
Configuration Space range.

0x000: 86 80 12 19 17 04 10 00 06 00 00 03 00 00 00 00
0x010: 04 00 00 10 08 00 00 00 0c 00 00 00 08 00 00 00
0x020: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 b9 06
0x030: 00 f8 ff ff 40 00 00 00 00 00 00 00 0b 01 00 00
0x040: 09 70 0c 01 71 26 01 62 c8 00 04 84 00 00 00 00
0x050: c1 00 00 00 39 00 00 00 00 00 00 00 01 00 00 a2
0x060: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
0x070: 10 ac 92 00 00 80 00 10 00 00 00 00 00 00 00 00
0x080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0a0: 00 00 00 00 00 00 00 00 00 00 00 00 05 d0 01 00
0x0b0: 18 00 e0 fe 00 00 00 00 00 00 00 00 00 00 00 00
0x0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0d0: 01 00 22 00 00 80 00 00 00 00 00 00 00 00 00 00
0x0e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00
0x0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100: 1b 00 01 20 02 14 00 00 00 00 00 00 00 00 00 00
...

Currently, we only emulate the PCI compatible Configuration Space.
This is okay if we attach vGPU to PCI bus. But when we attach to
a PCI Express bus (when Qemu emulates a Intel Q35 chipset which has
PCIe slot), it will not work. Extended Configuration Space is required
for a PCIe device.

This patch extended the virtual configuration space from 256 bytes
to 4KB bytes. So we are to be a *real* PCIe device. And for the
Extended CapList we keep same to physical GPU.

Cc: Laszlo Ersek <lersek@redhat.com>
Tested-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

For vfio-pci, if the region support MMAP then it should support both
mmap and normal file access. The user-space is free to choose which is
being used. For qemu, we just need add 'x-no-mmap=on' for vfio-pci
option.

Currently GVTg only support MMAP for BAR2. So GVTg will not work when
user turn on x-no-mmap option.

This patch added file style access for BAR2, aka the GPU aperture. We
map the entire aperture partition of active vGPU to kernel space when
guest driver try to enable PCI Memory Space. Then we redirect the file
RW operation from kvmgt to this mapped area.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458032Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

For PCI, 64bit bar consumes two BAR registers, but this doesn't mean
both of two BAR are valid. Actually the second BAR is regarded as
reserved in this case. So we shouldn't emulate the second BAR.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This exposes vGPU context hw id in mdev sysfs which is used to
do vGPU based profiling. Retrieved vGPU context hw id can be set
through i915 perf ioctl to set profiling for target vGPU.

Cc: Jiao Pengyuan <pengyuan.jiao@intel.com>
Cc: Niu Bing <bing.niu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

This reverts commit 62d02fd1.

The rwsem recursive trace should not be fixed from kvmgt side by using
a workqueue and it is an issue should be fixed in VFIO. So this one
should be reverted.
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

There are two kinds of locking sequence.

One is in the thread which is started by vfio ioctl to do
the iommu unmapping. The locking sequence is:
	down_read(&group_lock) ----> mutex_lock(&cached_lock)

The other is in the vfio release thread which will unpin all
the cached pages. The lock sequence is:
	mutex_lock(&cached_lock) ---> down_read(&group_lock)

And, the cache_lock is used to protect the rb tree of the cache
node and doing vfio unpin doesn't require this lock. Move the
vfio unpin out of the cache_lock protected region.

v2:
- use for style instead of do{}while(1). (Zhenyu)

Fixes: f30437c5 ("drm/i915/gvt: add KVMGT support")
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

vfio_unpin_pages will hold a read semaphore however it is already hold
in the same thread by vfio ioctl. It will cause below warning:

[ 5102.127454] ============================================
[ 5102.133379] WARNING: possible recursive locking detected
[ 5102.139304] 4.12.0-rc4+ #3 Not tainted
[ 5102.143483] --------------------------------------------
[ 5102.149407] qemu-system-x86/1620 is trying to acquire lock:
[ 5102.155624]  (&container->group_lock){++++++}, at: [<ffffffff817768c6>] vfio_unpin_pages+0x96/0xf0
[ 5102.165626]
but task is already holding lock:
[ 5102.172134]  (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.182522]
other info that might help us debug this:
[ 5102.189806]  Possible unsafe locking scenario:

[ 5102.196411]        CPU0
[ 5102.199136]        ----
[ 5102.201861]   lock(&container->group_lock);
[ 5102.206527]   lock(&container->group_lock);
[ 5102.211191]
*** DEADLOCK ***

[ 5102.217796]  May be due to missing lock nesting notation

[ 5102.225370] 3 locks held by qemu-system-x86/1620:
[ 5102.230618]  #0:  (&container->group_lock){++++++}, at: [<ffffffff8177728f>] vfio_fops_unl_ioctl+0x5f/0x280
[ 5102.241482]  #1:  (&(&iommu->notifier)->rwsem){++++..}, at: [<ffffffff810de775>] __blocking_notifier_call_chain+0x35/0x70
[ 5102.253713]  #2:  (&vgpu->vdev.cache_lock){+.+...}, at: [<ffffffff8157b007>] intel_vgpu_iommu_notifier+0x77/0x120
[ 5102.265163]
stack backtrace:
[ 5102.270022] CPU: 5 PID: 1620 Comm: qemu-system-x86 Not tainted 4.12.0-rc4+ #3
[ 5102.277991] Hardware name: Intel Corporation S1200RP/S1200RP, BIOS S1200RP.86B.03.01.APER.061220151418 06/12/2015
[ 5102.289445] Call Trace:
[ 5102.292175]  dump_stack+0x85/0xc7
[ 5102.295871]  validate_chain.isra.21+0x9da/0xaf0
[ 5102.300925]  __lock_acquire+0x405/0x820
[ 5102.305202]  lock_acquire+0xc7/0x220
[ 5102.309191]  ? vfio_unpin_pages+0x96/0xf0
[ 5102.313666]  down_read+0x2b/0x50
[ 5102.317259]  ? vfio_unpin_pages+0x96/0xf0
[ 5102.321732]  vfio_unpin_pages+0x96/0xf0
[ 5102.326024]  intel_vgpu_iommu_notifier+0xe5/0x120
[ 5102.331283]  notifier_call_chain+0x4a/0x70
[ 5102.335851]  __blocking_notifier_call_chain+0x4d/0x70
[ 5102.341490]  blocking_notifier_call_chain+0x16/0x20
[ 5102.346935]  vfio_iommu_type1_ioctl+0x87b/0x920
[ 5102.351994]  vfio_fops_unl_ioctl+0x81/0x280
[ 5102.356660]  ? __fget+0xf0/0x210
[ 5102.360261]  do_vfs_ioctl+0x93/0x6a0
[ 5102.364247]  ? __fget+0x111/0x210
[ 5102.367942]  SyS_ioctl+0x41/0x70
[ 5102.371542]  entry_SYSCALL_64_fastpath+0x1f/0xbe

put the vfio_unpin_pages in a workqueue can fix this.

v2:
- use for style instead of do{}while(1). (Zhenyu)
v3:
- rename gvt_cache_mark to gvt_cache_mark_remove. (Zhenyu)

Fixes: 659643f7 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The variable info is never NULL, which is checked by the caller. This
patch removes the redundant info NULL check logic.

Fixes: 695fbc08 ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit 865f03d4)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch introduces two functions for activating/de-activating vGPU in
mdev ops.

A racing condition was found between virtual vblank emulation and KVGMT
mdev release path. V-blank emulation will emulate and inject V-blank
interrupt for every active vGPU with holding gvt->lock, while in mdev
release path, it will directly release hypervisor handle without changing
vGPU status or taking gvt->lock, so a kernel oops is encountered when
vblank emulation is injecting a interrupt with a invalid hypervisor
handle. (Reported by Terrence)

To solve this problem, we factor out vGPU activation/de-activation from
vGPU creation/destruction path and let KVMGT mdev release ops de-activate
the vGPU before release hypervisor handle. Once a vGPU is de-activated,
GVT-g will not emulate v-blank for it or touch the hypervisor handle.

Fixes: 659643f7 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT")
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The weight defines proportional control of physical GPU resource
shared between vGPUs. So far the weight is tied to a specific vGPU
type, i.e when creating multiple vGPUs with different types, they
will inherit different weights.

e.g. The weight of type GVTg_V5_2 is 8, the weight of type GVTg_V5_4
is 4, so vGPU of type GVTg_V5_2 has double vGPU resource of vGPU type
GVTg_V5_4.

TODO: allow user control the weight setting in the future.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Reviewed-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The variable info is never NULL, which is checked by the caller. This
patch removes the redundant info NULL check logic.

Fixes: 695fbc08 ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>