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: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200615230500.551-1-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDaniel 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

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: NJiri 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: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 0666a8d7)

It always returns zero.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200401223039.2860-4-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200401223039.2860-3-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NJiri 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: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Reported-by: NGuillaume Gardet <Guillaume.Gardet@arm.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Tested-by: NGuillaume Gardet <Guillaume.Gardet@arm.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200226154752.24328-3-kraxel@redhat.com

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: NGerd Hoffman <kraxel@redhat.com>
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200227002601.745-3-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

This is a very, very minor cleanup.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200227002601.745-2-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NJohn Bates <jbates@chromium.org>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220225319.45621-1-jbates@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Move all remaining virtio_gpu_notify() calls from virtio_gpu_cmd_*
to the callers, for consistency reasons.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-7-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Reviewed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200214125535.26349-5-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-5-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

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: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-4-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

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: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200207074638.26386-3-kraxel@redhat.comReviewed-by: NChia-I Wu <olvaffe@gmail.com>

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-15-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-10-kraxel@redhat.com

No users left.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-5-kraxel@redhat.com

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-2-kraxel@redhat.com

Fixes: 3e93bc2a ("drm/virtio: make resource id workaround runtime switchable.")
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Link: http://patchwork.freedesktop.org/patch/msgid/20190828185516.22b03da8@canb.auug.org.auSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Also update the comment with a reference to the virglrenderer fix.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NChia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190822102614.18164-1-kraxel@redhat.com

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

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

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

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190208140409.15280-1-kraxel@redhat.com

0-based IDAs are more efficient than any other base.  Convert the
1-based IDAs to be 0-based.
Signed-off-by: NMatthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-2-willy@infradead.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NMatthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-1-willy@infradead.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NMatthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20180926160031.15721-2-willy@infradead.org

[ kraxel: resolve conflict ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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

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

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: NEzequiel Garcia <ezequiel@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180925161606.17980-3-ezequiel@collabora.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Implement a virtio_gpu_object_kunmap() to unmap the kernel
mapping, and use it in the TTM object destroy path.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180925161606.17980-2-ezequiel@collabora.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Never used as parameter, the only driver actually using this is nouveau
and there it is initialized after the BO is initialized.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

forward the operation context to ttm_tt_populate as well,
and the ultimate goal is swapout enablement for reserved BOs.

v2: squash in fix for vboxvideo
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NRoger He <Hongbo.He@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reported-by: N李强 <liqiang6-s@360.cn>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406155941.458-1-kraxel@redhat.com

Not used any more.
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Not used any more.
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>