Re: understanding virtio-gpu

Hi, > 1. virtio_gpu_pci_quirk(): > > * what is the explicit framebuffer removal about ? unregister boot framebuffer (typically efifb or vesafb on x86). > * why is it necessary to rename the device with "pci:" prefix ? > > does it only work w/ pci transport ? > what's the backgrou

Re: refactor the i915 GVT support

Hi, > https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i915/gvt/xengt.c > But it's hard for some customers to contribute their own "hypervisor" > module to the upstream Linux kernel. I am thinking what would be a > better solution here? The MPT layer in the kernel helps a

Re: [RFC v1 2/4] virtio-gpu uapi: Add VIRTIO_GPU_F_OUT_FENCE feature

On Thu, Jul 29, 2021 at 01:16:57AM -0700, Vivek Kasireddy wrote: > This feature enables the Guest to wait to know when a resource > is completely consumed by the Host. virtio spec update? What are the exact semantics? Why a new command? Can't you simply fence one of the commands sent anyway (se

Re: [RFC v1 4/4] drm/virtio: Probe and implement VIRTIO_GPU_F_OUT_FENCE feature

Hi, > + bool has_out_fence; > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_OUT_FENCE)) { > + vgdev->has_out_fence = true; > + vgdev->ddev->mode_config.deferred_out_fence = true; Looks like you don't need has_out_fence, you can just use vgdev->ddev->mode_co

Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability

Hi, > - We fix virtio to send out the completion event at the end of this entire > pipeline, i.e. virtio code needs to take care of sending out the > crtc_state->event correctly. That sounds sensible to me. Fence the virtio commands, make sure (on the host side) the command completes only

Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability

Hi, > > That sounds sensible to me. Fence the virtio commands, make sure (on > > the host side) the command completes only when the work is actually done > > not only submitted. Has recently been added to qemu for RESOURCE_FLUSH > > (aka frontbuffer rendering) and doing the same for SET_SCANOU

Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability

Hi, > > virtio_gpu_primary_plane_update() will send RESOURCE_FLUSH only for > > DIRTYFB and both SET_SCANOUT + RESOURCE_FLUSH for page-flip, and I > > think for the page-flip case the host (aka qemu) doesn't get the > > "wait until old framebuffer is not in use any more" right yet. > [Kasireddy,

Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)

> > + > > + if (vgdev->has_resource_blob) { > > + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST; > > + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE; > > > > This creates some log spam with crosvm + virgl_3d + vanilla linux, since > transfers don't work for guest

Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)

Hi, > > IIRC the VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag means that the host *can* > > create a shared mapping (i.e. the host seeing guest-side changes without > > explicit transfer doesn't cause problems for the guest). It doesn not > > mean the host *must* create a shared mapping (note that ther

Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)

On Wed, Apr 14, 2021 at 06:36:55AM +, Zhang, Tina wrote: > Hi Gerd, > > Speaking of the modifier, we notice that the virtio-gpu driver's > mode_config.allow_fb_modifiers = false, which means virtio-gpu doesn't > support modifier. With mode_config.allow_fb_modifiers=false, the DRM > Modifier AP

Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)

On Wed, Apr 14, 2021 at 04:31:45PM -0700, Gurchetan Singh wrote: > On Mon, Apr 12, 2021 at 10:36 PM Vivek Kasireddy > wrote: > > > If support for Blob resources is available, then dumb BOs created > > by the driver can be considered as guest Blobs. > > > > v2: Don't skip transfer and flush comman

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

Hi, > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During > > > > if support for 8-bit frame buffers would be added? > > Is that 8-bit greyscale or 8-bit indexed with 256 entry palett

Re: [PATCH] drm/bochs: Add screen blanking support

> > However, a tricky part is that the QEMU vga code does treat VGA_ATT_IW > > register always as "flip-flop"; the first write is for index and the > > second write is for the data like palette. Meanwhile, in the current > > bochs DRM driver, the flip-flop wasn't considered, and it calls only > >

Re: [PATCH v2] drm/bochs: Add screen blanking support

