1. 06 3月, 2018 4 次提交
    • C
      drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup overhead · cf4ee73f
      Changbin Du 提交于
      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>
      cf4ee73f
    • Z
      drm/i915/gvt: remove gvt max port definition · 0102d0d9
      Zhenyu Wang 提交于
      Remove GVT-g private max port definition but use i915 one.
      
      Fix error caused by:
      drivers/gpu/drm/i915//gvt/handlers.c:871 dp_aux_ch_ctl_mmio_write() error: buffer overflow 'display->ports' 5 <= 5
      Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      0102d0d9
    • W
      drm/i915/gvt: init mmio by lri command in vgpu inhibit context · cd7e61b9
      Weinan Li 提交于
      There is one issue relates to Coarse Power Gating(CPG) on KBL NUC in GVT-g,
      vgpu can't get the correct default context by updating the registers before
      inhibit context submission. It always get back the hardware default value
      unless the inhibit context submission happened before the 1st time
      forcewake put. With this wrong default context, vgpu will run with
      incorrect state and meet unknown issues.
      
      The solution is initialize these mmios by adding lri command in ring buffer
      of the inhibit context, then gpu hardware has no chance to go down RC6 when
      lri commands are right being executed, and then vgpu can get correct
      default context for further use.
      
      v3:
      - fix code fault, use 'for' to loop through mmio render list(Zhenyu)
      
      v4:
      - save the count of engine mmio need to be restored for inhibit context and
        refine some comments. (Kevin)
      
      v5:
      - code rebase
      
      Cc: Kevin Tian <kevin.tian@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      cd7e61b9
    • C
      drm/i915/gvt: Provide generic page_track infrastructure for write-protected page · e502a2af
      Changbin Du 提交于
      This patch provide generic page_track infrastructure for write-protected
      guest page. The old page_track logic gets rewrote and now stays in a new
      standalone page_track.c. This page track infrastructure can be both used
      by vGUC and GTT shadowing.
      
      The important change is that it uses radix tree instead of hash table.
      We don't have a predictable number of pages that will be tracked.
      
      Here is some performance data (duration in us) of looking up a element:
      Before: (aka. intel_vgpu_find_tracked_page)
       0.091 0.089 0.090 ... 0.093 0.091 0.087 ... 0.292 0.285 0.292 0.291
      After: (aka. intel_vgpu_find_page_track)
       0.104 0.105 0.100 0.102 0.102 0.100 ... 0.101 0.101 0.105 0.105
      
      The hash table has good performance at beginning, but turns bad with
      more pages being tracked even no 3D applications are running. As
      expected, radix tree has stable duration and very quick.
      
      The overall benchmark (tested with Heaven Benchmark) marginally improved
      since this is not the bottleneck. What we benefit more from this change
      is scalability.
      Signed-off-by: NChangbin Du <changbin.du@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      e502a2af
  2. 07 2月, 2018 3 次提交
  3. 22 12月, 2017 2 次提交
  4. 12 12月, 2017 1 次提交
  5. 08 12月, 2017 2 次提交
  6. 04 12月, 2017 4 次提交
    • T
      drm/i915/gvt: Dmabuf support for GVT-g · e546e281
      Tina Zhang 提交于
      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>
      e546e281
    • T
      drm/i915/gvt: Add framebuffer decoder support · 9f31d106
      Tina Zhang 提交于
      This patch is to introduce the framebuffer decoder which can decode guest
      OS's framebuffer information, including primary, cursor and sprite plane.
      
      v16:
      - rebase to 4.14.0-rc6.
      
      v14:
      - refine pixel format table. (Zhenyu)
      
      v9:
      - move drm format change to a separate patch. (Xiaoguang)
      
      v8:
      - fix a bug in decoding primary plane. (Tina)
      
      v7:
      - refine framebuffer decoder code. (Zhenyu)
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      9f31d106
    • T
      drm/i915/gvt: Add opregion support · b851adea
      Tina Zhang 提交于
      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>
      b851adea
    • X
      drm/i915/gvt: Alloc and Init guest opregion at vgpu creation · 4dff110b
      Xiong Zhang 提交于
      Currently guest opregion is allocated and initialised when guest
      write opregion base register. This is too late for kvmgt, so
      move it to vgpu_create time.
      Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
      Tested-by: NTina Zhang <tina.zhang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      4dff110b
  7. 16 11月, 2017 12 次提交
  8. 08 9月, 2017 3 次提交
    • C
      drm/i915/gvt: Add support for PCIe extended configuration space · 02d578e5
      Changbin Du 提交于
      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>
      02d578e5
    • F
      drm/i915/gvt: Separate cmd scan from request allocation · 0a53bc07
      fred gao 提交于
      Currently i915 request structure and shadow ring buffer are allocated
      before command scan, so it will have to restore to previous states once
      any error happens afterwards in the long dispatch_workload path.
      
      This patch is to introduce a reserved ring buffer created at the beginning
      of vGPU initialization. Workload will be coped to this reserved buffer and
      be scanned first, the i915 request and shadow ring buffer are only
      allocated after the result of scan is successful.
      
      To balance the memory usage and buffer alloc time, the coming bigger ring
      buffer will be reallocated and kept until more bigger buffer is coming.
      
      v2:
      - use kmalloc for the smaller ring buffer, realloc if required. (Zhenyu)
      
      v3:
      - remove the dynamically allocated ring buffer. (Zhenyu)
      
      v4:
      - code style polish.
      - kfree previous allocated buffer once kmalloc failed. (Zhenyu)
      Signed-off-by: Nfred gao <fred.gao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      0a53bc07
    • C
      drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach · f090a00d
      Changbin Du 提交于
      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>
      f090a00d
  9. 10 8月, 2017 2 次提交
    • K
      drm/i915/gvt: Add shadow context descriptor updating · 9dfb8e5b
      Kechen Lu 提交于
      The current context logic only updates the descriptor of context when
      it's being pinned to graphics memory space. But this cannot satisfy the
      requirement of shadow context. The addressing mode of the pinned shadow
      context descriptor may be changed according to the guest addressing mode.
      And this won't be updated, as the already pinned shadow context has no
      chance to update its descriptor. And this will lead to GPU hang issue,
      as shadow context is used with wrong descriptor. This patch fixes this
      issue by letting the pinned shadow context descriptor update its
      addressing mode on demand.
      
      This patch fixes GPU HANG issue which happends after changing the
      grub parameter i915.enable_ppgtt form 0x01 to 0x03 or vice versa and
      then rebooting the guest.
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Signed-off-by: NKechen Lu <kechen.lu@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      9dfb8e5b
    • P
      drm/i915/gvt: Factor out scan and shadow from workload dispatch · 89ea20b9
      Ping Gao 提交于
      To perform the workload scan and shadow in ELSP writing stage for
      performance consideration, the workload scan and shadow stuffs
      should be factored out from dispatch_workload().
      
      v2:Put context pin before i915_add_request;
         Refine the comments;
         Rename some APIs;
      
      v3:workload->status should set only when error happens.
      v4:i915_add_request is must to have after i915_gem_request_alloc.
      Signed-off-by: NPing Gao <ping.a.gao@intel.com>
      Reviewed-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      89ea20b9
  10. 04 8月, 2017 1 次提交
  11. 02 8月, 2017 1 次提交
  12. 11 7月, 2017 1 次提交
  13. 26 6月, 2017 1 次提交
    • C
      drm/i915/gvt: Fix possible recursive locking issue · 62d02fd1
      Chuanxiao Dong 提交于
      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>
      62d02fd1
  14. 08 6月, 2017 3 次提交