1. 21 Nov, 2018 1 commit
  2. 12 Nov, 2018 2 commits
    • Hang Yuan's avatar
      drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert · f3be657d
      Hang Yuan authored
      i915_gem_gtt_insert may evict some vmas and access HW if ggtt
      vm space is not enough. So add mmio_hw_access_pre before invoke
      i915_gem_gtt_insert to avoid call trace like below in vgpu create/
      destroy test.
      
      WARNING: CPU: 6 PID: 8720 at drivers/gpu/drm/i915/intel_drv.h:1768
      assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
      RPM wakelock ref not held during HW access
      
      Call Trace:
        [<ffffffff99af3b22>] dump_stack+0x19/0x1b
        [<ffffffff9948e338>] __warn+0xd8/0x100
        [<ffffffff9948e3bf>] warn_slowpath_fmt+0x5f/0x80
        [<ffffffffc0d5cc32>] assert_rpm_wakelock_held.part.2+0x27/0x30 [i915]
        [<ffffffffc0c7ffcf>] intel_runtime_pm_get_noresume+0x6f/0x80 [i915]
        [<ffffffffc0ca614d>] i915_gem_request_alloc+0x2dd/0x3c0 [i915]
        [<ffffffffc0c9056e>] i915_gem_switch_to_kernel_context+0xae/0x1d0 [i915]
        [<ffffffffc0c91572>] ggtt_flush+0x12/0x30 [i915]
        [<ffffffffc0c917ef>] i915_gem_evict_something+0x25f/0x470 [i915]
        [<ffffffffc0c9b62c>] i915_gem_gtt_insert+0x15c/0x1c0 [i915]
        [<ffffffffc0d35837>] alloc_gm+0xa7/0x160 [i915]
        [<ffffffffc0d35d8d>] intel_vgpu_alloc_resource+0x1ad/0x410 [i915]
        [<ffffffffc0d4819c>] intel_gvt_create_vgpu+0x16c/0x260 [i915]
        [<ffffffffc055d980>] intel_vgpu_create+0x50/0x140 [kvmgt]
        [<ffffffffc04fc6fa>] mdev_device_create+0x1aa/0x2e0 [mdev]
      
      v2: use mmio_hw_access_pre/post <Zhenyu>
      Signed-off-by: default avatarHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      f3be657d
    • Xinyun Liu's avatar
      drm/i915/gvt: not to touch undefined MOCS registers · def40774
      Xinyun Liu authored
      Some engines are not available for all Gens. eg, Gen11 introduced
      VCS3/VCS4/VECS2, and VCS2 is not supported on some Gen9 machines. So need to
      add check before access them.
      Signed-off-by: default avatarXinyun Liu <xinyun.liu@intel.com>
      Signed-off-by: Zhao Yakui's avatarYakui Zhao <Yakui.Zhao@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      def40774
  3. 06 Nov, 2018 1 commit
  4. 31 Oct, 2018 3 commits
  5. 08 Oct, 2018 1 commit
  6. 18 Sep, 2018 4 commits
    • Zhipeng Gong's avatar
      drm/i915/gvt: clear ggtt entries when destroy vgpu · 7759ca3a
      Zhipeng Gong authored
      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: default avatarZhipeng Gong <zhipeng.gong@intel.com>
      Reviewed-by: default avatarHang Yuan <hang.yuan@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      7759ca3a
    • Weinan Li's avatar
      drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid · a1ac5f09
      Weinan Li authored
      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: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      a1ac5f09
    • Colin Xu's avatar
      drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler · d817de3b
      Colin Xu authored
      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: default avatarHe, Min <min.he@intel.com>
      Signed-off-by: default avatarColin Xu <colin.xu@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      d817de3b
    • Colin Xu's avatar
      drm/i915/gvt: Init PHY related registers for BXT · db7c8f1e
      Colin Xu authored
      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: default avatarHe, Min <min.he@intel.com>
      Signed-off-by: default avatarColin Xu <colin.xu@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      db7c8f1e
  7. 06 Sep, 2018 1 commit
  8. 04 Sep, 2018 1 commit
    • Zhenyu Wang's avatar
      drm/i915/gvt: Fix life cycle reference on KVM mm · 0a1b60d7
      Zhenyu Wang authored
      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: default avatarZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      0a1b60d7
  9. 03 Sep, 2018 1 commit
    • Zhenyu Wang's avatar
      drm/i915/gvt: Give new born vGPU higher scheduling chance · 54ff01fd
      Zhenyu Wang authored
      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: default avatarHang Yuan <hang.yuan@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      54ff01fd
  10. 30 Aug, 2018 5 commits
    • Zhenyu Wang's avatar
      drm/i915/gvt: Fix drm_format_mod value for vGPU plane · b244ffa1
      Zhenyu Wang authored
      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: default avatarColin Xu <Colin.Xu@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      b244ffa1
    • Hang Yuan's avatar
      drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in stop_schedule · b2b599fb
      Hang Yuan authored
      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: default avatarHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      b2b599fb
    • Colin Xu's avatar
      drm/i915/gvt: Handle GEN9_WM_CHICKEN3 with F_CMD_ACCESS. · b9b824a5
      Colin Xu authored
      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: default avatarColin Xu <colin.xu@intel.com>
      Acked-by: default avatarZhao Yan <yan.y.zhao@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      b9b824a5
    • Colin Xu's avatar
      drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY · c8ab5ac3
      Colin Xu authored
      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: default avatarColin Xu <colin.xu@intel.com>
      Reviewed-by: default avatarHe, Min <min.he@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      c8ab5ac3
    • Xiaolin Zhang's avatar
      drm/i915/gvt: emulate gen9 dbuf ctl register access · 9174c1d6
      Xiaolin Zhang authored
      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: default avatarXiaolin Zhang <xiaolin.zhang@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      9174c1d6
  11. 16 Aug, 2018 2 commits
  12. 14 Aug, 2018 6 commits
    • Yi Wang's avatar
      drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() · 7590ebb8
      Yi Wang authored
      The 'sparse' variable may leak when return in function
      intel_vgpu_ioctl(), and this patch fix this.
      Signed-off-by: default avatarYi Wang <wang.yi59@zte.com.cn>
      Reviewed-by: default avatarJiang Biao <jiang.biao2@zte.com.cn>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      7590ebb8
    • Dan Carpenter's avatar
      drm/i915/gvt: Off by one in intel_vgpu_write_fence() · 4b25e737
      Dan Carpenter authored
      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: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      4b25e737
    • Gustavo A. R. Silva's avatar
      drm/i915/kvmgt: Fix potential Spectre v1 · de5372da
      Gustavo A. R. Silva authored
      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: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      de5372da
    • Zhao Yan's avatar
      drm/i915/gvt: return error on cmd access · 8d458ea0
      Zhao Yan authored
      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: default avatarZhao Yan <yan.y.zhao@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      8d458ea0
    • Hang Yuan's avatar
      drm/i915/gvt: initialize dmabuf mutex in vgpu_create · d6c6113b
      Hang Yuan authored
      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: default avatarHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      d6c6113b
    • Hang Yuan's avatar
      drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_device · 3fd34ac0
      Hang Yuan authored
      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: default avatarHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      3fd34ac0
  13. 13 Aug, 2018 1 commit
  14. 08 Aug, 2018 1 commit
    • Imre Deak's avatar
      drm/i915/ddi: Use power well CTL IDX instead of ID · 75e39688
      Imre Deak authored
      Similarly to the previous patch use a separate request/status HW flag
      index defined right after the corresponding control registers instead of
      depending for this on the power well IDs. Since the set of
      control/status registers varies among the different power wells (on a
      single platform), also add a new i915_power_well_registers struct that
      we populate and assign to each DDI power well as needed.
      
      Also clarify a bit the code comment describing the function and layout
      of the control registers.
      
      This also fixes a problem on ICL, where we incorrectly read the KVMR
      control register in hsw_power_well_requesters() even for DDI and AUX
      power wells.
      
      v2:
      - Clarify platform range tags in code comments. (Paulo)
      - Fix line over 80 chars checkpatch warning.
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: Imre Deak's avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: Paulo Zanoni's avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
      75e39688
  15. 07 Aug, 2018 4 commits
  16. 06 Aug, 2018 1 commit
  17. 02 Aug, 2018 2 commits
  18. 23 Jul, 2018 1 commit
  19. 10 Jul, 2018 1 commit
  20. 09 Jul, 2018 1 commit
    • Colin Xu's avatar
      drm/i915/gvt: Handle EDP_PSR_IMR and EDP_PSR_IIR for BXT. · 93d68b25
      Colin Xu authored
      BXT supports EDP. However since GVT-g only simulate DP monitor
      to guest and handles EDP_PSR_IMR and EDP_PSR_IIR as default MMIO
      r/w. If guest r/w these IMR/IIR, GVT-g won't simulate the real
      HW behavior and below warning is printed:
      --------
      Interrupt register 0x64838 is not zero: 0xffffffff
      WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:161
      gen3_assert_iir_is_zero+0x34/0xa0
      
      Call Trace:
      gen8_de_irq_postinstall+0xad/0x330
      gen8_irq_postinstall+0x23/0x80
      drm_irq_install+0xb5/0x130
      i915_driver_load+0xafd/0xf70
      --------
      Since GVT-g won't simulate EDP to guest, always set EDP_PSR_IMR
      and EDP_PSR_IIR IMR/IIR to 0.
      Signed-off-by: default avatarColin Xu <colin.xu@intel.com>
      Signed-off-by: Zhenyu Wang's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      93d68b25