> > I'm fine to change in any better way, of course, so feel free to > > modify the patch. > > If no one objects, I'll merge it as-is. It's somewhat wrong wrt to VGA, but > apparently what qemu wants. No objections. Acked-by: Gerd Hoffmann FYI: cirrus is in

Re: [PATCH] drm/virtio: support mapping exported vram

Hi, > +static struct sg_table *virtgpu_gem_map_dma_buf( > + struct dma_buf_attachment *attach, > + enum dma_data_direction dir) checkpatch doesn't like that: -:47: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' #47: FILE: drivers/gpu/drm/virtio/virtgpu_prime.c:4

Re: [PATCH] drm/virtio: set non-cross device blob uuid_state

On Wed, Aug 11, 2021 at 01:04:01PM +0900, David Stevens wrote: > Blob resources without the cross device flag don't have a uuid to share > with other virtio devices. When exporting such blobs, set uuid_state to > STATE_ERR so that virtgpu_virtio_get_uuid doesn't hang. > > Signed-off-by: David Stev

Re: Why we didn't use embedded gem object for virtio gpu when making ttm bo a gem bo subclass?

there some specific reason? commit c66df701e783bc666593e6e665f13670760883ee Author: Gerd Hoffmann Date: Thu Aug 29 12:32:57 2019 +0200 drm/virtio: switch from ttm to gem shmem helpers HTH, Gerd

Re: Why we didn't use embedded gem object for virtio gpu when making ttm bo a gem bo subclass?

On Sun, Aug 15, 2021 at 09:51:02PM -0700, lepton wrote: > Hi Gerd, > > Thanks for your reply. I was aware of that change, but need a fix for > 5.4 kernel as a temp solution for now. > If the reason is just that you will move away from ttm soon,then I > guess a CL like http://crrev.com/c/3092457 sh

Re: [PATCH v2] drm/virtio: support mapping exported vram

On Fri, Aug 13, 2021 at 09:54:41AM +0900, David Stevens wrote: > Implement virtgpu specific map_dma_buf callback to support mapping > exported vram object dma-bufs. The dma-buf callback is used directly, as > vram objects don't have backing pages and thus can't implement the > drm_gem_object_funcs.

