summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-09drm/vmwgfx: Keep a gem reference to user bos in surfacesZack Rusin1-3/+4
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
2023-08-23drm/vmwgfx: Fix possible invalid drm gem put callsZack Rusin1-4/+2
vmw_bo_unreference sets the input buffer to null on exit, resulting in null ptr deref's on the subsequent drm gem put calls. This went unnoticed because only very old userspace would be exercising those paths but it wouldn't be hard to hit on old distros with brand new kernels. Introduce a new function that abstracts unrefing of user bo's to make the code cleaner and more explicit. Signed-off-by: Zack Rusin <zackr@vmware.com> Reported-by: Ian Forbes <iforbes@vmware.com> Fixes: 9ef8d83e8e25 ("drm/vmwgfx: Do not drop the reference to the handle too soon") Cc: <stable@vger.kernel.org> # v6.4+ Reviewed-by: Maaz Mombasawala<mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230818041301.407636-1-zack@kde.org
2023-02-15drm/vmwgfx: Do not drop the reference to the handle too soonZack Rusin1-3/+5
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
2023-02-15drm/vmwgfx: Stop accessing buffer objects which failed initZack Rusin1-1/+3
ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208180050.2093426-1-zack@kde.org
2023-02-14drm/vmwgfx: Stop using raw ttm_buffer_object'sZack Rusin1-141/+57
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
2023-02-14drm/vmwgfx: Abstract placement selectionZack Rusin1-18/+125
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
2023-02-14drm/vmwgfx: Simplify fb pinningZack Rusin1-4/+4
Only the legacy display unit requires pinning of the fb memory in vram. Both the screen objects and screen targets can present from any buffer. That makes the pinning abstraction pointless. Simplify all of the code and move it to the legacy display unit, the only place that needs it. 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-5-zack@kde.org
2023-02-14drm/vmwgfx: Rename vmw_buffer_object to vmw_boZack Rusin1-54/+40
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
2023-02-14drm/vmwgfx: Remove the duplicate bo_free functionZack Rusin1-29/+20
Remove the explicit bo_free parameter which was switching between vmw_bo_bo_free and vmw_gem_destroy which had exactly the same implementation. It makes no sense to keep parameter which is always the same, remove it and all code referencing it. Instead use the vmw_bo_bo_free directly. 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-3-zack@kde.org
2023-02-06drm/ttm: prevent moving of pinned BOsChristian König1-17/+2
We have checks for this in the individual drivers move callback, but it's probably better to generally forbid that on a higher level. Also stops exporting ttm_resource_compat() since that's not necessary any more after removing the extra checks in vmwgfx. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-6-matthew.auld@intel.com
2023-01-10drm/vmwgfx: Remove rcu locks from user resourcesZack Rusin1-38/+0
User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. Fixes: e14c02e6b699 ("drm/vmwgfx: Look up objects without taking a reference") Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221207172907.959037-1-zack@kde.org
2022-10-27drm/ttm: rework on ttm_resource to use size_t typeSomalapuram Amaranath1-3/+3
Change ttm_resource structure from num_pages to size_t size in bytes. v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages v1 -> v2: change bo->resource->size to bo->base.size at some places v1 -> v2: remove the local variable v1 -> v2: cleanup cmp_size_smaller_first() v2 -> v3: adding missing PFN_UP in ttm_bo_vm_fault_reserved Signed-off-by: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221027091237.983582-1-Amaranath.Somalapuram@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2022-10-25drm/vmwgfx: Do not allow invalid bpp's for dumb buffersZack Rusin1-1/+15
Dumb buffers allow a very limited set of formats. Basically everything apart from 1, 2 and 4 is expected to return an error. Make vmwgfx follow those guidelines. This fixes igt's dumb_buffer invalid_bpp test on vmwgfx. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-13-zack@kde.org
2022-08-04drm/vmwgfx: cleanup commentsTom Rix1-1/+1
Remove second 'should' Spelling replacements aqcuire -> acquire applcations -> applications assumings -> assumes begining -> beginning commited -> committed contol -> control inbetween -> in between resorces -> resources succesful -> successful successfule -> successful Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220730135704.2889434-1-trix@redhat.com
2022-07-11drm/ttm: rename and cleanup ttm_bo_initChristian König1-7/+5
Rename ttm_bo_init to ttm_bo_init_validate since that better matches what the function is actually doing. Remove the unused size parameter, move the function's kerneldoc to the implementation and cleanup the whole error handling. Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220707102453.3633-2-christian.koenig@amd.com Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
2022-05-09drm/ttm: move default BO destructor into VMWGFX v2Christian König1-1/+9
It's the only driver using this. v2: use BUG_ON() in vmw_bo_create() as suggested by Zack Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220329110243.6335-5-christian.koenig@amd.com
2022-05-03Backmerge tag 'v5.18-rc5' of ↵Dave Airlie1-23/+20
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 5.18-rc5 There was a build fix for arm I wanted in drm-next, so backmerge rather then cherry-pick. Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-04-21drm/vmwgfx: Fix gem refcounting and memory evictionsZack Rusin1-23/+20
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
2022-04-07dma-buf: add DMA_RESV_USAGE_KERNEL v3Christian König1-1/+1
Add an usage for kernel submissions. Waiting for those are mandatory for dynamic DMA-bufs. As a precaution this patch also changes all occurrences where fences are added as part of memory management in TTM, VMWGFX and i915 to use the new value because it now becomes possible for drivers to ignore fences with the WRITE usage. v2: use "must" in documentation, fix whitespaces v3: separate out some driver changes and better document why some changes should still be part of this patch. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-5-christian.koenig@amd.com
2022-04-07dma-buf: specify usage while adding fences to dma_resv obj v7Christian König1-1/+2
Instead of distingting between shared and exclusive fences specify the fence usage while adding fences. Rework all drivers to use this interface instead and deprecate the old one. v2: some kerneldoc comments suggested by Daniel v3: fix a missing case in radeon v4: rebase on nouveau changes, fix lockdep and temporary disable warning v5: more documentation updates v6: separate internal dma_resv changes from this patch, avoids to disable warning temporary, rebase on upstream changes v7: fix missed case in lima driver, minimize changes to i915_gem_busy_ioctl Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-3-christian.koenig@amd.com
2022-04-07dma-buf: add enum dma_resv_usage v4Christian König1-2/+2
This change adds the dma_resv_usage enum and allows us to specify why a dma_resv object is queried for its containing fences. Additional to that a dma_resv_usage_rw() helper function is added to aid retrieving the fences for a read or write userspace submission. This is then deployed to the different query functions of the dma_resv object and all of their users. When the write paratermer was previously true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. v2: add KERNEL/OTHER in separate patch v3: some kerneldoc suggestions by Daniel v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in the rebase pointed out by Bas. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-2-christian.koenig@amd.com
2022-04-06dma-buf/drivers: make reserving a shared slot mandatory v4Christian König1-5/+11
Audit all the users of dma_resv_add_excl_fence() and make sure they reserve a shared slot also when only trying to add an exclusive fence. This is the next step towards handling the exclusive fence like a shared one. v2: fix missed case in amdgpu v3: and two more radeon, rename function v4: add one more case to TTM, fix i915 after rebase Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220406075132.3263-2-christian.koenig@amd.com
2021-12-17drm/vmwgfx: Fix possible usage of an uninitialized variableZack Rusin1-3/+5
vmw_user_bo_lookup can fail to lookup user buffers, especially because the buffer handles come from the userspace. The return value has to be checked before the buffers are put back. This was spotted by Dan's Smatch statick checker: drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release() error: uninitialized symbol 'vmw_bo'. Signed-off-by: Zack Rusin <zackr@vmware.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215200224.3693345-1-zack@kde.org (cherry picked from commit 60c9ecd705be3a28f79d70ea21c3939db668bf46) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-12-16drm/vmwgfx: Fix possible usage of an uninitialized variableZack Rusin1-3/+5
vmw_user_bo_lookup can fail to lookup user buffers, especially because the buffer handles come from the userspace. The return value has to be checked before the buffers are put back. This was spotted by Dan's Smatch statick checker: drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release() error: uninitialized symbol 'vmw_bo'. Signed-off-by: Zack Rusin <zackr@vmware.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215200224.3693345-1-zack@kde.org
2021-12-09drm/vmwgfx: Implement DRIVER_GEMZack Rusin1-407/+110
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
2021-12-09drm/vmwgfx: Remove the dedicated memory accountingZack Rusin1-56/+9
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
2021-12-01drm/vmwgfx: Switch the internal BO's to ttm_bo_type_kernelZack Rusin1-1/+1
There's never a need to access our internal kernel bo's from user-space. Those objects are used exclusively for internal support to guest backed surfaces (in otable setup and mob page tables) and there's no need to have them be of device type, i.e. mmappable from user-space. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105193845.258816-6-zackr@vmware.com
2021-09-03drm/ttm: cleanup ttm_resource_compatChristian König1-9/+6
Move that function into the resource handling and remove an unused parameter. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831112110.113196-1-christian.koenig@amd.com
2021-08-10drm/vmwgfx: Make use of PFN_ALIGN/PFN_UP helper macroCai Huoqing1-3/+2
it's a refactor to make use of PFN_ALIGN/PFN_UP helper macro Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210802033308.927-1-caihuoqing@baidu.com
2021-06-06dma-buf: drop the _rcu postfix on function names v3Christian König1-3/+3
The functions can be called both in _rcu context as well as while holding the lock. v2: add some kerneldoc as suggested by Daniel v3: fix indentation Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210602111714.212426-7-christian.koenig@amd.com
2021-06-02drm/ttm: rename bo->mem and make it a pointerChristian König1-18/+18
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
2021-05-11drm/vmwgfx: Add basic support for SVGA3Zack Rusin1-1/+1
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
2021-05-11drm/vmwgfx: Remove the reservation semaphoreZack Rusin1-31/+0
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
2021-04-23drm/ttm: remove special handling for non GEM driversChristian König1-0/+10
vmwgfx is the only driver actually using this. Move the handling into the driver instead. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210419092853.1605-1-christian.koenig@amd.com
2021-02-09drm/ttm: move memory accounting into vmwgfx v4Christian König1-4/+18
This is just another feature which is only used by VMWGFX, so move it into the driver instead. I've tried to add the accounting sysfs file to the kobject of the drm minor, but I'm not 100% sure if this works as expected. v2: fix typo in KFD and avoid 64bit divide v3: fix init order in VMWGFX v4: use pdev sysfs reference instead of drm Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Zack Rusin <zackr@vmware.com> (v3) Tested-by: Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210208133226.36955-2-christian.koenig@amd.com
2021-01-21drm/ttm: device naming cleanupChristian König1-2/+2
Rename ttm_bo_device to ttm_device. Rename ttm_bo_driver to ttm_device_funcs. Rename ttm_bo_global to ttm_global. Move global and device related functions to ttm_device.[ch]. No functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/415222/
2021-01-19drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply anotherLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:142: warning: Excess function parameter 'pin' description in 'vmw_bo_pin_in_vram_or_gmr' drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:647: warning: Function parameter or member 'p_base' not described in 'vmw_user_bo_alloc' 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-28-lee.jones@linaro.org
2020-12-14drm/ttm: cleanup BO size handling v3Christian König1-3/+3
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/
2020-10-07drm/vmwgfx: move null mem checks outside move notifiesDave Airlie1-3/+0
Both fns checked mem == NULL, just move the check outside. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-3-airlied@gmail.com
2020-09-24drm/vmwgfx: switch over to the new pin interface v2Christian König1-24/+25
Stop using TTM_PL_FLAG_NO_EVICT. v2: fix unconditional pinning Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/391601/?series=81973&rev=1
2020-09-24drm/vmwgfx: stop using ttm_bo_create v2Christian König1-0/+43
Implement in the driver instead since it is the only user of that function. v2: fix usage of ttm_bo_init_reserved Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/391614/?series=81973&rev=1
2020-09-11drm/ttm: nuke memory type flagsChristian König1-0/+1
It's not supported to specify more than one of those flags. So it never made sense to make this a flag in the first place. Nuke the flags and specify directly which memory type to use. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/389826/?series=81551&rev=1
2020-09-11drm/vmwgfx: stop setting multiple domain flagsChristian König1-2/+3
Setting more than one placement flag is illegal. Fix this by using the current flags. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/389824/?series=81551&rev=1
2020-08-06drm/ttm: rename ttm_mem_reg to ttm_resource.Dave Airlie1-2/+2
This name better reflects what the object does. I didn't rename all the pointers it seemed too messy. Signed-off-by: Dave Airlie <airlied@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-60-airlied@gmail.com
2020-06-26drm/vmwgfx: don't use ttm bo->offsetNirmoy Das1-2/+2
Calculate GPU offset within vmwgfx driver itself without depending on bo->offset. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/372933/ Signed-off-by: Christian König <christian.koenig@amd.com>
2019-11-06drm/vmwgfx: Use an RBtree instead of linked list for MOB resourcesThomas Hellstrom1-2/+3
With emulated coherent memory we need to be able to quickly look up a resource from the MOB offset. Instead of traversing a linked list with O(n) worst case, use an RBtree with O(log n) worst case complexity. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-11-06drm/vmwgfx: Implement an infrastructure for write-coherent resourcesThomas Hellstrom1-1/+4
This infrastructure will, for coherent resources, make sure that from the user-space point of view, data written by the CPU is immediately automatically available to the GPU at resource validation time. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-10-25drm/ttm, drm/vmwgfx: move cpu_writers handling into vmwgfxChristian König1-5/+12
This feature is only used by vmwgfx and superfluous for everybody else. Signed-off-by: Christian König <christian.koenig@amd.com> Co-developed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Tested-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/333650/
2019-08-21Merge tag 'drm-misc-next-2019-08-19' of ↵Dave Airlie1-4/+4
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number (and then restored) - dma-fence: Shrinkage of the dma_fence structure, Merge dma_fence_signal and dma_fence_signal_locked, Store the timestamp in struct dma_fence in a union with cb_list Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: fixup dma_resv rename fallout] From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea
2019-08-15drm/vmwgfx: Assign eviction priorities to resourcesThomas Hellstrom1-0/+2
TTM provides a means to assign eviction priorities to buffer object. This means that all buffer objects with a lower priority will be evicted first on memory pressure. Use this to make sure surfaces and in particular non-dirty surfaces are evicted first. Evicting in particular shaders, cotables and contexts imply a significant performance hit on vmwgfx, so make sure these resources are evicted last. Some buffer objects are sub-allocated in user-space which means we can have many resources attached to a single buffer object or resource. In that case the buffer object is given the highest priority of the attached resources. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-03 04:09:04 +0300