RE: [VIRTIO GPU PATCH v3 0/1] Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Parav Pandit <parav@nvidia.com>]

> From: Chen, Jiqian <Jiqian.Chen@amd.com>
> Sent: Wednesday, August 2, 2023 11:28 AM
> 
> On 2023/8/2 12:49, Parav Pandit wrote:
> >
> >
> >> From: virtio-dev@lists.oasis-open.org
> >> <virtio-dev@lists.oasis-open.org> On Behalf Of Chen, Jiqian
> >> Sent: Wednesday, August 2, 2023 8:51 AM Hi all,
> >>
> >> Do you have any other comments on the modification of virtio-gpu S3?
> >> Looking forward to your reply and comments.
> >>
> 
> Hi Parav Pandit,
> Thank you for your reply. Let me try to answer your question.
> 
> > I am not familiar with the GPU, so a dumb question is, why the S3 state is gpu
> specific?
> S3 state is not gpu specific. I think different virtio devices may have different
> actions/problems when S3.
I am making assumption that the gpu device is pci. :)
If so can you please use the transport specific notification from gpu guest driver to notify to qemu?

> When I do S3 on Xen, I found guest's display can't come back and the root cause
> is in virtio-gpu backend in QEMU.
> So, to solve that problem, I change codes to let guest notify QEMU virtio-gpu's
> suspend state, and then QEMU will not destroy resources that used for display.
> Please see attached kernel and QEMU patch links.
> For above reason, Gerd suggest me to add a new feature flag specifically for
> virtio-gpu, so that guest and host can negotiate whenever to enable above
> mechanism.
> 
> > Can a transport specific suspend state be used and apply to all virtio devices?
> Based on my limited knowledge. Different virtio devices have different virtio
> queues, my modifications let guest to notify QEMU by using virtio-gpu's control
> queue.
> Other virtio devices can't get that notification unless you can traverse all virtio
> devices and notify one by one, or other global method?
> But for now, this patch is to add a new feature flag just used for virtio-gpu.
> 
If this is done at the pci transport level, all the virtio device benefit from it without inventing in each device type.

> > And can you please add both the rationale to the commit message?
> Sure, I will expand the description of my commit message and add them.
> 
> >
> >> On 2023/7/20 20:18, 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.
> >>> * Explain in more detail
> >>>
> >>> And latest version on QEMU and Linux kernel side:
> >>> 	QEMU: https://lore.kernel.org/qemu-devel/20230720120816.8751-1-
> >> Jiqian.Chen@amd.com
> >>> 	Kernel:
> >>> https://lore.kernel.org/lkml/20230720115805.8206-1-Jiqian.Chen@amd.c
> >>> om
> >>> /T/#t
> >>>
> >>> Best regards,
> >>> Jiqian Chen.
> >>>
> >>>
> >>> v2:
> >>> link,
> >>> https://lists.oasis-open.org/archives/virtio-comment/202307/msg00160
> >>> .h
> >>> tml
> >>>
> >>> Hi all,
> >>> Thanks to Gerd Hoffmann for his suggestions. V2 makes below changes:
> >>> * Elaborate on the types of resources.
> >>> * Add some descriptions for S3 and S4.
> >>>
> >>>
> >>> v1:
> >>> link,
> >>> https://lists.oasis-open.org/archives/virtio-comment/202306/msg00595
> >>> .h
> >>> tml
> >>>
> >>> Hi all,
> >>> I am working to implement virtgpu S3 function on Xen.
> >>>
> >>> Currently on Xen, if we start a guest through Qemu with enabling
> >>> virtgpu, and then suspend and s3resume guest. We can find that the
> >>> guest kernel comes back, but the display doesn't. It just shown a black
> screen.
> >>>
> >>> That is because when guest was during suspending, it called into
> >>> Qemu and Qemu destroyed all resources and reset renderer. This made
> >>> the display gone after guest resumed.
> >>>
> >>> So, I add a mechanism that when guest is suspending, it will notify
> >>> Qemu, and then Qemu will not destroy resources. That can help
> >>> guest's display come back.
> >>>
> >>> As discussed and suggested by Robert Beckett and Gerd Hoffmann on v1
> >>> qemu's mailing list. Due to that mechanism needs cooperation between
> >>> guest and host. What's more, as virtio drivers by design paravirt
> >>> drivers, it is reasonable for guest to accept some cooperation with
> >>> host to manage suspend/resume. So I request to add a new feature
> >>> flag, so that guest and host can negotiate whenever freezing is supported or
> not.
> >>>
> >>> Jiqian Chen (1):
> >>>   virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3
> >>>
> >>>  device-types/gpu/description.tex | 42
> >>> ++++++++++++++++++++++++++++++++
> >>>  1 file changed, 42 insertions(+)
> >>>
> >>
> >> --
> >> Best regards,
> >> Jiqian Chen.
> 
> --
> Best regards,
> Jiqian Chen.