An error occurred fetching the project authors.
- 29 Sep, 2020 4 commits
-
-
Gerd Hoffmann authored
Implement resource create blob as specified. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-18-gurchetansingh@chromium.orgCo-developed-by:
Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by:
-
Gerd Hoffmann authored
A virtio-gpu vram object is based on range-based allocation. No guest shmemfs backing, so we call drm_gem_private_object_init. This is for host memory without any guest backing (atleast initially). Signed-off-by:
-
Gurchetan Singh authored
VRAM object will need it. Signed-off-by:
-
Gurchetan Singh authored
Useful for upcoming blob resources. Signed-off-by:
-
- 25 Sep, 2020 1 commit
-
-
Thomas Zimmermann authored
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces virtgpu's per-driver PRIME export function with a per-object function. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-19-tzimmermann@suse.de
-
- 26 Aug, 2020 1 commit
-
-
Gurchetan Singh authored
This reverts commit d323bb44. Fixes a double-free regression: [ 4.357928] drm_gem_shmem_free_object+0xb4/0x100 [ 4.358983] virtio_gpu_dequeue_ctrl_func+0xd9/0x290 [ 4.360343] process_one_work+0x1d2/0x3a0 [ 4.361581] worker_thread+0x45/0x3c0 [ 4.362645] kthread+0xf6/0x130 [ 4.363543] ? process_one_work+0x3a0/0x3a0 [ 4.364770] ? kthread_park+0x80/0x80 [ 4.365799] ret_from_fork+0x35/0x40 [ 4.367103] Modules linked in: [ 4.367958] CR2: 0000000000000018 [ 4.368857] ---[ end trace db84f7a2974d5c79 ]--- [ 4.370118] RIP: 0010:dma_direct_unmap_sg+0x1f/0x60 In addition, virtio has it's own set of dma-ops so there's not an obviously clean way to transition to shmem helpers. Fixes: d323bb44 ("drm/virtio: Call the right shmem helpers") Signed-off-by:
-
- 17 Aug, 2020 1 commit
-
-
Gurchetan Singh authored
This reverts commit d323bb44. Fixes a double-free regression: [ 4.357928] drm_gem_shmem_free_object+0xb4/0x100 [ 4.358983] virtio_gpu_dequeue_ctrl_func+0xd9/0x290 [ 4.360343] process_one_work+0x1d2/0x3a0 [ 4.361581] worker_thread+0x45/0x3c0 [ 4.362645] kthread+0xf6/0x130 [ 4.363543] ? process_one_work+0x3a0/0x3a0 [ 4.364770] ? kthread_park+0x80/0x80 [ 4.365799] ret_from_fork+0x35/0x40 [ 4.367103] Modules linked in: [ 4.367958] CR2: 0000000000000018 [ 4.368857] ---[ end trace db84f7a2974d5c79 ]--- [ 4.370118] RIP: 0010:dma_direct_unmap_sg+0x1f/0x60 In addition, virtio has it's own set of dma-ops so there's not an obviously clean way to transition to shmem helpers. Fixes: d323bb44 ("drm/virtio: Call the right shmem helpers") Signed-off-by:
-
- 07 Aug, 2020 1 commit
-
-
Xin He authored
Before setting shmem->pages to NULL, kfree() should be called. Signed-off-by:
Xin He <hexin.op@bytedance.com> Reviewed-by:
Qi Liu <liuqi.16@bytedance.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200722051851.72662-1-hexin.op@bytedance.comSigned-off-by:
-
- 03 Aug, 2020 1 commit
-
-
Michael S. Tsirkin authored
Now that the corresponding feature bit has been renamed, rename the quirk too - it's about special ways to do DMA, not necessarily about the IOMMU. Signed-off-by:Michael S. Tsirkin <mst@redhat.com>
-
- 03 Jun, 2020 1 commit
-
-
Daniel Vetter authored
drm_gem_shmem_get_sg_table is meant to implement obj->funcs->get_sg_table, for prime exporting. The one we want is drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not just native objects. v2: Rebase, this stuff moved around in commit 2f2aa137 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Fri Feb 7 08:46:38 2020 +0100 drm/virtio: move virtio_gpu_mem_entry initialization to new function Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-5-daniel.vetter@ffwll.ch
-
- 06 Apr, 2020 1 commit
-
-
Jiri Slaby authored
After commit f651c8b0 ("drm/virtio: factor out the sg_table from virtio_gpu_object"), virtio_gpu_create_object allocates too small space to fit everything in. It is because it allocates struct virtio_gpu_object, but should allocate a newly added struct virtio_gpu_object_shmem which has 2 more members. So fix that by using correct type in virtio_gpu_create_object. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Link: http://patchwork.freedesktop.org/patch/msgid/20200319100421.16267-1-jslaby@suse.cz Fixes: f651c8b0 ("drm/virtio: factor out the sg_table from virtio_gpu_object") Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
- 03 Apr, 2020 2 commits
-
-
Gurchetan Singh authored
It always returns zero. Signed-off-by:
-
Gurchetan Singh authored
For 3D buffers, virtio_gpu_gem_object_open notifies. We can have the same behavior for dumb buffer. v2: virtio_gpu_gem_object_open always notifies v3: avoid boolean variable Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200401223039.2860-3-gurchetansingh@chromium.orgSigned-off-by:
-
- 19 Mar, 2020 1 commit
-
-
Jiri Slaby authored
After commit f651c8b0 ("drm/virtio: factor out the sg_table from virtio_gpu_object"), virtio_gpu_create_object allocates too small space to fit everything in. It is because it allocates struct virtio_gpu_object, but should allocate a newly added struct virtio_gpu_object_shmem which has 2 more members. So fix that by using correct type in virtio_gpu_create_object. Signed-off-by:
-
- 09 Mar, 2020 2 commits
-
-
Gurchetan Singh authored
This function can be reused for hostmem objects. v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object() v3: use-after free fix Signed-off-by:
-
Gurchetan Singh authored
A resource will be a shmem based resource or a (planned) vram based resource, so it makes sense to factor out common fields (resource handle, dumb). v2: move mapped field to shmem object Signed-off-by:
-
- 27 Feb, 2020 3 commits
-
-
Gerd Hoffmann authored
virtio-gpu uses cached mappings, set drm_gem_shmem_object.map_cached accordingly. Cc: stable@vger.kernel.org Fixes: c66df701 ("drm/virtio: switch from ttm to gem shmem helpers") Reported-by:
Guillaume Gardet <Guillaume.Gardet@arm.com> Signed-off-by:
-
Gurchetan Singh authored
The plan is use have both shmem and virtual "vram" running side-by-side in virtio-gpu. It looks like we'll eventually use struct drm_gem_object as a base class, and we'll need to convert to shmem and vram objects on the fly. As a first step, add a virtio_gpu_is_shmem helper. Thanks to kraxel for suggesting this approach on Gitlab. Suggested-by:
-
Gurchetan Singh authored
This is a very, very minor cleanup. Signed-off-by:
-
- 24 Feb, 2020 1 commit
-
-
John Bates authored
The previous code was not thread safe and caused undefined behavior from spurious duplicate resource IDs. In this patch, an atomic_t is used instead. We no longer see any duplicate IDs in tests with this change. Fixes: 16065fcd ("drm/virtio: do NOT reuse resource ids") Signed-off-by:
John Bates <jbates@chromium.org> Reviewed-by:
-
- 17 Feb, 2020 2 commits
-
-
Gerd Hoffmann authored
Move all remaining virtio_gpu_notify() calls from virtio_gpu_cmd_* to the callers, for consistency reasons. Signed-off-by:
-
Gerd Hoffmann authored
Move virtio_gpu_notify() to higher-level functions for virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d() and virtio_gpu_cmd_resource_attach_backing(). virtio_gpu_object_create() will batch commands and notify only once when creating a resource. Signed-off-by:
-
- 10 Feb, 2020 3 commits
-
-
Gerd Hoffmann authored
Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by:
-
Gerd Hoffmann authored
Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by:
-
Gerd Hoffmann authored
Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by:
-
- 17 Oct, 2019 1 commit
-
-
Gerd Hoffmann authored
Switch gem shmem helper to the new mmap() workflow, from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap. v2: Fix vm_flags and vm_page_prot handling. Signed-off-by:
Steven Price <steven.price@arm.com> Acked-by:
-
- 04 Sep, 2019 4 commits
-
-
Gerd Hoffmann authored
virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4: fix drm_gem_object_funcs name. Signed-off-by:
-
Gerd Hoffmann authored
Rework fencing workflow. Stop using ttm helpers, use the virtio_gpu_array_* helpers instead. Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init. So we can simply use the standard fencing workflow and drop the tricky logic which checks whenever the command is in flight still. v6: rewrite most of the patch. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
With this gem and ttm will use the same reservation object, so mixing and matching ttm / gem reservation helpers should work fine. Signed-off-by:
-
- 28 Aug, 2019 1 commit
-
-
Stephen Rothwell authored
Fixes: 3e93bc2a ("drm/virtio: make resource id workaround runtime switchable.") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: http://patchwork.freedesktop.org/patch/msgid/20190828185516.22b03da8@canb.auug.org.auSigned-off-by:
-
- 27 Aug, 2019 1 commit
-
-
Gerd Hoffmann authored
Also update the comment with a reference to the virglrenderer fix. Signed-off-by:
-
- 23 Aug, 2019 1 commit
-
-
Gerd Hoffmann authored
We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Suggested-by:
Laszlo Ersek <lersek@redhat.com> Signed-off-by:
-
- 28 Mar, 2019 2 commits
-
-
Gerd Hoffmann authored
This patch moves the virtio_gpu_cmd_create_resource() call (which notifies the host about the new resource created) into the virtio_gpu_object_create() function. That way we can call virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host already knows about the object when ttm initializes the object and calls our driver callbacks. Specifically the object is already created when the virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(), so the extra virtio_gpu_object_attach() calls done after virtio_gpu_object_create() are not needed any more. The fence support for the create ioctl becomes a bit more tricky though. The code moved into virtio_gpu_object_create() too. We first submit the (fenced) virtio_gpu_cmd_create_resource() command, then initialize the ttm object, and finally attach just created object to the fence for the command in case it didn't finish yet. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com
-
Gerd Hoffmann authored
Create virtio_gpu_object_params, use that to pass object parameters to virtio_gpu_object_create. This is just the first step, followup patches will add more parameters to the struct. The plan is to use the struct for all object parameters. Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is unused and always false. Also drop "pinned" parameter. virtio-gpu doesn't shuffle around objects, so effecively they all are pinned anyway. Hardcode TTM_PL_FLAG_NO_EVICT so ttm knows. Doesn't change much for the moment as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to move around objects. That'll probably change in the future though. Signed-off-by:
-
- 11 Feb, 2019 1 commit
-
-
Gerd Hoffmann authored
Bisected guest kernel changes crashing qemu. Landed at "6c1cd97b drm/virtio: fix resource id handling". Looked again, and noticed we where not only leaking *some* ids, but *all* ids. The old code never ever called virtio_gpu_resource_id_put(). So, commit 6c1cd97b effectively makes the linux kernel starting re-using IDs after releasing them, and apparently virglrenderer can't deal with that. Oops. This patch puts a temporary stopgap into place for the 5.0 release. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
- 14 Nov, 2018 2 commits
-
-
Matthew Wilcox authored
0-based IDAs are more efficient than any other base. Convert the 1-based IDAs to be 0-based. Signed-off-by:
Matthew Wilcox <willy@infradead.org> Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-2-willy@infradead.orgSigned-off-by:
-
Matthew Wilcox authored
ida_alloc() can return -ENOMEM in the highly unlikely case we run out of memory. The current code creates an object with an invalid ID. Signed-off-by:
-
- 29 Oct, 2018 2 commits
-
-
Matthew Wilcox authored
These IDRs were only being used to allocate unique numbers, not to look up pointers, so they can use the more space-efficient IDA instead. Signed-off-by:
-
Gerd Hoffmann authored
Move virtio_gpu_resource_id_{get,put} to virtgpu_object.c and make them static. Allocate and free the id on creation and destroy, drop all other calls. That way objects have a valid handle for the whole lifetime of the object. Also fixes ids leaking. Worst offender are dumb buffers, and I think some error paths too. Signed-off-by:
-
