History log of /linux-master/drivers/gpu/drm/i915/gvt/page_track.c
Revision Date Author Comments
# 3cca6b26 28-Jul-2023 Sean Christopherson <seanjc@google.com>

drm/i915/gvt: Protect gfn hash table with vgpu_lock

Use vgpu_lock instead of KVM's mmu_lock to protect accesses to the hash
table used to track which gfns are write-protected when shadowing the
guest's GTT, and hoist the acquisition of vgpu_lock from
intel_vgpu_page_track_handler() out to its sole caller,
kvmgt_page_track_write().

This fixes a bug where kvmgt_page_track_write(), which doesn't hold
kvm->mmu_lock, could race with intel_gvt_page_track_remove() and trigger
a use-after-free.

Fixing kvmgt_page_track_write() by taking kvm->mmu_lock is not an option
as mmu_lock is a r/w spinlock, and intel_vgpu_page_track_handler() might
sleep when acquiring vgpu->cache_lock deep down the callstack:

intel_vgpu_page_track_handler()
|
|-> page_track->handler / ppgtt_write_protection_handler()
|
|-> ppgtt_handle_guest_write_page_table_bytes()
|
|-> ppgtt_handle_guest_write_page_table()
|
|-> ppgtt_handle_guest_entry_removal()
|
|-> ppgtt_invalidate_pte()
|
|-> intel_gvt_dma_unmap_guest_page()
|
|-> mutex_lock(&vgpu->cache_lock);

Reviewed-by: Yan Zhao <yan.y.zhao@intel.com>
Tested-by: Yongwei Ma <yongwei.ma@intel.com>
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
Link: https://lore.kernel.org/r/20230729013535.1070024-12-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


# df947eb6 13-Jul-2022 Mauro Carvalho Chehab <mchehab@kernel.org>

drm/i915: gvt: fix kernel-doc trivial warnings

Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.

Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype for inte_gvt_free_vgpu_resource(). Prototype was for intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting prototype for intel_alloc_vgpu_resource(). Prototype was for intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype for intel_vgpu_emulate_cfg_read(). Prototype was for intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype for intel_t_default_mmio_write(). Prototype was for intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting prototype for intel_gvt_switch_render_mmio(). Prototype was for intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype for intel_vgpu_enable_page_track(). Prototype was for intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() instead

Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/375c0c0ca2ef414f25e14f274457f77373a9268d.1657699522.git.mchehab@kernel.org
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>


# 4c2baaaf7 11-Apr-2022 Christoph Hellwig <hch@lst.de>

drm/i915/gvt: devirtualize ->{enable,disable}_page_track

Just call the kvmgt functions directly.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220411141403.86980-21-hch@lst.de
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>


# a752b070 30-Jul-2018 Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Fix function comment doc errors

Caught by W=1 to fix left wrong function comment doc.

Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>


# f25a49ab 18-May-2018 Colin Xu <colin.xu@intel.com>

drm/i915/gvt: Use vgpu_lock to protect per vgpu access

The patch set splits out 2 small locks from the original big gvt lock:
- vgpu_lock protects per-vGPU data and logic, especially the vGPU
trap emulation path.
- sched_lock protects gvt scheudler structure, context schedule logic
and vGPU's schedule data.

Use vgpu_lock to replace the gvt big lock. By doing this, the
mmio read/write trap path, vgpu virtual event emulation and other
vgpu related process, would be protected under per vgpu_lock.

v9:
- Change commit author since the patches are improved a lot compared
with original version.
Original author: Pei Zhang <pei.zhang@intel.com>
- Rebase to latest gvt-staging.
v8:
- Correct coding and comment style.
- Rebase to latest gvt-staging.
v7:
- Remove gtt_lock since already proteced by gvt_lock and vgpu_lock.
- Fix a typo in intel_gvt_deactivate_vgpu, unlock the wrong lock.
v6:
- Rebase to latest gvt-staging.
v5:
- Rebase to latest gvt-staging.
- intel_vgpu_page_track_handler should use vgpu_lock.
v4:
- Rebase to latest gvt-staging.
- Protect vgpu->active access with vgpu_lock.
- Do not wait gpu idle in vgpu_lock.
v3: update to latest code base
v2: add gvt->lock in function gvt_check_vblank_emulation

