On 1/7/26 21:27, [email protected] wrote: > From: Dongwon Kim <[email protected]> > > 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. -- Best regards, Dmitry
