| Message ID | 20230720120816.8751-1-Jiqian.Chen@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | S3 support | expand |
Hi all, Please forgive me for asking. Do you have any other comments on my latest version patches about virtio-gpu S3 on Xen? Looking forward to your reply. On 2023/7/20 20:08, Jiqian Chen wrote: > v4: > > Hi all, > Thanks for Gerd Hoffmann's advice. V4 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. > > latest version on kernel side: > https://lore.kernel.org/lkml/20230720115805.8206-1-Jiqian.Chen@amd.com/T/#t > > Best regards, > Jiqian Chen. > > > v3: > link, > https://lore.kernel.org/qemu-devel/20230719074726.1613088-1-Jiqian.Chen@amd.com/T/#t > > Hi all, > Thanks for Michael S. Tsirkin's advice. V3 makes below changes: > * Remove changes in file include/standard-headers/linux/virtio_gpu.h > I am not supposed to edit this file and it will be imported after > the patches of linux kernel was merged. > > > v2: > link, > https://lore.kernel.org/qemu-devel/20230630070016.841459-1-Jiqian.Chen@amd.com/T/#t > > 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 virtio_gpu_device_unrealize to destroy resources to solve > potential memory leak problem. This also needs hot-plug support. > * Add a new feature flag VIRTIO_GPU_F_FREEZING, so that guest and > host can negotiate whenever freezing is supported or not. > > v1: > link, > https://lore.kernel.org/qemu-devel/20230608025655.1674357-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 shown a > black screen. > > Through reading codes, I founded that when guest was during suspending, > it called into Qemu to call virtio_gpu_gl_reset. In virtio_gpu_gl_reset, > it destroyed all resources and reset renderer. This made the display > gone after guest resumed. > > I think we should keep resources or prevent they being destroyed when > guest is suspending. So, I add a new status named freezing to virtgpu, > and add a new ctrl message VIRTIO_GPU_CMD_STATUS_FREEZING to get > notification from guest. If freezing is set to true, and then Qemu will > realize that guest is suspending, it will not destroy resources and will > not reset renderer. If freezing is set to false, Qemu will do its origin > actions, and has no other impaction. > > And now, display can come back and applications can continue their > status after guest resumes. > > Jiqian Chen (1): > virtgpu: do not destroy resources when guest suspend > > hw/display/virtio-gpu-base.c | 3 ++ > hw/display/virtio-gpu-gl.c | 10 ++++++- > hw/display/virtio-gpu-virgl.c | 7 +++++ > hw/display/virtio-gpu.c | 55 ++++++++++++++++++++++++++++++++-- > hw/virtio/virtio.c | 3 ++ > include/hw/virtio/virtio-gpu.h | 6 ++++ > 6 files changed, 81 insertions(+), 3 deletions(-) >