Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5 |
|
#
21e29f14 |
| 20-Sep-2023 |
Philipp Stanner <pstanner@redhat.com> |
drm: vmwgfx_surface.c: copy user-array safely
[ Upstream commit 06ab64a0d836ac430c5f94669710a78aa43942cb ]
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_arr
drm: vmwgfx_surface.c: copy user-array safely
[ Upstream commit 06ab64a0d836ac430c5f94669710a78aa43942cb ]
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely.
Suggested-by: David Airlie <airlied@redhat.com> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920123612.16914-7-pstanner@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
91398b41 |
| 27-Sep-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Keep a gem reference to user bos in surfaces
Surfaces can be backed (i.e. stored in) memory objects (mob's) which are created and managed by the userspace as GEM buffers. Surfaces grab o
drm/vmwgfx: Keep a gem reference to user bos in surfaces
Surfaces can be backed (i.e. stored in) memory objects (mob's) which are created and managed by the userspace as GEM buffers. Surfaces grab only a ttm reference which means that the gem object can be deleted underneath us, especially in cases where prime buffer export is used.
Make sure that all userspace surfaces which are backed by gem objects hold a gem reference to make sure they're not deleted before vmw surfaces are done with them, which fixes: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28 refcount_warn_saturate+0xfb/0x150 Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm gameport> CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:refcount_warn_saturate+0xfb/0x150 Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89 48 c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff ff ff 0f b> RSP: 0018:ffffbdc34344bba0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff960475ea1548 RSI: 0000000000000001 RDI: ffff960475ea1540 RBP: ffffbdc34344bba8 R08: 0000000000000003 R09: 65646e75203a745f R10: ffffffffa5b32b20 R11: 72657466612d6573 R12: ffff96037d6a6400 R13: ffff9603484805b0 R14: 000000000000000b R15: ffff9603bed06060 FS: 00007f5fd8520c40(0000) GS:ffff960475e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5fda755000 CR3: 000000010d012005 CR4: 00000000003706e0 Call Trace: <TASK> ? show_regs+0x6e/0x80 ? refcount_warn_saturate+0xfb/0x150 ? __warn+0x91/0x150 ? refcount_warn_saturate+0xfb/0x150 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xfb/0x150 drm_gem_object_handle_put_unlocked+0xba/0x110 [drm] drm_gem_object_release_handle+0x6e/0x80 [drm] drm_gem_handle_delete+0x6a/0xc0 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx] drm_ioctl_kernel+0xbc/0x160 [drm] drm_ioctl+0x2d2/0x580 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] ? do_vmi_munmap+0xee/0x180 vmw_generic_ioctl+0xbd/0x180 [vmwgfx] vmw_unlocked_ioctl+0x19/0x20 [vmwgfx] __x64_sys_ioctl+0x99/0xd0 do_syscall_64+0x5d/0x90 ? syscall_exit_to_user_mode+0x2a/0x50 ? do_syscall_64+0x6d/0x90 ? handle_mm_fault+0x16e/0x2f0 ? exit_to_user_mode_prepare+0x34/0x170 ? irqentry_exit_to_user_mode+0xd/0x20 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x8e/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f5fda51aaff Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 7> RSP: 002b:00007ffd536a4d30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd536a4de0 RCX: 00007f5fda51aaff RDX: 00007ffd536a4de0 RSI: 0000000040086442 RDI: 0000000000000003 RBP: 0000000040086442 R08: 000055fa603ada50 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffd536a51b8 R13: 0000000000000003 R14: 000055fa5ebb4c80 R15: 00007f5fda90f040 </TASK> ---[ end trace 0000000000000000 ]---
A lot of the analyis on the bug was done by Murray McAllister and Ian Forbes.
Reported-by: Murray McAllister <murray.mcallister@gmail.com> Cc: Ian Forbes <iforbes@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle too soon") Cc: <stable@vger.kernel.org> # v6.2+ Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230928041355.737635-1-zack@kde.org
show more ...
|
Revision tags: v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12 |
|
#
a950b989 |
| 10-Feb-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Do not drop the reference to the handle too soon
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing
drm/vmwgfx: Do not drop the reference to the handle too soon
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot.
It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them.
Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace.
Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point.
Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org (cherry picked from commit 9ef8d83e8e25d5f1811b3a38eb1484f85f64296c) Cc: <stable@vger.kernel.org> # v5.17+
show more ...
|
#
9ef8d83e |
| 10-Feb-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Do not drop the reference to the handle too soon
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing
drm/vmwgfx: Do not drop the reference to the handle too soon
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot.
It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them.
Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace.
Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point.
Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org
show more ...
|
Revision tags: v6.1.11, v6.1.10, v6.1.9 |
|
#
668b2066 |
| 30-Jan-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Stop using raw ttm_buffer_object's
Various bits of the driver used raw ttm_buffer_object instead of the driver specific vmw_bo object. All those places used to duplicate the mapped bo ca
drm/vmwgfx: Stop using raw ttm_buffer_object's
Various bits of the driver used raw ttm_buffer_object instead of the driver specific vmw_bo object. All those places used to duplicate the mapped bo caching policy of vmw_bo.
Instead of duplicating all of that code and special casing various functions to work both with vmw_bo and raw ttm_buffer_object's unify the buffer object handling code.
As part of that work fix the naming of bo's, e.g. insted of generic backup use 'guest_memory' because that's what it really is.
All of it makes the driver easier to maintain and the code easier to read. Saves 100+ loc as well.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-9-zack@kde.org
show more ...
|
#
39985eea |
| 30-Jan-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Abstract placement selection
Problem with explicit placement selection in vmwgfx is that by the time the buffer object needs to be validated the information about which placement was sup
drm/vmwgfx: Abstract placement selection
Problem with explicit placement selection in vmwgfx is that by the time the buffer object needs to be validated the information about which placement was supposed to be used is lost. To workaround this the driver had a bunch of state in various places e.g. as_mob or cpu_blit to somehow convey the information on which placement was intended.
Fix it properly by allowing the buffer objects to hold their preferred placement so it can be reused whenever needed. This makes the entire validation pipeline a lot easier both to understand and maintain.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-8-zack@kde.org
show more ...
|
#
09881d29 |
| 30-Jan-2023 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Rename vmw_buffer_object to vmw_bo
The rest of the drivers which are using ttm have mostly standardized on driver_prefix_bo as the name for subclasses of the TTM buffer object. Make vmwg
drm/vmwgfx: Rename vmw_buffer_object to vmw_bo
The rest of the drivers which are using ttm have mostly standardized on driver_prefix_bo as the name for subclasses of the TTM buffer object. Make vmwgfx match the rest of the drivers and follow the same naming semantics.
This is especially clear given that the name of the file in which the object was defined is vmw_bo.c.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-4-zack@kde.org
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4 |
|
#
da7ffb96 |
| 25-Oct-2022 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Cleanup the cursor snooping code
Cursor snooping depended on implicit size and format which made debugging quite difficult. Make the code easier to following by making everything explici
drm/vmwgfx: Cleanup the cursor snooping code
Cursor snooping depended on implicit size and format which made debugging quite difficult. Make the code easier to following by making everything explicit and instead of using magic numbers predefine all the parameters the code depends on.
Also fixes incorrectly computed pitches for non-aligned cursor snoops. Fix which has no practical effect because non-aligned cursor snoops are not used by the X11 driver and Wayland cursors will go through mob cursors, instead of surface dma's.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Michael Banack <banackm@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-2-zack@kde.org
show more ...
|
Revision tags: v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35 |
|
#
298799a2 |
| 19-Apr-2022 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Fix gem refcounting and memory evictions
v2: Add the last part of the ref count fix which was spotted by Philipp Sieweck where the ref count of cpu writers is off due to ERESTARTSYS or E
drm/vmwgfx: Fix gem refcounting and memory evictions
v2: Add the last part of the ref count fix which was spotted by Philipp Sieweck where the ref count of cpu writers is off due to ERESTARTSYS or EBUSY during bo waits.
The initial GEM port broke refcounting on shareable (prime) surfaces and memory evictions. The prime surfaces broke because the parent surfaces weren't increasing the ref count on GEM surfaces, which meant that the memory backing textures could have been deleted while the texture was still accessible. The evictions broke due to a typo, the code was supposed to exit if the passed buffers were not vmw_buffer_object not if they were. They're tied because the evictions depend on having memory to actually evict.
This fixes crashes with XA state tracker which is used for xrender acceleration on xf86-video-vmware, apps/tests which use a lot of memory (a good test being the piglit's streaming-texture-leak) and desktops.
Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reported-by: Philipp Sieweck <psi@informatik.uni-kiel.de> Cc: <stable@vger.kernel.org> # v5.17+ Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220420040328.1007409-1-zack@kde.org
show more ...
|
Revision tags: v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
8afa13a0 |
| 06-Dec-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Implement DRIVER_GEM
This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx was written before GEM and has always used TTM. Over the years the TTM buffers started inherti
drm/vmwgfx: Implement DRIVER_GEM
This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx was written before GEM and has always used TTM. Over the years the TTM buffers started inherting from GEM objects but vmwgfx never implemented GEM making it quite awkward. We were directly setting variables in GEM objects to not make DRM crash.
This change brings vmwgfx inline with other DRM drivers and allows us to use a lot of DRM helpers which have depended on drivers with GEM support.
Due to historical reasons vmwgfx splits the idea of a buffer and surface which makes it a littly tricky since either one can be used in most of our ioctl's which take user space handles. For now our BO's are GEM objects and our surfaces are opaque objects which are backed by GEM objects. In the future I'd like to combine those into a single BO but we don't want to break any of our existing ioctl's so it will take time to do it in a non-destructive way.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-5-zack@kde.org
show more ...
|
#
8aadeb8a |
| 06-Dec-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Remove the dedicated memory accounting
vmwgfx shared very elaborate memory accounting with ttm. It was moved from ttm to vmwgfx in change f07069da6b4c ("drm/ttm: move memory accounting i
drm/vmwgfx: Remove the dedicated memory accounting
vmwgfx shared very elaborate memory accounting with ttm. It was moved from ttm to vmwgfx in change f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4") but because of complexity it was hard to maintain. Some parts of the code weren't freeing memory correctly and some were missing accounting all together. While those would be fairly easy to fix the fundamental reason for memory accounting in the driver was the ability to invoke shrinker which is part of TTM code as well (with support for unified memory hopefully coming soon).
That meant that vmwgfx had a lot of code that was either unused or duplicating code from TTM. Removing this code also prevents excessive calls to global swapout which were common during memory pressure because both vmwgfx and TTM would invoke the shrinker when memory usage reached half of RAM.
Fixes: f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4") Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-2-zack@kde.org
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53 |
|
#
2bc5da52 |
| 24-Jul-2021 |
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> |
drm/vmwgfx: fix potential UAF in vmwgfx_surface.c
drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_ge
drm/vmwgfx: fix potential UAF in vmwgfx_surface.c
drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_get is called on unprotected file_priv->master pointers in vmw_surface_define_ioctl and vmw_gb_surface_define_internal.
This is fixed by replacing drm_master_get with drm_file_get_master.
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-4-desmondcheongzx@gmail.com
show more ...
|
Revision tags: v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46 |
|
#
ebc9ac7c |
| 15-Jun-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Update device headers
Historically our device headers have been forked versions of the internal device headers, this has made maintaining them a bit of a burden. To fix the situation, go
drm/vmwgfx: Update device headers
Historically our device headers have been forked versions of the internal device headers, this has made maintaining them a bit of a burden. To fix the situation, going forward, the device headers will be verbatim copies of the internal headers. To do that the driver code has to be adapted to use pristine device headers. This will make future update to the device headers trivial and automatic.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-2-zackr@vmware.com
show more ...
|
Revision tags: v5.10.43 |
|
#
a12be027 |
| 09-Jun-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Fix subresource updates with new contexts
The has_dx variable was only set during the initialization which meant that UPDATE_SUBRESOURCE was never used. We were emulating it with UPDATE_
drm/vmwgfx: Fix subresource updates with new contexts
The has_dx variable was only set during the initialization which meant that UPDATE_SUBRESOURCE was never used. We were emulating it with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead of has_dx which has been deprecated a long time ago we need to check for whether shader model 4.0 or newer is available to the device.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-4-zackr@vmware.com
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
d3116756 |
| 12-Apr-2021 |
Christian König <christian.koenig@amd.com> |
drm/ttm: rename bo->mem and make it a pointer
When we want to decouble resource management from buffer management we need to be able to handle resources separately.
Add a resource pointer and renam
drm/ttm: rename bo->mem and make it a pointer
When we want to decouble resource management from buffer management we need to be able to handle resources separately.
Add a resource pointer and rename bo->mem so that all code needs to change to access the pointer instead.
No functional change.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-4-christian.koenig@amd.com
show more ...
|
#
2cd80dbd |
| 05-May-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Add basic support for SVGA3
SVGA3 is the next version of our PCI device. Some of the changes include using MMIO for register accesses instead of ioports, deprecating the FIFO MMIO and re
drm/vmwgfx: Add basic support for SVGA3
SVGA3 is the next version of our PCI device. Some of the changes include using MMIO for register accesses instead of ioports, deprecating the FIFO MMIO and removing a lot of the old and legacy functionality. SVGA3 doesn't support guest backed objects right now so everything except 3D is working.
v2: Fixes all the static analyzer warnings
Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Martin Krastev <krastevm@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210505191007.305872-1-zackr@vmware.com
show more ...
|
#
8211783f |
| 04-May-2021 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Remove the reservation semaphore
Now since Christian reworked TTM to always keep objects on the LRU list unless they are pinned we shouldn't need the reservation semaphore. It makes the
drm/vmwgfx: Remove the reservation semaphore
Now since Christian reworked TTM to always keep objects on the LRU list unless they are pinned we shouldn't need the reservation semaphore. It makes the driver code a lot cleaner, especially because it was a little hard to reason when and where the reservation semaphore needed to be held.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-5-zackr@vmware.com
show more ...
|
#
88509f69 |
| 04-May-2021 |
Thomas Hellstrom <thellstrom@vmware.com> |
drm/vmwgfx: Fix cpu updates of coherent multisample surfaces
In cases where the dirty linear memory range spans multiple sample sheets in a surface, the dirty surface region is incorrectly computed.
drm/vmwgfx: Fix cpu updates of coherent multisample surfaces
In cases where the dirty linear memory range spans multiple sample sheets in a surface, the dirty surface region is incorrectly computed. To do this correctly and in an optimized fashion we would have to compute the dirty region of each sample sheet and compute the union of those regions.
But assuming that cpu writing to a multisample surface is rather a corner case than a common case, just set the dirty region to the full surface.
This fixes OpenGL piglit errors with SVGA_FORCE_COHERENT=1 and the piglit test:
fbo-depthstencil blit default_fb -samples=2 -auto
Fixes: 9ca7d19ff8ba ("drm/vmwgfx: Add surface dirty-tracking callbacks") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-4-zackr@vmware.com
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
cde3435a |
| 15-Jan-2021 |
Lee Jones <lee.jones@linaro.org> |
drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or member 'pr
drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or member 'prime' not described in 'vmw_user_surface' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:55: warning: Function parameter or member 'backup_base' not described in 'vmw_user_surface' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:78: warning: cannot understand function prototype: 'struct vmw_surface_dirty ' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or member 'header' not described in 'vmw_surface_dma' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or member 'body' not described in 'vmw_surface_dma' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or member 'cb' not described in 'vmw_surface_dma' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:173: warning: Function parameter or member 'suffix' not described in 'vmw_surface_dma' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:181: warning: Function parameter or member 'header' not described in 'vmw_surface_define' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:181: warning: Function parameter or member 'body' not described in 'vmw_surface_define' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:189: warning: Function parameter or member 'header' not described in 'vmw_surface_destroy' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:189: warning: Function parameter or member 'body' not described in 'vmw_surface_destroy' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:555: warning: Function parameter or member 'readback' not described in 'vmw_legacy_srf_unbind' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Function parameter or member 'res' not described in 'vmw_gb_surface_create' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Excess function parameter 'srf' description in 'vmw_gb_surface_create' drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:1067: warning: Excess function parameter 'cmd_space' description in 'vmw_gb_surface_create'
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Roland Scheidegger <sroland@vmware.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-34-lee.jones@linaro.org
show more ...
|
Revision tags: v5.10 |
|
#
8426ed9c |
| 18-Nov-2020 |
Zack Rusin <zackr@vmware.com> |
drm/vmwgfx: Cleanup the cmd/fifo split
Lets try to cleanup the usage of the term FIFO which we used for both our MMIO based cmd queue processing and for general command processing which could have b
drm/vmwgfx: Cleanup the cmd/fifo split
Lets try to cleanup the usage of the term FIFO which we used for both our MMIO based cmd queue processing and for general command processing which could have been using command buffers interface. We're going to rename the functions which are processing commands (and work either via MMIO or command buffers) as _cmd_ and functions which operate on the MMIO based commands as FIFO to match the SVGA device naming.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/414044/?series=85516&rev=2
show more ...
|
#
e11bfb99 |
| 09-Dec-2020 |
Christian König <christian.koenig@amd.com> |
drm/ttm: cleanup BO size handling v3
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->base.size is the original size of the BO in ar
drm/ttm: cleanup BO size handling v3
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->base.size is the original size of the BO in arbitrary units, usually bytes.
bo->mem.num_pages is the size in number of pages in the resource domain of bo->mem.mem_type.
v2: use the GEM object size instead of the BO size v3: fix printks in some places
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> (v1) Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/406831/
show more ...
|
#
d6c91423 |
| 24-Jul-2021 |
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> |
drm/vmwgfx: fix potential UAF in vmwgfx_surface.c
[ Upstream commit 2bc5da528dd570c5ecabc107e6fbdbc55974276f ]
drm_file.master should be protected by either drm_device.master_mutex or drm_file.mast
drm/vmwgfx: fix potential UAF in vmwgfx_surface.c
[ Upstream commit 2bc5da528dd570c5ecabc107e6fbdbc55974276f ]
drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_get is called on unprotected file_priv->master pointers in vmw_surface_define_ioctl and vmw_gb_surface_define_internal.
This is fixed by replacing drm_master_get with drm_file_get_master.
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-4-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
40b70170 |
| 04-May-2021 |
Thomas Hellstrom <thellstrom@vmware.com> |
drm/vmwgfx: Fix cpu updates of coherent multisample surfaces
[ Upstream commit 88509f698c4e38e287e016e86a0445547824135c ]
In cases where the dirty linear memory range spans multiple sample sheets i
drm/vmwgfx: Fix cpu updates of coherent multisample surfaces
[ Upstream commit 88509f698c4e38e287e016e86a0445547824135c ]
In cases where the dirty linear memory range spans multiple sample sheets in a surface, the dirty surface region is incorrectly computed. To do this correctly and in an optimized fashion we would have to compute the dirty region of each sample sheet and compute the union of those regions.
But assuming that cpu writing to a multisample surface is rather a corner case than a common case, just set the dirty region to the full surface.
This fixes OpenGL piglit errors with SVGA_FORCE_COHERENT=1 and the piglit test:
fbo-depthstencil blit default_fb -samples=2 -auto
Fixes: 9ca7d19ff8ba ("drm/vmwgfx: Add surface dirty-tracking callbacks") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-4-zackr@vmware.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4 |
|
#
4f88b4cc |
| 17-Jun-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
drm/vmwgfx: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes.
This code was detected with the help of Coc
drm/vmwgfx: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
show more ...
|
Revision tags: v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31 |
|
#
c594285f |
| 05-Apr-2020 |
Colin Ian King <colin.king@canonical.com> |
drm/vmwgfx: remove redundant assignment to variable ret
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is re
drm/vmwgfx: remove redundant assignment to variable ret
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com>
show more ...
|