Performance comparison on Kabylake platform.
- Configuration:
Host: Ubuntu 16.04.
Guest 1 & 2: Ubuntu 16.04.

glmark2 score comparison:
- Configuration:
Host: glxgears.
Guests: glmark2.
+--------------------------------+-----------------+
| Setup | glmark2 score |
+--------------------------------+-----------------+
| unified lock, iommu=on | 58~62 (avg. 60) |
+--------------------------------+-----------------+
| unified lock, iommu=igfx_off | 57~61 (avg. 59) |
+--------------------------------+-----------------+
| per-logic lock, iommu=on | 60~68 (avg. 64) |
+--------------------------------+-----------------+
| per-logic lock, iommu=igfx_off | 61~67 (avg. 64) |
+--------------------------------+-----------------+

lock_stat comparison:
- Configuration:
Stop lock stat immediately after boot up.
Boot 2 VM Guests.
Run glmark2 in guests.
Start perf lock_stat for 20 seconds and stop again.
- Legend: c - contentions; w - waittime-avg
+------------+-----------------+-----------+---------------+------------+
| | gvt_lock |sched_lock | vgpu_lock | gtt_lock |
+ lock type; +-----------------+-----------+---------------+------------+
| iommu set | c | w | c | w | c | w | c | w |
+------------+-------+---------+----+------+------+--------+-----+------+
| unified; | 20697 | 839 |N/A | N/A | N/A | N/A | N/A | N/A |
| on | | | | | | | | |
+------------+-------+---------+----+------+------+--------+-----+------+
| unified; | 21838 | 658.15 |N/A | N/A | N/A | N/A | N/A | N/A |
| igfx_off | | | | | | | | |
+------------+-------+---------+----+------+------+--------+-----+------+
| per-logic; | 1553 | 1599.96 |9458|429.97| 5846 | 274.33 | 0 | 0.00 |
| on | | | | | | | | |
+------------+-------+---------+----+------+------+--------+-----+------+
| per-logic; | 1911 | 1678.32 |8335|445.16| 5451 | 244.80 | 0 | 0.00 |
| igfx_off | | | | | | | | |
+------------+-------+---------+----+------+------+--------+-----+------+

Signed-off-by: Pei Zhang <pei.zhang@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>


# 991ecefb 05-Mar-2018 Xiong Zhang <xiong.y.zhang@intel.com>

drm/i915/gvt: Return error at the failure of finding page_track

In XenGT, ioreq copy is used to trap mmio write and ppgtt write. Both
of them are memory write, ioreq handler couldn't distinguish them. So
ioreq handler probe the ppgtt write handler, if it is succuess, this
ioreq is ppgtt write, otherwise it is mmio write.

So ppgtt write handler should return an error at the failure of finding
page track, it is fatal to implement ioreq handler in XenGT.

Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>


# 7e60946f 05-Mar-2018 Xiong Zhang <xiong.y.zhang@intel.com>

drm/i915/gvt: Release gvt->lock at the failure of finding page track

page_track_handler take lock at the beginning, the lock should be released
at the failure of finding page track. Otherwise deadlock will happen.

Fixes: e502a2af4c35 ("drm/i915/gvt: Provide generic page_track infrastructure for write-protected page")
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>


# e502a2af 30-Jan-2018 Changbin Du <changbin.du@intel.com>

drm/i915/gvt: Provide generic page_track infrastructure for write-protected page

This patch provide generic page_track infrastructure for write-protected
guest page. The old page_track logic gets rewrote and now stays in a new
standalone page_track.c. This page track infrastructure can be both used
by vGUC and GTT shadowing.

The important change is that it uses radix tree instead of hash table.
We don't have a predictable number of pages that will be tracked.

Here is some performance data (duration in us) of looking up a element:
Before: (aka. intel_vgpu_find_tracked_page)
0.091 0.089 0.090 ... 0.093 0.091 0.087 ... 0.292 0.285 0.292 0.291
After: (aka. intel_vgpu_find_page_track)
0.104 0.105 0.100 0.102 0.102 0.100 ... 0.101 0.101 0.105 0.105

The hash table has good performance at beginning, but turns bad with
more pages being tracked even no 3D applications are running. As
expected, radix tree has stable duration and very quick.

The overall benchmark (tested with Heaven Benchmark) marginally improved
since this is not the bottleneck. What we benefit more from this change
is scalability.

Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>