1. 13 Jul, 2018 2 commits
  2. 12 Jul, 2018 8 commits
  3. 11 Jul, 2018 3 commits
  4. 10 Jul, 2018 11 commits
  5. 09 Jul, 2018 16 commits
    • Rodrigo Vivi's avatar
      82edc7e8
    • Chris Wilson's avatar
      drm/i915/selftests: Prevent background reaping of active objects · 932cac10
      Chris Wilson authored
      igt_mmap_offset_exhaustion() wants to test what happens when the mmap
      space is filled with zombie objects, objects discarded by userspace but
      still active on the GPU. As they are only protected by the active
      reference, we have to be certain that active reference is kept while we
      peek into our dangling pointer. That active reference should not be
      freed until we retire, but we do that retirement from a background
      thread. This leaves us with a subtle timing problem, exacerbated and
      highlighted by KASAN:
      
      <3>[  132.380399] BUG: KASAN: use-after-free in drm_gem_create_mmap_offset+0x8c/0xd0
      <3>[  132.380430] Read of size 8 at addr ffff8801e13245f8 by task drv_selftest/5822
      
      <4>[  132.380470] CPU: 0 PID: 5822 Comm: drv_selftest Tainted: G     U            4.18.0-rc3-g7ae7763aa2be-kasan_48+ #1
      <4>[  132.380473] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
      <4>[  132.380475] Call Trace:
      <4>[  132.380481]  dump_stack+0x7c/0xbb
      <4>[  132.380487]  print_address_description+0x65/0x270
      <4>[  132.380493]  kasan_report+0x25b/0x380
      <4>[  132.380497]  ? drm_gem_create_mmap_offset+0x8c/0xd0
      <4>[  132.380503]  drm_gem_create_mmap_offset+0x8c/0xd0
      <4>[  132.380584]  i915_gem_object_create_mmap_offset+0x6d/0x100 [i915]
      <4>[  132.380650]  igt_mmap_offset_exhaustion+0x462/0x940 [i915]
      <4>[  132.380714]  ? i915_gem_close_object+0x740/0x740 [i915]
      <4>[  132.380784]  ? igt_gem_huge+0x269/0x3d0 [i915]
      <4>[  132.380865]  __i915_subtests+0x5a/0x160 [i915]
      <4>[  132.380936]  __run_selftests+0x1a2/0x2f0 [i915]
      <4>[  132.381008]  i915_live_selftests+0x4e/0x80 [i915]
      <4>[  132.381071]  i915_pci_probe+0xd8/0x1b0 [i915]
      <4>[  132.381077]  pci_device_probe+0x1c5/0x3a0
      <4>[  132.381087]  driver_probe_device+0x6b6/0xcb0
      <4>[  132.381094]  __driver_attach+0x22d/0x2c0
      <4>[  132.381100]  ? driver_probe_device+0xcb0/0xcb0
      <4>[  132.381103]  bus_for_each_dev+0x113/0x1a0
      <4>[  132.381108]  ? check_flags.part.24+0x450/0x450
      <4>[  132.381112]  ? subsys_dev_iter_exit+0x10/0x10
      <4>[  132.381123]  bus_add_driver+0x38b/0x6e0
      <4>[  132.381131]  driver_register+0x189/0x400
      <4>[  132.381136]  ? 0xffffffffc12d8000
      <4>[  132.381140]  do_one_initcall+0xa0/0x4c0
      <4>[  132.381145]  ? initcall_blacklisted+0x180/0x180
      <4>[  132.381152]  ? do_init_module+0x4a/0x54c
      <4>[  132.381156]  ? rcu_lockdep_current_cpu_online+0xdc/0x130
      <4>[  132.381161]  ? kasan_unpoison_shadow+0x30/0x40
      <4>[  132.381169]  do_init_module+0x1b5/0x54c
      <4>[  132.381177]  load_module+0x619e/0x9b70
      <4>[  132.381202]  ? module_frob_arch_sections+0x20/0x20
      <4>[  132.381211]  ? vfs_read+0x257/0x2f0
      <4>[  132.381214]  ? vfs_read+0x257/0x2f0
      <4>[  132.381221]  ? kernel_read+0x8b/0x130
      <4>[  132.381231]  ? copy_strings_kernel+0x120/0x120
      <4>[  132.381244]  ? __se_sys_finit_module+0x17c/0x1a0
      <4>[  132.381248]  __se_sys_finit_module+0x17c/0x1a0
      <4>[  132.381252]  ? __ia32_sys_init_module+0xa0/0xa0
      <4>[  132.381261]  ? __se_sys_newstat+0x77/0xd0
      <4>[  132.381265]  ? cp_new_stat+0x590/0x590
      <4>[  132.381269]  ? kmem_cache_free+0x2f0/0x340
      <4>[  132.381285]  do_syscall_64+0x97/0x400
      <4>[  132.381292]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  132.381295] RIP: 0033:0x7eff4af46839
      <4>[  132.381297] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
      <4>[  132.381426] RSP: 002b:00007ffcd84f4cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      <4>[  132.381432] RAX: ffffffffffffffda RBX: 000055dfdeb429a0 RCX: 00007eff4af46839
      <4>[  132.381435] RDX: 0000000000000000 RSI: 000055dfdeb43670 RDI: 0000000000000004
      <4>[  132.381437] RBP: 000055dfdeb43670 R08: 0000000000000004 R09: 0000000000000000
      <4>[  132.381440] R10: 00007ffcd84f4e60 R11: 0000000000000246 R12: 0000000000000000
      <4>[  132.381442] R13: 000055dfdeb3bec0 R14: 0000000000000000 R15: 000000000000003b
      
      <3>[  132.381466] Allocated by task 5822:
      <4>[  132.381485]  kmem_cache_alloc+0xdf/0x2e0
      <4>[  132.381546]  i915_gem_object_create_internal+0x24/0x1e0 [i915]
      <4>[  132.381609]  igt_mmap_offset_exhaustion+0x257/0x940 [i915]
      <4>[  132.381677]  __i915_subtests+0x5a/0x160 [i915]
      <4>[  132.381742]  __run_selftests+0x1a2/0x2f0 [i915]
      <4>[  132.381806]  i915_live_selftests+0x4e/0x80 [i915]
      <4>[  132.381865]  i915_pci_probe+0xd8/0x1b0 [i915]
      <4>[  132.381868]  pci_device_probe+0x1c5/0x3a0
      <4>[  132.381871]  driver_probe_device+0x6b6/0xcb0
      <4>[  132.381874]  __driver_attach+0x22d/0x2c0
      <4>[  132.381877]  bus_for_each_dev+0x113/0x1a0
      <4>[  132.381880]  bus_add_driver+0x38b/0x6e0
      <4>[  132.381884]  driver_register+0x189/0x400
      <4>[  132.381886]  do_one_initcall+0xa0/0x4c0
      <4>[  132.381889]  do_init_module+0x1b5/0x54c
      <4>[  132.381892]  load_module+0x619e/0x9b70
      <4>[  132.381895]  __se_sys_finit_module+0x17c/0x1a0
      <4>[  132.381898]  do_syscall_64+0x97/0x400
      <4>[  132.381901]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      <3>[  132.381914] Freed by task 150:
      <4>[  132.381931]  kmem_cache_free+0xb7/0x340
      <4>[  132.381995]  __i915_gem_free_objects+0x875/0xf50 [i915]
      <4>[  132.382054]  __i915_gem_free_work+0x69/0xb0 [i915]
      <4>[  132.382058]  process_one_work+0x78b/0x1740
      <4>[  132.382061]  worker_thread+0x82/0xb80
      <4>[  132.382064]  kthread+0x30c/0x3d0
      <4>[  132.382067]  ret_from_fork+0x3a/0x50
      
      <3>[  132.382081] The buggy address belongs to the object at ffff8801e1324500
                         which belongs to the cache drm_i915_gem_object of size 1168
      <3>[  132.382133] The buggy address is located 248 bytes inside of
                         1168-byte region [ffff8801e1324500, ffff8801e1324990)
      <3>[  132.382179] The buggy address belongs to the page:
      <0>[  132.382202] page:ffffea000784c800 count:1 mapcount:0 mapping:ffff8801dedf6500 index:0xffff8801e1323ec0 compound_mapcount: 0
      <0>[  132.382251] flags: 0x8000000000008100(slab|head)
      <1>[  132.382274] raw: 8000000000008100 ffff8801d6317440 ffff8801d6317440 ffff8801dedf6500
      <1>[  132.382307] raw: ffff8801e1323ec0 0000000000140013 00000001ffffffff 0000000000000000
      <1>[  132.382339] page dumped because: kasan: bad access detected
      
      <3>[  132.382373] Memory state around the buggy address:
      <3>[  132.382395]  ffff8801e1324480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      <3>[  132.382426]  ffff8801e1324500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      <3>[  132.382457] >ffff8801e1324580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      <3>[  132.382488]                                                                 ^
      <3>[  132.382517]  ffff8801e1324600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      <3>[  132.382548]  ffff8801e1324680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      This patch tricks the system into running without the background retire
      thread, until after we finish the test. The only reaping should then be
      performed by the mmap offset routine to reclaim the space as required.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709130208.11730-1-chris@chris-wilson.co.uk
      932cac10
    • Chris Wilson's avatar
      drm/i915/selftests: Replace wait-on-timeout with explicit timeout · d9a13ce3
      Chris Wilson authored
      In igt_flush_test() we install a background timer in order to ensure
      that the wait completes within a certain time. We can now tell the wait
      that it has to complete within a timeout, and so no longer need the
      background timer.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709122044.7028-3-chris@chris-wilson.co.uk
      d9a13ce3
    • Chris Wilson's avatar
      drm/i915: Provide a timeout to i915_gem_wait_for_idle() on setup · 2621cefa
      Chris Wilson authored
      With a broken GPU we expect it to fail during the initial
      GPU setup where do a couple of context switches to record the defaults.
      This is a task that takes a few milliseconds even on the slowest of
      devices, but we may have to wait 60s for hangcheck to give in and
      declare the machine inoperable. In this a case where any gpu hang is
      unacceptable, both from a timeliness and practical standpoint.
      
      We can therefore set a timeout on our wait-for-idle that is shorter than
      the hangcheck (which may be up to 60s for a declaring a wedged driver)
      and so detect the broken GPU much more quickly during driver load (and
      so prevent stalling userspace for ages).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709122044.7028-2-chris@chris-wilson.co.uk
      2621cefa
    • Chris Wilson's avatar
      drm/i915: Provide a timeout to i915_gem_wait_for_idle() · ec625fb9
      Chris Wilson authored
      Usually we have no idea about the upper bound we need to wait to catch
      up with userspace when idling the device, but in a few situations we
      know the system was idle beforehand and can provide a short timeout in
      order to very quickly catch a failure, long before hangcheck kicks in.
      
      In the following patches, we will use the timeout to curtain two overly
      long waits, where we know we can expect the GPU to complete within a
      reasonable time or declare it broken.
      
      In particular, with a broken GPU we expect it to fail during the initial
      GPU setup where do a couple of context switches to record the defaults.
      This is a task that takes a few milliseconds even on the slowest of
      devices, but we may have to wait 60s for hangcheck to give in and
      declare the machine inoperable. In this a case where any gpu hang is
      unacceptable, both from a timeliness and practical standpoint.
      
      The other improvement is that in selftests, we do not need to arm an
      independent timer to inject a wedge, as we can just limit the timeout on
      the wait directly.
      
      v2: Include the timeout parameter in the trace.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709122044.7028-1-chris@chris-wilson.co.uk
      ec625fb9
    • Chris Wilson's avatar
      drm/i915/selftests: Magic numbers for old Y-tiling · e1479132
      Chris Wilson authored
      i915g has a slightly different tiling layout, and so requires a
      different reference swizzle pattern.
      
      Testcase: igt/drv_selftests/live_objects #gdg
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180707100405.817-1-chris@chris-wilson.co.uk
      e1479132
    • 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: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      93d68b25
    • Changbin Du's avatar
      drm/i915: Enable platform support for vGPU huge gtt pages · aa36ed6d
      Changbin Du authored
      Now GVTg supports shadowing both 2M/64K huge gtt pages. So let's turn on
      the cap info bit VGT_CAPS_HUGE_GTT.
      
      v2: Split changes in i915 side into a separated patch.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      aa36ed6d
    • Changbin Du's avatar
      drm/i915/gvt: Fix error handling in ppgtt_populate_spt_by_guest_entry · 80e76ea6
      Changbin Du authored
      Don't forget to free allocated spt if shadowing failed.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      80e76ea6
    • Changbin Du's avatar
      drm/i915/gvt: Handle special sequence on PDE IPS bit · 54c81653
      Changbin Du authored
      If the guest update the 64K gtt entry before changing IPS bit of PDE, we
      need to re-shadow the whole page table. Because we have ignored all
      updates to unused entries.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      54c81653
    • Changbin Du's avatar
      drm/i915/gvt: Add 2M huge gtt support · b901b252
      Changbin Du authored
      This add 2M huge gtt support for GVTg. Unlike 64K gtt entry, we can
      shadow 2M guest entry with real huge gtt. But before that, we have to
      check memory physical continuous, alignment and if it is supported on
      the host. We can get all supported page sizes from
      intel_device_info.page_sizes.
      
      Finally we must split the 2M page into smaller pages if we cannot
      satisfy guest Huge Page.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      b901b252
    • Changbin Du's avatar
      drm/i915/kvmgt: Support setting dma map for huge pages · 79e542f5
      Changbin Du authored
      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: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      79e542f5
    • Changbin Du's avatar
      drm/i915/gvt: Add 64K huge gtt support · eb3a3530
      Changbin Du authored
      Finally, this add the first huge gtt support for GVTg - 64K pages. Since
      64K page and 4K page cannot be mixed on the same page table, so we always
      split a 64K entry into small 4K page. And when unshadow guest 64K entry,
      we need ensure all the shadowed entries in shadow page table also get
      cleared.
      
      For page table which has 64K gtt entry, only PTE#0, PTE#16, PTE#32, ...
      PTE#496 are used. Unused PTEs update should be ignored.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      eb3a3530
    • Changbin Du's avatar
      drm/i915/gvt: Make PTE iterator 64K entry aware · 4c9414d7
      Changbin Du authored
      64K PTE is special, only PTE#0, PTE#16, PTE#32, ... PTE#496 are used in
      the page table.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      4c9414d7
    • Changbin Du's avatar
      drm/i915/gvt: Split ppgtt_alloc_spt into two parts · 155521c9
      Changbin Du authored
      We need a interface to allocate a pure shadow page which doesn't have
      a guest page associated with. Such shadow page is used to shadow 2M
      huge gtt entry.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      155521c9
    • Changbin Du's avatar
      drm/i915/gvt: Add GTT clear_pse operation · c3e69763
      Changbin Du authored
      Add clear_pse operation in case we need to split huge gtt into small pages.
      
      v2: correct description.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      c3e69763