[RFC PATCH 0/2] Virtio-GPU suspend and resume

Kim, Dongwon dongwon.kim at intel.com
Mon May 5 19:38:52 UTC 2025


Hi Dmitry,

> Subject: Re: [RFC PATCH 0/2] Virtio-GPU suspend and resume
> 
> On 4/19/25 02:29, dongwon.kim at intel.com wrote:
> > From: Dongwon Kim <dongwon.kim at intel.com>
> >
> > This patch series introduces a freeze and restore mechanism for the
> > virtio-gpu driver:
> >
> > First patch adds `virtgpu_freeze` and `virtgpu_restore` functions.
> > These functions handle the deletion of virtio queues before suspension
> > and their recreation during the restoration process.
> >
> > Second patch implements a mechanism for restoring `virtio_gpu_object`
> instances.
> > This is necessary because the host (QEMU) deletes all associated
> > resources during the virtio-gpu reset, which occurs as part of the restoration
> process.
> >
> > These changes ensure that the virtio-gpu driver can properly handle
> > suspend and resume scenarios without resource loss.
> 
> Resetting GPU by QEMU on suspend sounds like a wrong behaviour. Are you
> talking about upstream QEMU?
> 
> Could you please point at the QEMU code where it handles virtio-gpu
> suspend/resume? Don't see where it happens.

[Kim, Dongwon] So I am using Ubuntu guest and whenever I suspend then resume, I see 
static void virtio_gpu_reset_bh(void *opaque) is being called. It is probably triggered
by virtio layer but I didn't look into it. Check the video please:
(https://drive.google.com/file/d/1D_JF9CzgCjzQZ3RcLAaNnUORqGj24_I9/view?usp=sharing)

> 
> I tried to apply your kernel patches and then suspend/resume guest kernel, it
> doesn't work:
> 
> virtio_gpu_transfer_to_host_2d: no backing storage 2
> [   22.909454] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response
> 0x1200 (command 0x105)
> virtio_gpu_transfer_to_host_2d: no backing storage 2
> [   23.169138] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response
> 0x1200 (command 0x105)

[Kim, Dongwon] I will check your failing case more closely. As you know, we use virtio-gpu device
only for display device, which means I tested this in that specific environment
although I thought it is generic enough...

> 
> Cc: +Alex Bennée +Akihiko Odaki
> 
> --
> Best regards,
> Dmitry

[Kim, Dongwon] Thanks!


More information about the dri-devel mailing list