Re: [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs

On Tue, Mar 30, 2021 at 08:04:38PM -0700, Vivek Kasireddy wrote: > If support for Blob resources is available, then dumb BOs created > by the driver can be considered as guest Blobs. And, for guest > Blobs, there is no need to do any transfers or flushes No. VIRTGPU_BLOB_FLAG_USE_SHAREABLE means

Re: [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob

Hi, > -#define MAX_INLINE_CMD_SIZE 96 > +#define MAX_INLINE_CMD_SIZE 112 Separate patch please. > --- a/include/uapi/linux/virtio_gpu.h > +++ b/include/uapi/linux/virtio_gpu.h > @@ -409,6 +409,7 @@ struct virtio_gpu_set_scanout_blob { > __le32 width; > __le32 height; > __

Re: [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs

Hi, > > No. VIRTGPU_BLOB_FLAG_USE_SHAREABLE means the host (aka device in virtio > > terms) *can* create a shared mapping. So, the guest sends still needs to > > send transfer > > commands, and then the device can shortcut the transfer commands on the > > host side in > > case a shared mappi

[PATCH v3 2/4] drm/qxl: unpin release objects

Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index 0fcfc952d5e9

[PATCH v3 0/4] drm/qxl: fix some driver shutdown issues.

Some progress. Not complete though, I still get an unclean mm warning on shutdown due to some release objects not being freed yet. Gerd Hoffmann (4): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary

[PATCH v3 4/4] drm/qxl: handle shadow in primary destroy

qxl_primary_atomic_disable must check whenever the framebuffer bo has a shadow surface and in case it has check the shadow primary status. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c

[PATCH v3 3/4] drm/qxl: release shadow on shutdown

In case we have a shadow surface on shutdown release it so it doesn't leak. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 38d6b59

[PATCH v3 1/4] drm/qxl: use drmm_mode_config_init

Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter --- drivers/gpu/drm/qxl/qxl_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 012bce0cdb65..38d6b596094d 100644 --- a/drivers/gpu

Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver

Hi, > > > > > + select TRACE_GPU_MEM > > > > > +#ifdef CONFIG_TRACE_GPU_MEM That doesn't make sense btw. > > > > > +#ifdef CONFIG_TRACE_GPU_MEM > > > > > +static inline void virtio_gpu_trace_total_mem(struct > > > > > virtio_gpu_device *vgdev, > > > > > +

Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver

On Wed, Jan 20, 2021 at 10:52:11AM -0800, Yiwei Zhang wrote: > On Wed, Jan 20, 2021 at 5:33 AM Gerd Hoffmann wrote: > > > > Hi, > > > > > > > > > + select TRACE_GPU_MEM > > > > > > > > > +#ifdef CONFIG_TRACE_GPU_MEM >

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote: > Hi > > Am 20.01.21 um 12:12 schrieb Gerd Hoffmann: > > Balances the qxl_create_bo(..., pinned=true, ...); > > call in qxl_release_bo_alloc(). > > > > Signed-off-by: Gerd Hoffmann > > ---

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

it > to 0 kinda defeats the warning. Figured the unpin is at the completely wrong place while trying to reproduce the lockdep splat ... take care, Gerd >From 43befab4a935114e8620af62781666fa81288255 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Mon, 25 Jan 2021 13:10:50 +0100 Subje

[PATCH v4 0/5] drm/qxl: fix driver shutdown issues.

0x120 [qxl] drm_minor_release+0x3d/0x60 but I don't think this is the qxl driver's fault. Gerd Hoffmann (5): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary destroy drm/qxl: properly free qxl releases

[PATCH v4 2/5] drm/qxl: unpin release objects

Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index c52412724c26

[PATCH v4 4/5] drm/qxl: handle shadow in primary destroy

qxl_primary_atomic_disable must check whenever the framebuffer bo has a shadow surface and in case it has check the shadow primary status. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c

[PATCH v4 3/5] drm/qxl: release shadow on shutdown

In case we have a shadow surface on shutdown release it so it doesn't leak. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 38d6b59

[PATCH v4 1/5] drm/qxl: use drmm_mode_config_init

Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 012bce0cdb65

[PATCH v4 5/5] drm/qxl: properly free qxl releases

Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/qxl/qxl_kms.c | 22 -- drivers/gpu/drm/qxl/qxl_release.c | 2 ++ 3 files changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl

Re: [PATCH v4 5/5] drm/qxl: properly free qxl releases

> > + /* > > +* Ask host to release resources (+fill release ring), > > +* then wait for the release actually happening. > > +*/ > > + qxl_io_notify_oom(qdev); > > + for (try = 0; try < 20 && atomic_read(&qdev->release_count) > 0; try++) > > + msleep(20); > > A bit icky

[PATCH v5 1/6] drm/qxl: use drmm_mode_config_init

Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 012bce0cdb65

[PATCH v5 0/6] drm/qxl: fix driver shutdown issues.

0x120 [qxl] drm_minor_release+0x3d/0x60 but I don't think this is the qxl driver's fault. v5: - add release_event wait queue. - also cleanup qxl_fence_wait(). Gerd Hoffmann (6): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/q

[PATCH v5 3/6] drm/qxl: release shadow on shutdown

In case we have a shadow surface on shutdown release it so it doesn't leak. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 38d6b59

[PATCH v5 2/6] drm/qxl: unpin release objects

Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index c52412724c26

[PATCH v5 6/6] drm/qxl: simplify qxl_fence_wait

Now that we have the new release_event wait queue we can just use that in qxl_fence_wait() and simplify the code alot. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 42 +++ 1 file changed, 4 insertions(+), 38 deletions(-) diff --git a/drivers

[PATCH v5 5/6] drm/qxl: properly free qxl releases

Reorganize qxl_device_fini() a bit. Add missing unpin() calls. Count releases. Add wait queue for releases. That way qxl_device_fini() can easily wait until everything is ready for proper shutdown. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_drv.h | 2 ++ drivers/gpu/drm

[PATCH v5 4/6] drm/qxl: handle shadow in primary destroy

qxl_primary_atomic_disable must check whenever the framebuffer bo has a shadow surface and in case it has check the shadow primary status. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c

[PATCH v6 04/10] drm/qxl: unpin release objects

Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl

[PATCH v6 00/10] drm/qxl: fix driver shutdown issues.

v5: - add release_event wait queue. - also cleanup qxl_fence_wait(). v6: - add shadow pinning fix (Thomas). - use ram for dumb allocation. Gerd Hoffmann (10): [hack] silence ttm fini WARNING Revert "drm/qxl: do not run release if qxl failed to init" drm/qxl: use drmm_mode_c

[PATCH v6 03/10] drm/qxl: use drmm_mode_config_init

Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 012bce0cdb65

[PATCH v6 01/10] [hack] silence ttm fini WARNING

kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put() is being called. WARNING: CPU: 0 PID: 209 at lib/kobject.c:750 kobject_put+0x3a/0x60 [ ... ] Call Trace: ttm_device_fini+0x133/0x1b0 [ttm] qxl_ttm_fini+0x2f/0x40 [qxl] --- drivers/gpu/drm/ttm/ttm_device.c | 2 +- 1 file

[PATCH v6 10/10] drm/qxl: allocate dumb buffers in ram

dumb buffers are shadowed anyway, so there is no need to store them in device memory. Use QXL_GEM_DOMAIN_CPU (TTM_PL_SYSTEM) instead. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_dumb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl

[PATCH v6 02/10] Revert "drm/qxl: do not run release if qxl failed to init"

This reverts commit b91907a6241193465ca92e357adf16822242296d. Patch is broken, it effectively makes qxl_drm_release() a nop because on normal driver shutdown qxl_drm_release() is called *after* drm_dev_unregister(). Cc: Tong Zhang Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_drv.c

[PATCH v6 09/10] drm/qxl: simplify qxl_fence_wait

Now that we have the new release_event wait queue we can just use that in qxl_fence_wait() and simplify the code alot. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_release.c | 44 +++ 1 file changed, 4 insertions(+), 40

[PATCH v6 06/10] drm/qxl: properly pin/unpin shadow

Suggested-by: Thomas Zimmermann Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 60331e31861a..d25fd3acc891 100644 --- a/drivers/gpu/drm/qxl

[PATCH v6 05/10] drm/qxl: release shadow on shutdown

In case we have a shadow surface on shutdown release it so it doesn't leak. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 38d6b59

[PATCH v6 07/10] drm/qxl: handle shadow in primary destroy

qxl_primary_atomic_disable must check whenever the framebuffer bo has a shadow surface and in case it has check the shadow primary status. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a

[PATCH v6 08/10] drm/qxl: properly free qxl releases

Reorganize qxl_device_fini() a bit. Add missing unpin() calls. Count releases. Add wait queue for releases. That way qxl_device_fini() can easily wait until everything is ready for proper shutdown. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_drv.h

Re: [PATCH v6 01/10] [hack] silence ttm fini WARNING

On Thu, Feb 04, 2021 at 03:58:33PM +0100, Christian König wrote: > ? > > What's the background here? > > Christian. > > Am 04.02.21 um 15:57 schrieb Gerd Hoffmann: > > kobject: '(null)' ((ptrval)): is not initialized, yet kobject_put() > &g

Re: [PATCH v2] drm/qxl: do not run release if qxl failed to init

On Thu, Feb 04, 2021 at 11:30:50AM -0500, Tong Zhang wrote: > if qxl_device_init() fail, drm device will not be registered, > in this case, do not run qxl_drm_release() How do you trigger this? take care, Gerd ___ dri-devel mailing list dri-devel@lis

Re: [PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers

Hi, > I smoke-tested the code by running fbdev, Xorg and weston with the > converted mgag200 driver. Looks sane to me. Survived cirrus smoke test too. Tested-by: Gerd Hoffmann Acked-by: Gerd Hoffmann take care, Gerd ___ dri-devel mailin

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

Hi, > > +/* extract pages referenced by sgt */ > > +static struct page **extr_pgs(struct sg_table *sgt, int *nents, int > > *last_len) > > Nack, this doesn't work on dma-buf. And it'll blow up at runtime when you > enable the very recently merged CONFIG_DMABUF_DEBUG (would be good to test > wi

[PATCH] drm/qxl: properly handle device init failures

Specifically do not try release resources which where not allocated in the first place. Cc: Tong Zhang Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ drivers/gpu/drm/qxl/qxl_kms.c | 4 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/qxl

Re: [PATCH 0/6] drm: Move vmap out of commit tail for SHMEM-based drivers

On Sun, Feb 07, 2021 at 07:33:24PM +0100, Thomas Zimmermann wrote: > Hi > > Am 05.02.21 um 10:05 schrieb Gerd Hoffmann: > >Hi, > > > > > I smoke-tested the code by running fbdev, Xorg and weston with the > > > converted mgag200 driver. > > &g

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

Hi, > > > > Nack, this doesn't work on dma-buf. And it'll blow up at runtime > > > > when you enable the very recently merged CONFIG_DMABUF_DEBUG (would > > > > be good to test with that, just to make sure). > [Kasireddy, Vivek] Although, I have not tested it yet but it looks like this > will >

Re: [PATCH] drm/qxl: properly handle device init failures

On Mon, Feb 08, 2021 at 12:07:01PM -0500, Tong Zhang wrote: > Does this patch fix an issue raised previously? Or should they be used > together? > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2466541.html > > IMHO using this patch alone won’t fix the issue This patch on top of d

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

> > You don't have to use the rendering pipeline. You can let the i915 gpu > > render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for > > buffer sharing with the host. > [Kasireddy, Vivek] Is this the most viable path forward? I am not sure how > complex or > feasible it woul

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

Hi, > This is because of the fundamental concept of DMA-buf that the exporter > needs to setup mappings (both CPU page tables as well as stuff like IOMMU). > When the guest exports something it would mean that you give the guest > control over the IOMMU and/or host page tables. And that is not s

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

On Fri, Feb 12, 2021 at 08:15:12AM +, Kasireddy, Vivek wrote: > Hi Gerd, > > > > > You don't have to use the rendering pipeline. You can let the i915 > > > > gpu render into a dma-buf shared with virtio-gpu, then use > > > > virtio-gpu only for buffer sharing with the host. > [Kasireddy, Vive

[PATCH 02/10] drm/qxl: more fence wait rework

Move qxl_io_notify_oom() call into wait condition. That way the driver will call it again if one call wasn't enough. Also allows to remove the extra dma_fence_is_signaled() check and the goto. Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") Signed-off-by: Gerd Hoffmann -

[PATCH 00/10] drm/qxl: a collection of fixes

Mostly around locking. Gerd Hoffmann (10): drm/qxl: properly handle device init failures drm/qxl: more fence wait rework drm/qxl: use ttm bo priorities drm/qxl: fix lockdep issue in qxl_alloc_release_reserved drm/qxl: rename qxl_bo_kmap -> qxl_bo_kmap_locked drm/qxl: add qxl_bo_k

[PATCH 04/10] drm/qxl: fix lockdep issue in qxl_alloc_release_reserved

Call qxl_bo_unpin (which does a reservation) without holding the release_mutex lock. Fixes lockdep (correctly) warning on a possible deadlock. Fixes: 65ffea3c6e73 ("drm/qxl: unpin release objects") Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 13 ++-

[PATCH 03/10] drm/qxl: use ttm bo priorities

() picks something which can't be evicted and throws an error after waiting a while without success. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 1 + drivers/gpu/drm/qxl/qxl_cmd.c | 2 +- drivers/gpu/drm/qxl/qxl_display.c | 4 ++-- drivers/gpu/drm/qxl/qxl_gem.c

[PATCH 06/10] drm/qxl: add qxl_bo_kmap/qxl_bo_kunmap

Add kmap/kunmap variants which reserve (and pin) the bo. They can be used in case the caller doesn't hold a reservation for the bo. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 2 ++ drivers/gpu/drm/qxl/qxl_object.c | 36 2 files ch

[PATCH 07/10] drm/qxl: fix prime kmap

Use the correct kmap variant. We don't have a reservation here, so we can't use the _locked version. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_prime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/g

[PATCH 10/10] drm/qxl: add lock asserts to qxl_bo_kmap_locked + qxl_bo_kunmap_locked

Try avoid re-introducing locking bugs. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c index 22748b9566af..90d5e5b7f927 100644 --- a/drivers/gpu/drm/qxl

[PATCH 08/10] drm/qxl: fix monitors object kmap

Use the correct kmap variant. We don't hold a reservation here, so we can't use the _locked variant. We can drop the pin because qxl_bo_kmap will do that for us. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 7 ++- 1 file changed, 2 insertions(+), 5

[PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.

We don't have to map in atomic_update callback then, making locking a bit less complicated. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gp

[PATCH 05/10] drm/qxl: rename qxl_bo_kmap -> qxl_bo_kmap_locked

Make clear that these functions should be called with reserved bo's only. No functional change. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 4 ++-- drivers/gpu/drm/qxl/qxl_display.c | 14 +++--- drivers/gpu/drm/qxl/qxl_draw.c| 8 drivers/gp

[PATCH 01/10] drm/qxl: properly handle device init failures

Specifically do not try release resources which where not allocated in the first place. Cc: Tong Zhang Tested-by: Tong Zhang Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ drivers/gpu/drm/qxl/qxl_kms.c | 4 2 files changed, 7 insertions(+) diff --git a

Re: [PATCH v2 00/10] drm/ast: Clean-up cursor-plane updates

> v2: > * convert to drm_shadow_plane_state helpers Looks all sane to me. Acked-by: Gerd Hoffmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.

On Tue, Feb 16, 2021 at 02:46:21PM +0100, Thomas Zimmermann wrote: > > > Am 16.02.21 um 14:27 schrieb Thomas Zimmermann: > > Hi > > > > this is a shadow-buffered plane. Did you consider using the new helpers > > for shadow-buffered planes? They will map the user BO for you and > > provide the ma

[PATCH v2 00/11] drm/qxl: a collection of fixes

Mostly around locking. v2: - use 'vmap' instead of 'kmap'. - rework cursor update workflow. Gerd Hoffmann (11): drm/qxl: properly handle device init failures drm/qxl: more fence wait rework drm/qxl: use ttm bo priorities drm/qxl: fix lockdep issue in qxl_alloc_re

[PATCH v2 01/11] drm/qxl: properly handle device init failures

Specifically do not try release resources which where not allocated in the first place. Cc: Tong Zhang Tested-by: Tong Zhang Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ drivers/gpu/drm/qxl/qxl_kms.c | 4 2 files changed, 7

[PATCH v2 07/11] drm/qxl: fix prime vmap

Use the correct vmap variant. We don't have a reservation here, so we can't use the _locked version. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_prime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/g

[PATCH v2 10/11] drm/qxl: rework cursor plane

Add helper functions to create and move the cursor. Create the cursor_bo in prepare_fb callback, in the atomic_commit callback we only send the update command to the host. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 248 -- 1 file changed

[PATCH v2 04/11] drm/qxl: fix lockdep issue in qxl_alloc_release_reserved

Call qxl_bo_unpin (which does a reservation) without holding the release_mutex lock. Fixes lockdep (correctly) warning on a possible deadlock. Fixes: 65ffea3c6e73 ("drm/qxl: unpin release objects") Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 13 ++-

[PATCH v2 03/11] drm/qxl: use ttm bo priorities

() picks something which can't be evicted and throws an error after waiting a while without success. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 1 + drivers/gpu/drm/qxl/qxl_cmd.c | 2 +- drivers/gpu/drm/qxl/qxl_display.c | 4 ++-- drivers/gpu/drm/qxl/qxl_gem.c

[PATCH v2 06/11] drm/qxl: add qxl_bo_vmap/qxl_bo_vunmap

Add vmap/vunmap variants which reserve (and pin) the bo. They can be used in case the caller doesn't hold a reservation for the bo. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 2 ++ drivers/gpu/drm/qxl/qxl_object.c | 36 2 files ch

[PATCH v2 11/11] drm/qxl: add lock asserts to qxl_bo_vmap_locked + qxl_bo_vunmap_locked

Try avoid re-introducing locking bugs. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann --- drivers/gpu/drm/qxl/qxl_object.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c index 82c3bf195ad6..6e26d70f2f07

[PATCH v2 02/11] drm/qxl: more fence wait rework

Move qxl_io_notify_oom() call into wait condition. That way the driver will call it again if one call wasn't enough. Also allows to remove the extra dma_fence_is_signaled() check and the goto. Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") Signed-off-by: Gerd Hoffmann -

[PATCH v2 05/11] drm/qxl: rename qxl_bo_kmap -> qxl_bo_vmap_locked

Append _locked to Make clear that these functions should be called with reserved bo's only. While being at it also rename kmap -> vmap. No functional change. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_object.h | 4 ++-- drivers/gpu/drm/qxl/qxl_displa

[PATCH v2 09/11] drm/qxl: move shadow handling to new qxl_prepare_shadow()

Pure code motion, no functional change. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 61 +-- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index

[PATCH v2 08/11] drm/qxl: fix monitors object vmap

Use the correct vmap variant. We don't hold a reservation here, so we can't use the _locked variant. We can drop the pin because qxl_bo_vmap will do that for us. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 7 ++- 1 file changed, 2 insertions(+), 5

Re: [PATCH v2 10/11] drm/qxl: rework cursor plane

Hi, > I'm still trying to wrap my head around the qxl cursor code. > > Getting vmap out of the commit tail is good, but I feel like this isn't > going in the right direction overall. > > In ast, these helper functions were only good when converting the drvier to > atomic modesetting. So I remo

Re: [PATCH v2 10/11] drm/qxl: rework cursor plane

Hi, > > Well. I suspect I could easily spend a month cleaning up and party > > redesign the qxl driver (specifically qxl_draw.c + qxl_image.c). > > > > I'm not sure I'll find the time to actually do that anytime soon. > > I have plenty of other stuff on my TODO list, and given that the > > wor

Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode

On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote: > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini > wrote: > > > > Add a virtual hardware or vblank-less mode as a module to enable > > VKMS to emulate virtual graphic drivers. This mode can be enabled > > by setting enable_virtua

Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode

On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote: > On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote: > > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote: > > > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini > > > wrote: &g

Re: drm/ttm: ttm_bo_release called without lock

On Thu, Mar 04, 2021 at 08:42:55AM +0100, Thomas Zimmermann wrote: > (cc'ing Gerd) > > This might be related to the recent clean-up patches for the BO handling in > qxl. Yes, it is. Fixed in drm-misc-next, cherry-picked into drm-misc-fixes, hopefully lands in -rc2. take care, Gerd __

Re: [PATCH] drm/ttm: soften TTM warnings

r pointless, qxl fix for this one is already queued in drm-misc-fixes so this would only land after the qxl fixes ... But I think using WARN_ON_ONCE() is a good idea in general, especially in a code path like this where a single bug can easily cause a flood of stack traces.

Re: [PATCH] qxl: Fix uninitialised struct field head.surface_id

On Thu, Mar 04, 2021 at 09:49:28AM +, Colin King wrote: > From: Colin Ian King > > The surface_id struct field in head is not being initialized and > static analysis warns that this is being passed through to > dev->monitors_config->heads[i] on an assignment. Clear up this > warning by initia

Re: [PATCH] drm/virtio: fix possible leak/unlock virtio_gpu_object_array

On Fri, Mar 05, 2021 at 11:18:19PM +0800, xndcn wrote: > virtio_gpu_object array is not freed or unlocked in some > failed cases. Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedeskt

  1   2   3   4   5   6   7   8   9   10   >