1. 20 3月, 2018 1 次提交
  2. 15 3月, 2018 2 次提交
    • Z
      drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field · 850555d1
      Zhenyu Wang 提交于
      This is to fix warning got as:
      
      [ 6730.476938] ------------[ cut here ]------------
      [ 6730.476979] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'gvt-g_vgpu_workload' (offset 120, size 4)!
      [ 6730.477021] WARNING: CPU: 2 PID: 441 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
      [ 6730.477042] Modules linked in: tun(E) bridge(E) stp(E) llc(E) kvmgt(E) x86_pkg_temp_thermal(E) vfio_mdev(E) intel_powerclamp(E) mdev(E) coretemp(E) vfio_iommu_type1(E) vfio(E) kvm_intel(E) kvm(E) hid_generic(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) usbhid(E) i915(E) crc32c_intel(E) hid(E) ghash_clmulni_intel(E) pcbc(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) intel_cstate(E) idma64(E) evdev(E) virt_dma(E) iTCO_wdt(E) intel_uncore(E) intel_rapl_perf(E) intel_lpss_pci(E) sg(E) shpchp(E) mei_me(E) pcspkr(E) iTCO_vendor_support(E) intel_lpss(E) intel_pch_thermal(E) prime_numbers(E) mei(E) mfd_core(E) video(E) acpi_pad(E) button(E) binfmt_misc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) e1000e(E) xhci_pci(E) sdhci_pci(E)
      [ 6730.477244]  ptp(E) cqhci(E) xhci_hcd(E) pps_core(E) sdhci(E) mmc_core(E) i2c_i801(E) usbcore(E) thermal(E) fan(E)
      [ 6730.477276] CPU: 2 PID: 441 Comm: gvt workload 0 Tainted: G            E    4.16.0-rc1-gvt-staging-0213+ #127
      [ 6730.477303] Hardware name:  /NUC6i5SYB, BIOS SYSKLi35.86A.0039.2016.0316.1747 03/16/2016
      [ 6730.477326] RIP: 0010:usercopy_warn+0x7e/0xa0
      [ 6730.477340] RSP: 0018:ffffba6301223d18 EFLAGS: 00010286
      [ 6730.477355] RAX: 0000000000000000 RBX: ffff8f41caae9838 RCX: 0000000000000006
      [ 6730.477375] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8f41dad166f0
      [ 6730.477395] RBP: 0000000000000004 R08: 0000000000000576 R09: 0000000000000000
      [ 6730.477415] R10: ffffffffb1293fb2 R11: 00000000ffffffff R12: 0000000000000001
      [ 6730.477447] R13: ffff8f41caae983c R14: ffff8f41caae9838 R15: 00007f183ca2b000
      [ 6730.477467] FS:  0000000000000000(0000) GS:ffff8f41dad00000(0000) knlGS:0000000000000000
      [ 6730.477489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 6730.477506] CR2: 0000559462817291 CR3: 000000028b46c006 CR4: 00000000003626e0
      [ 6730.477526] Call Trace:
      [ 6730.477537]  __check_object_size+0x9c/0x1a0
      [ 6730.477562]  __kvm_write_guest_page+0x45/0x90 [kvm]
      [ 6730.477585]  kvm_write_guest+0x46/0x80 [kvm]
      [ 6730.477599]  kvmgt_rw_gpa+0x9b/0xf0 [kvmgt]
      [ 6730.477642]  workload_thread+0xa38/0x1040 [i915]
      [ 6730.477659]  ? do_wait_intr_irq+0xc0/0xc0
      [ 6730.477673]  ? finish_wait+0x80/0x80
      [ 6730.477707]  ? clean_workloads+0x120/0x120 [i915]
      [ 6730.477722]  kthread+0x111/0x130
      [ 6730.477733]  ? _kthread_create_worker_on_cpu+0x60/0x60
      [ 6730.477750]  ? exit_to_usermode_loop+0x6f/0xb0
      [ 6730.477766]  ret_from_fork+0x35/0x40
      [ 6730.477777] Code: 48 c7 c0 20 e3 25 b1 48 0f 44 c2 41 50 51 41 51 48 89 f9 49 89 f1 4d 89 d8 4c 89 d2 48 89 c6 48 c7 c7 78 e3 25 b1 e8 b2 bc e4 ff <0f> ff 48 83 c4 18 c3 48 c7 c6 09 d0 26 b1 49 89 f1 49 89 f3 eb
      [ 6730.477849] ---[ end trace cae869c1c323e45a ]---
      
      By whitelist guest page write from workload struct allocated from kmem cache.
      Reviewed-by: NHang Yuan <hang.yuan@linux.intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      (cherry picked from commit 5627705406874df57fdfad3b4e0c9aedd3b007df)
      850555d1
    • F
      drm/i915/gvt: Correct the privilege shadow batch buffer address · ef75c685
      fred gao 提交于
      Once the ring buffer is copied to ring_scan_buffer and scanned,
      the shadow batch buffer start address is only updated into
      ring_scan_buffer, not the real ring address allocated through
      intel_ring_begin in later copy_workload_to_ring_buffer.
      
      This patch is only to set the right shadow batch buffer address
      from Ring buffer, not include the shadow_wa_ctx.
      
      v2:
      - refine some comments. (Zhenyu)
      v3:
      - fix typo in title. (Zhenyu)
      v4:
      - remove the unnecessary comments. (Zhenyu)
      - add comments in bb_start_cmd_va update. (Zhenyu)
      
      Fixes: 0a53bc07 ("drm/i915/gvt: Separate cmd scan from request allocation")
      Cc: stable@vger.kernel.org  # v4.15
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Yulei Zhang <yulei.zhang@intel.com>
      Signed-off-by: Nfred gao <fred.gao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      ef75c685
  3. 13 3月, 2018 3 次提交
  4. 09 3月, 2018 2 次提交
    • M
      drm/i915/gvt: keep oa config in shadow ctx · fa3dd623
      Min He 提交于
      When populating shadow ctx from guest, we should handle oa related
      registers in hw ctx, so that they will not be overlapped by guest oa
      configs. This patch made it possible to capture oa data from host for
      both host and guests.
      Signed-off-by: NMin He <min.he@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      fa3dd623
    • X
      drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio · b24881e0
      Xiong Zhang 提交于
      If user continuously create vgpu, boot guest, shoutdown guest and destroy
      vgpu from remote, the following calltrace exists in dmesg sometimes:
      [ 6412.954721] RPM wakelock ref not held during HW access
      [ 6412.954795] WARNING: CPU: 7 PID: 11941 at
      linux/drivers/gpu/drm/i915/intel_drv.h:1800
      intel_uncore_forcewake_get.part.7+0x96/0xa0 [i915]
      [ 6412.954915] Call Trace:
      [ 6412.954951] intel_uncore_forcewake_get+0x18/0x20 [i915]
      [ 6412.954989] intel_gvt_switch_mmio+0x8e/0x770 [i915]
      [ 6412.954996] ? __slab_free+0x14d/0x2c0
      [ 6412.955001] ? __slab_free+0x14d/0x2c0
      [ 6412.955006] ? __slab_free+0x14d/0x2c0
      [ 6412.955041] intel_vgpu_stop_schedule+0x92/0xd0 [i915]
      [ 6412.955073] intel_gvt_deactivate_vgpu+0x48/0x60 [i915]
      [ 6412.955078] __intel_vgpu_release+0x55/0x260 [kvmgt]
      
      when this happens, gvt_switch_mmio is called at vgpu destroy, host i915 is
      idle and doesn't hold RPM wakelock, igd is in powersave mode, but
      gvt_switch_mmio require igd power on to access register, so
      intel_runtime_pm_get should be added to make sure igd power on before
      gvt_switch_mmio.
      
      v2: Move runtime_pm_get/put into gvt_switch_mmio.(Zhenyu)
      Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      b24881e0
  5. 06 3月, 2018 2 次提交
    • C
      drm/i915: Suspend submission tasklets around wedging · 88d3dfb6
      Chris Wilson 提交于
      After staring hard at sequences like
      
      [   28.199013]  systemd-1       2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
      [   28.199095]  systemd-1       2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1
      [   28.199177]  systemd-1       2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
      [   28.199258]  systemd-1       2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0
      [   28.199340]  gem_eio-829     1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
      [   28.199421]   <idle>-0       2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
      [   28.199503]   <idle>-0       2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1
      [   28.199585]  gem_eio-829     1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
      [   28.199667]  gem_eio-829     1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
      [   28.199749]   <idle>-0       2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
      [   28.199830]   <idle>-0       2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1
      [   28.199912]   <idle>-0       2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
      [   28.199994]  gem_eio-829     2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
      [   28.200096]  gem_eio-829     2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5
      [   28.200178]  gem_eio-829     2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
      [   28.200260]  gem_eio-829     2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
      
      the conclusion is that the only place where the ports are reset to zero,
      is from engine->cancel_requests called during i915_gem_set_wedged().
      
      The race is horrible as it results from calling set-wedged on active HW
      (the GPU reset failed) and as such we need to be careful as the HW state
      changes beneath us. Fortunately, it's the same scary conditions as
      affect normal reset, so we can reuse the same machinery to disable state
      tracking as we clobber it.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Fixes: af7a8ffa ("drm/i915: Use rcu instead of stop_machine in set_wedged")
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
      (cherry picked from commit 963ddd63)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      88d3dfb6
    • L
      drm/i915/perf: fix perf stream opening lock · f616f283
      Lionel Landwerlin 提交于
      We're seeing on CI that some contexts don't have the programmed OA
      period timer that directs the OA unit on how often to write reports.
      
      The issue is that we're not holding the drm lock from when we edit the
      context images down to when we set the exclusive_stream variable. This
      leaves a window for the deferred context allocation to call
      i915_oa_init_reg_state() that will not program the expected OA timer
      value, because we haven't set the exclusive_stream yet.
      
      v2: Drop need_lock from gen8_configure_all_contexts() (Matt)
      Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Fixes: 701f8231 ("drm/i915/perf: prune OA configs")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
      Link: https://patchwork.freedesktop.org/patch/msgid/20180301110613.1737-1-lionel.g.landwerlin@intel.com
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v4.14+
      (cherry picked from commit 41d3fdcd)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      f616f283
  6. 01 3月, 2018 5 次提交
  7. 15 2月, 2018 4 次提交
  8. 14 2月, 2018 8 次提交
  9. 13 2月, 2018 4 次提交
  10. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      Linus Torvalds 提交于
      This is the mindless scripted replacement of kernel use of POLL*
      variables as described by Al, done by this script:
      
          for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
              L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
              for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
          done
      
      with de-mangling cleanups yet to come.
      
      NOTE! On almost all architectures, the EPOLL* constants have the same
      values as the POLL* constants do.  But they keyword here is "almost".
      For various bad reasons they aren't the same, and epoll() doesn't
      actually work quite correctly in some cases due to this on Sparc et al.
      
      The next patch from Al will sort out the final differences, and we
      should be all done.
      Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  11. 08 2月, 2018 1 次提交
  12. 07 2月, 2018 7 次提交