kernel.git/drivers/gpu/drm/virtio/virtgpu_gem.c, branch master

Convert 'alloc_flex' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

Merge drm/drm-fixes into drm-misc-fixes

2025-04-08T08:15:47Z

Backmerging to get updates from v6.15-rc1. Signed-off-by: Thomas Zimmermann

drm/virtio: Don't attach GEM to a non-created context in gem_object_open()

2025-04-01T20:11:54Z

The vfpriv->ctx_id is always initialized to a non-zero value. Check whether context was created before attaching GEM to this context ID. This left unnoticed previously because host silently skips attachment if context doesn't exist, still we shouldn't do that for consistency. Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported") Cc: # v6.14+ Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Clark Link: https://lore.kernel.org/r/20250401123842.2232205-1-dmitry.osipenko@collabora.com

drm/virtio: Add drm_panic support

2025-02-09T17:36:51Z

Virtio gpu supports the drm_panic module, which displays a message to the screen when a kernel panic occurs. It is supported where it has vmapped shmem BO. Signed-off-by: Jocelyn Falempe Signed-off-by: Ryosuke Yasuoka Tested-by: Dmitry Osipenko Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250206104300.416014-1-ryasuoka@redhat.com

drm/virtio: Don't create a context with default param if context_init is supported

2024-11-18T18:17:42Z

Xorg context creation fails for native contexts that use VIRTGPU_CONTEXT_INIT because context is already initialized implicitly when dumb buffer is created. Fix it by not creating default vrend context if context_init is supported. Signed-off-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/20241020224725.179937-1-dmitry.osipenko@collabora.com

drm/virtio: Use generic dumb_map_offset implementation

2024-11-18T11:08:37Z

Currently, virtio uses its own dumb_map_offset implementation, virtio_gpu_mode_dumb_mmap. It works similarly to generic implementation, drm_gem_dumb_map_offset, and using the generic implementation is preferable (and making drivers to do so is a task stated on the DRM subsystem's TODO list). Thus, make driver use the generic implementation. This includes VIRTGPU_MAP ioctl so it cannot be used to circumvent rules imposed by drm_gem_dumb_map_offset (imported objects cannot be mapped). Signed-off-by: Peter Shkenev Signed-off-by: Dmitry Osipenko [dmitry.osipenko@collabora.com: cosmetic code improvements] Link: https://patchwork.freedesktop.org/patch/msgid/20241107141133.13624-1-mustela@erminea.space

drm/virtio: Unlock reservations on dma_resv_reserve_fences() error

2022-07-19T12:40:58Z

Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens. Cc: stable@vger.kernel.org Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4") Reviewed-by: Thomas Hellström Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-5-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann

dma-buf: specify usage while adding fences to dma_resv obj v7

2022-04-07T10:53:53Z

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 Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-3-christian.koenig@amd.com

dma-buf/drivers: make reserving a shared slot mandatory v4

2022-04-06T15:38:25Z

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 Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220406075132.3263-2-christian.koenig@amd.com