linux/drivers/gpu/drm/virtio/virtgpu_object.c, branch v5.4

drm/virtio: use virtio_max_dma_size

2019-08-23T08:09:02Z

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 Signed-off-by: Gerd Hoffmann Reviewed-by: Laszlo Ersek Link: http://patchwork.freedesktop.org/patch/msgid/20190821111210.27165-1-kraxel@redhat.com

drm/virtio: rework resource creation workflow.

2019-03-28T11:11:56Z

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: Gerd Hoffmann Acked-by: Noralf Trønnes Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com

drm/virtio: use struct to pass params to virtio_gpu_object_create()

2019-03-28T11:11:55Z

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: Gerd Hoffmann Acked-by: Noralf Trønnes Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-3-kraxel@redhat.com

drm/virtio: do NOT reuse resource ids

2019-02-11T04:44:10Z

Bisected guest kernel changes crashing qemu. Landed at "6c1cd97bda 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 6c1cd97bda 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: Gerd Hoffmann Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20190208140409.15280-1-kraxel@redhat.com

drm/virtio: Use IDAs more efficiently

2018-11-14T11:50:34Z

0-based IDAs are more efficient than any other base. Convert the 1-based IDAs to be 0-based. Signed-off-by: Matthew Wilcox Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-2-willy@infradead.org Signed-off-by: Gerd Hoffmann

drm/virtio: Handle error from virtio_gpu_resource_id_get

2018-11-14T11:50:34Z

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: Matthew Wilcox Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-1-willy@infradead.org Signed-off-by: Gerd Hoffmann

drm/virtio: Replace IDRs with IDAs

2018-10-29T21:50:55Z

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: Matthew Wilcox Link: http://patchwork.freedesktop.org/patch/msgid/20180926160031.15721-2-willy@infradead.org [ kraxel: resolve conflict ] Signed-off-by: Gerd Hoffmann

drm/virtio: fix resource id handling

2018-10-29T21:50:55Z

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: Gerd Hoffmann Reviewed-by: Dave Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-7-kraxel@redhat.com

drm/virtio: track created object state

2018-10-29T21:50:55Z

Track whenever the virtio_gpu_object is already created (i.e. host knows about it) in a new variable. Add checks to virtio_gpu_object_attach() to do nothing on objects not created yet. Make virtio_gpu_ttm_bo_destroy() use the new variable too, instead of expecting hw_res_handle indicating the object state. Signed-off-by: Gerd Hoffmann Reviewed-by: Dave Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-2-kraxel@redhat.com

virtio: Rework virtio_gpu_object_kmap()

2018-09-26T06:05:06Z

Currently, virtio_gpu_object_kmap() is only called by virtio_gpufb_create(), when a DRM framebuffer is created. Thus, instead of returning the vmap'ed address, emit a warning if virtio_gpu_object_kmap is called on an already mapped object. With this change, kmap/kunmap calls are now balanced. Signed-off-by: Ezequiel Garcia Link: http://patchwork.freedesktop.org/patch/msgid/20180925161606.17980-3-ezequiel@collabora.com Signed-off-by: Gerd Hoffmann