1. 20 Sep, 2018 13 commits
  2. 19 Sep, 2018 1 commit
  3. 18 Sep, 2018 6 commits
    • Rodrigo Vivi's avatar
      Merge tag 'gvt-fixes-2018-09-18' of https://github.com/intel/gvt-linux into drm-intel-fixes · a530bf94
      Rodrigo Vivi authored
      gvt-fixes-2018-09-18
      
      - Fix initial DPIO PHY register state for BXT (Colin)
      - BXT untracked GEN9_CLKGATE_DIS_4 warning fix (Colin)
      - Fix srcu lock for GFN valid check (Weinan)
      - Should clear GGTT entry value after vGPU destroy (Zhipeng)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      From: Zhenyu Wang <zhenyuw@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180918073349.GQ20737@zhen-hp.sh.intel.com
      a530bf94
    • Dave Airlie's avatar
      drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers. · 57078338
      Dave Airlie authored
      vgem seems to oops on the intel CI due to the vgem debugfs init
      hitting this path now.
      
      Check if we have mode_config funcs before checking one.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180918062018.24942-1-airlied@gmail.com
      57078338
    • 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: default 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: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: default 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: default 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: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      db7c8f1e
  4. 17 Sep, 2018 1 commit
  5. 16 Sep, 2018 2 commits
  6. 15 Sep, 2018 8 commits
  7. 14 Sep, 2018 9 commits