Re: [PATCH v7 0/3] Virtio-GPU S4 support

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 2/25/26 20:06, Kim, Dongwon wrote:
> Hi Dmitry,
> 
>> -----Original Message-----
>> From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> Sent: Wednesday, February 25, 2026 8:06 AM
>> To: Kim, Dongwon <dongwon.kim@intel.com>; dri-devel@lists.freedesktop.org;
>> airlied@redhat.com; kraxel@redhat.com
>> Cc: nirmoyd@nvidia.com; Kasireddy, Vivek <vivek.kasireddy@intel.com>
>> Subject: Re: [PATCH v7 0/3] Virtio-GPU S4 support
>>
>> On 1/7/26 21:27, dongwon.kim@intel.com wrote:
>>> From: Dongwon Kim <dongwon.kim@intel.com>
>>>
>>> This patch series implements functions for .freeze and .restore hooks
>>> for virtio-gpu driver as well as pm-notifier to handle object
>>> restoration in
>>> S4(hiberation) case.
>>>
>>> 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
>> hiberation/resume process.
>>>
>>> Third patch adds pm-notifier to the driver that handles resubmission
>>> of virtio-gpu objects to the QEMU once the guest resumes from hibenation.
>>>
>>> These changes ensure that the virtio-gpu driver can properly handle
>>> hibernation scenarios without resource loss.
>>>
>>> v2: 10ms sleep is added in virtgpu_freeze to avoid the situation
>>>     the driver is locked up during resumption.
>>>
>>> v3: Plain 10ms delay (v2) is replaced with wait calls which wait until
>>>     the virtio queue is empty.
>>>     (Dmitry Osipenko)
>>>
>>> v4: New version of patchset only covers S4 case because loss of resources in
>> S3
>>>     case can be avoided by skipping virtio-gpu-reset in QEMU
>> (hw/display/virtio-gpu.c).
>>>     To skip virtio-gpu-reset (soft-reset), virtio-gpu-pci device should be
>> attached to
>>>     PCIE bus AND a PCIE option, 'x-pcie-pm-no-soft-reset' should added and set
>> to 'true'.
>>>     (e.g. -device
>>> virtio-gpu-pci,bus=port,x-pcie-pm-no-soft-reset=true)
>>>
>>> v5: Remove virtio_gpu_object from the restore list before freeing the object
>>>     to prevent an use-after-free situation.
>>>     (Nirmoy Das)
>>>
>>>     Protect restore list operations with a spinlock
>>>     (Nirmoy Das)
>>>
>>>     Move restore list node into virtio_gpu_bo struct to reduce memory usage
>>>     (Dmitry Osipenko)
>>>
>>>     Remove unused header - drm_atomic_helper.h
>>>     (Dmitry Osipenko)
>>>
>>> v6: Include object backed by imported dmabuf
>>>     (Dmitry Osipenko)
>>>
>>>     Not storing virgl objects in the restore_list as virgl 3D objects are not
>>>     recoverable.
>>>     (Dmitry Osipenko)
>>>
>>>     Change the name 'list',a node in restore_list to 'restore_node'
>>>     (Nirmoy Das)
>>>
>>>     Use mutex instead of spinlock when updating restore_list
>>>     (Nirmoy Das)
>>>
>>>     Initialize restore_node when virtio_gpu_object is created - this is to
>>>     check if the node is in the list with 'list_empty' before removing it.
>>>
>>>     Restoring objects in the PM notifier is too late, as virtio-gpu
>>>     message communication begins in virtgpu_restore once virtqueues
>>>     are re-established. To address this, a 'hibernation' flag is set
>>>     during the PM_HIBERNATION_PREPARE phase in the notifier. This flag
>>>     is then used in virtgpu_restore to detect if the system is resuming
>>>     from S4, allowing objects to be recovered immediately after virtqueues
>>>     are reconfigured.
>>>
>>> v7: Add a helper, virtio_gpu_add_object_to_restore_list
>>>     (Dmitry Osipenko)
>>>
>>>     Unreference all objects before hibernation so they can be removed
>>>     on the host side, since they will be fully restored anyway. This
>>>     prevents the situation where host-side hibernation fails (leaving
>>>     all associated resources still alive) while the virtio-gpu driver
>>>     still attempts to restore those objects.
>>>     (Dmitry Osipenko)
>>>
>>> Dongwon Kim (3):
>>>   drm/virtio: Freeze and restore hooks to support suspend and resume
>>>   drm/virtio: Add support for saving and restoring virtio_gpu_objects
>>>   drm/virtio: Add PM notifier to restore objects after hibernation
>>>
>>>  drivers/gpu/drm/virtio/virtgpu_drv.c    | 74 +++++++++++++++++++++-
>>>  drivers/gpu/drm/virtio/virtgpu_drv.h    | 23 ++++++-
>>>  drivers/gpu/drm/virtio/virtgpu_kms.c    | 54 ++++++++++++++--
>>>  drivers/gpu/drm/virtio/virtgpu_object.c | 83
>>> ++++++++++++++++++++++++-  drivers/gpu/drm/virtio/virtgpu_prime.c  | 43
>> ++++++++++++-
>>>  drivers/gpu/drm/virtio/virtgpu_vq.c     | 13 +++-
>>>  drivers/gpu/drm/virtio/virtgpu_vram.c   |  4 +-
>>>  7 files changed, 280 insertions(+), 14 deletions(-)
>>>
>>
>> Hello Kim,
>>
>> Want let you know that I've seen the patches, but didn't have enough time to
>> review and test them. Will try to do it sooner. Will leave couple comments for
>> now.
>>
>> Meanwhile there is a kernel bot bug report.
> 
> Thanks for the comment. No problem. I will wait for your test results then create V8 based on
> your feedback including what you just left for individual patches (function/variable
> names..etc.)
> 
> I thought I got an error report for the previous version but I will double check.

Thanks for your patience and sending v8, will test it. There other
patches in my queue, hopefully it will get untangled sooner.

-- 
Best regards,
Dmitry