[LINUX KERNEL PATCH v3 0/1] add S3 support for virtgpu

[Chen, Jiqian]

Hi all,
Sorry for the late update of the v4 patches on Qemu side: https://lore.kernel.org/qemu-devel/20230720120816.8751-1-Jiqian.Chen@amd.com/ .
And I have created an "issue" in the Qemu gitlab for tracing this problem: https://gitlab.com/qemu-project/qemu/-/issues/1860.
Do you have any other comments about my patches ? Or any guidance on what I should do next? I am looking forward to getting reply from you.

On 2023/7/20 19:58, Jiqian Chen wrote:
> v3:
> Hi all,
> Thanks for Gerd Hoffmann's advice. V3 makes below changes:
> * Use enum for freeze mode, so this can be extended with more
>   modes in the future.
> * Rename functions and paratemers with "_S3" postfix.
> And no functional changes.
> 
> Best regards,
> Jiqian Chen.
> 
> 
> v2:
> 
> Hi all,
> Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
> their advice and guidance. V2 makes below changes:
> * Change VIRTIO_CPU_CMD_STATUS_FREEZING to 0x0400 (<0x1000)
> * Add a new feature flag VIRTIO_GPU_F_FREEZING, so that guest and
>   host can negotiate whenever freezing is supported or not.
> 
> V2 of Qemu patch:
> https://lore.kernel.org/qemu-devel/20230630070016.841459-1-Jiqian.Chen@amd.com/T/#t
> 
> 
> v1:
> 
> link,
> https://lore.kernel.org/lkml/20230608063857.1677973-1-Jiqian.Chen@amd.com/
> 
> Hi all,
> I am working to implement virtgpu S3 function on Xen.
> 
> Currently on Xen, if we start a guest who enables virtgpu, and then
> run "echo mem > /sys/power/state" to suspend guest. And run
> "sudo xl trigger <guest id> s3resume" to resume guest. We can find that
> the guest kernel comes back, but the display doesn't. It just shows a
> black screen.
> 
> In response to the above phenomenon, I have found two problems.
> 
> First, if we move mouse on the black screen, guest kernel still sends a
> cursor request to Qemu, but Qemu doesn't response. Because when guest
> is suspending, it calls device_suspend, and then call into Qemu to call
> virtio_reset->__virtio_queue_reset. In __virtio_queue_reset, it clears
> all virtqueue information on Qemu end. So, after guest resumes, Qemu
> can't get message from virtqueue.
> 
> Second, the reason why display can't come back is that when guest is
> suspending, it calls into Qemu to call virtio_reset->virtio_gpu_gl_reset.
> In virtio_gpu_gl_reset, it destroys all resources and resets renderer,
> which are used for display. So after guest resumes, the display can't
> come back to the status when guest is suspended.
> 
> This patch initializes virtqueue when guest is resuming to solve first
> problem. And it notifies Qemu that guest is suspending to prevent Qemu
> destroying resources, this is to solve second problem. And then, I can
> bring the display back, and everything continues their actions after
> guest resumes.
> 
> Modifications on Qemu end:
> https://lore.kernel.org/qemu-devel/20230608025655.1674357-2-Jiqian.Chen@amd.com/
> 
> Jiqian Chen (1):
>   virtgpu: init vq during resume and notify qemu guest status
> 
>  drivers/gpu/drm/virtio/virtgpu_debugfs.c |  1 +
>  drivers/gpu/drm/virtio/virtgpu_drv.c     | 39 ++++++++++++++++++++++++
>  drivers/gpu/drm/virtio/virtgpu_drv.h     |  5 +++
>  drivers/gpu/drm/virtio/virtgpu_kms.c     | 36 ++++++++++++++++------
>  drivers/gpu/drm/virtio/virtgpu_vq.c      | 16 ++++++++++
>  include/uapi/linux/virtio_gpu.h          | 19 ++++++++++++
>  6 files changed, 107 insertions(+), 9 deletions(-)
> 

-- 
Best regards,
Jiqian Chen.