1. 08 Sep, 2017 7 commits
    • fred gao's avatar
      drm/i915/gvt: Refine error handling in dispatch_workload · 0f43702a
      fred gao authored
      When an error occurs in dispatch_workload, this patch is to do the
      proper cleanup and rollback to the original states before the workload
      is abandoned.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - original PTR_ERR(cs) is good and code cleanup. (Zhenyu)
      
      v4:
      - reuse the existing i915_add_request for error handling. (Zhenyu)
      
      v5:
      - remove the duplicate error handling release_shadow_wa_ctx and
        move the engine->context_unpin upper. (Zhenyu)
      
      v6:
      - keep the old label "out". (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0f43702a
    • fred gao's avatar
      drm/i915/gvt: Refine error handling for intel_vgpu_pin_mm · 46b441ef
      fred gao authored
      When it is failed in shadow_mm, the pin_count should rollback
      to the original states before return.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
        increase the pincount after shadow success. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      46b441ef
    • fred gao's avatar
      drm/i915/gvt: Refine error handling for prepare_execlist_workload · 0cce2823
      fred gao authored
      refine the error handling for prepare_execlist_workload to restore to the
      original states once error occurs.
      
      only release the shadowed batch buffer and wa ctx when the workload is
      completed successfully.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - handle prepare batch buffer/wa ctx pin errors and
      - emulate_schedule_in null issue. (Zhenyu)
      
      v4:
      - no need to handle emulate_schedule_in null issue. (Zhenyu)
      
      v5:
      - release the shadowed batch buffer and wa ctx only for the
        successful workload. (Zhenyu)
      
      v6:
      - polish the return style. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0cce2823
    • fred gao's avatar
      drm/i915/gvt: Add error handling for intel_gvt_scan_and_shadow_workload · a3cfdca9
      fred gao authored
      When an error occurs after shadow_indirect_ctx, this patch is to do the
      proper cleanup and rollback to the original states for shadowed indirect
      context before the workload is abandoned.
      
      v2:
      - split the mixed several error paths for better review. (Zhenyu)
      
      v3:
      - no return check for clean up functions. (Changbin)
      
      v4:
      - expose and reuse the existing release_shadow_wa_ctx. (Zhenyu)
      
      v5:
      - move the release function to scheduler.c file. (Zhenyu)
      
      v6:
      - move error handling code of intel_gvt_scan_and_shadow_workload
        to here. (Zhenyu)
      Signed-off-by: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      a3cfdca9
    • fred gao's avatar
      drm/i915/gvt: Separate cmd scan from request allocation · 0a53bc07
      fred gao authored
      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: default avatarfred gao <fred.gao@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0a53bc07
    • Changbin Du's avatar
      drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach · f090a00d
      Changbin Du authored
      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: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      f090a00d
    • Changbin Du's avatar
      drm/i915/kvmgt: Sanitize PCI bar emulation · 5d5fe176
      Changbin Du authored
      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: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      5d5fe176
  2. 07 Sep, 2017 1 commit
  3. 06 Sep, 2017 7 commits
  4. 05 Sep, 2017 5 commits
  5. 04 Sep, 2017 6 commits
    • Jani Nikula's avatar
      Merge drm-upstream/drm-next into drm-intel-next-queued · d149d6ae
      Jani Nikula authored
      Catch up with upstream while it's easy.
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      d149d6ae
    • Ville Syrjälä's avatar
      drm/i915: io unmap functions want __iomem · afe722be
      Ville Syrjälä authored
      Don't cast away the __iomem from the io_mapping functions so that
      sparse won't be so unhappy when we pass the pointer to the unmap
      functions. Instead let's move the cast to where we actually use the
      pointer.
      
      Fixes the following sparse warnings:
      i915_gem.c:1022:33: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1022:33:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1022:33:    got void *[assigned] vaddr
      i915_gem.c:1027:34: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1027:34:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1027:34:    got void *[assigned] vaddr
      i915_gem.c:1199:33: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1199:33:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1199:33:    got void *[assigned] vaddr
      i915_gem.c:1204:34: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1204:34:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1204:34:    got void *[assigned] vaddr
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-2-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      afe722be
    • Ville Syrjälä's avatar
      drm/i915: Add __rcu to radix tree slot pointer · c23aa71b
      Ville Syrjälä authored
      radix_tree_for_each_slot() wants an __rcu annotated pointer for the
      slot. So let's add the annotation.
      
      Fixes the following sparse warnings:
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:2217:9:    expected void [noderef] <asn:4>**slot
      i915_gem.c:2217:9:    got void **slot
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c23aa71b
    • Ville Syrjälä's avatar
      drm/i915: Wake up the device for the fbdev setup · c6364232
      Ville Syrjälä authored
      Our fbdev setup requires the device to be awake for access
      through the GTT. If one boots without connected displays and
      later plugs one in, we won't have any runtime PM references when
      the fbdev setup runs. Explicitly grab a runtime PM reference during
      the fbdev setup to avoid the following spew:
      
      [   62.518435] RPM wakelock ref not held during HW access
      [   62.518459] ------------[ cut here ]------------
      [   62.518546] WARNING: CPU: 3 PID: 37 at ../drivers/gpu/drm/i915/intel_drv.h:1800 i915_vma_pin_iomap+0x144/0x150 [i915]
      [   62.518585] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole nls_iso8859_1 nls_cp437 vfat fat efi_pstore coretemp hwmon intel_rapl x86_pkg_temp_thermal e1000e efivars ptp pps_core video evdev ip_tables x_tables ipv6 autofs4
      [   62.518741] CPU: 3 PID: 37 Comm: kworker/3:1 Not tainted 4.13.0-rc7-skl+ #1077
      [   62.518770] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
      [   62.518827] Workqueue: events i915_hotplug_work_func [i915]
      [   62.518853] task: ffff88046c00dc00 task.stack: ffffc90000184000
      [   62.518896] RIP: 0010:i915_vma_pin_iomap+0x144/0x150 [i915]
      [   62.518919] RSP: 0018:ffffc90000187cc8 EFLAGS: 00010292
      [   62.518942] RAX: 000000000000002a RBX: ffff880460044000 RCX: 0000000000000006
      [   62.518969] RDX: 0000000000000006 RSI: ffffffff819c3e6f RDI: ffffffff819f1c0e
      [   62.518996] RBP: ffffc90000187cd8 R08: ffff88046c00e4f0 R09: 0000000000000000
      [   62.519022] R10: ffff8804669ca800 R11: 0000000000000000 R12: ffff880461d20000
      [   62.519049] R13: ffffc90000187d48 R14: ffff880461d20000 R15: ffff880460044000
      [   62.519076] FS:  0000000000000000(0000) GS:ffff88047ed80000(0000) knlGS:0000000000000000
      [   62.519107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   62.519130] CR2: 000056478ae213f0 CR3: 0000000002c0f000 CR4: 00000000003406e0
      [   62.519156] Call Trace:
      [   62.519190]  intelfb_create+0x176/0x360 [i915]
      [   62.519216]  __drm_fb_helper_initial_config_and_unlock+0x1c7/0x3c0 [drm_kms_helper]
      [   62.519251]  drm_fb_helper_hotplug_event.part.18+0xac/0xc0 [drm_kms_helper]
      [   62.519282]  drm_fb_helper_hotplug_event+0x1a/0x20 [drm_kms_helper]
      [   62.519324]  intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
      [   62.519352]  drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
      [   62.519395]  i915_hotplug_work_func+0x24e/0x2b0 [i915]
      [   62.519420]  process_one_work+0x1d3/0x6d0
      [   62.519440]  worker_thread+0x4b/0x400
      [   62.519458]  ? schedule+0x4a/0x90
      [   62.519475]  ? preempt_count_sub+0x97/0xf0
      [   62.519495]  kthread+0x114/0x150
      [   62.519511]  ? process_one_work+0x6d0/0x6d0
      [   62.519530]  ? kthread_create_on_node+0x40/0x40
      [   62.519551]  ret_from_fork+0x27/0x40
      [   62.519569] Code: c4 78 e6 e0 0f ff e9 08 ff ff ff 80 3d d5 bc 0c 00 00 0f 85 0b ff ff ff 48 c7 c7 d8 50 32 a0 c6 05 c1 bc 0c 00 01 e8 9d 78 e6 e0 <0f> ff e9 f1 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 0f b6 87 98
      [   62.519771] ---[ end trace 5fbe271f991a58ae ]---
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901195456.6386-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c6364232
    • Changbin Du's avatar
      drm/i915: Add interface to reserve fence registers for vGPU · 969b0950
      Changbin Du authored
      In the past, vGPU alloc fence registers by walking through mm.fence_list
      to find fence which pin_count = 0 and vma is empty. vGPU may not find
      enough fence registers this way. Because a fence can be bind to vma even
      though it is not in using. We have found such failure many times these
      days.
      
      An option to resolve this issue is that we can force-remove fence from
      vma in this case.
      
      This patch added two new api to the fence management code:
       - i915_reserve_fence() will try to find a free fence from fence_list
         and force-remove vma if need.
       - i915_unreserve_fence() reclaim a reserved fence after vGPU has
         finished.
      
      With this change, the fence management is more clear to work with vGPU.
      GVTg do not need remove fence from fence_list in private.
      
      v3: (Chris)
        - Add struct_mutex lock assertion.
        - Only count for unpinned fence.
      
      v2: (Chris)
        - Rename the new api for symmetry.
        - Add safeguard to ensure at least 1 fence remained for host display.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1504512061-5892-1-git-send-email-changbin.du@intel.comAcked-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      969b0950
    • Thierry Reding's avatar
      drm/i915: Use correct path to trace include · 4e6d7719
      Thierry Reding authored
      The header comment in include/trace/define_trace.h specifies that the
      TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
      rather than the trace file including it. Most instances get that wrong
      and work around it by adding the $(src) directory to the include path.
      
      While this works, it is preferable to refer to the correct path to the
      trace file in the first place and avoid any workaround.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901144954.19620-4-thierry.reding@gmail.com
      4e6d7719
  6. 02 Sep, 2017 1 commit
  7. 01 Sep, 2017 10 commits
  8. 31 Aug, 2017 3 commits