[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[QEMU PATCH v4 0/1] S3 support


  • To: Gerd Hoffmann <kraxel@xxxxxxxxxx>, Marc-André Lureau <marcandre.lureau@xxxxxxxxx>, "Michael S . Tsirkin" <mst@xxxxxxxxxx>, "Robert Beckett" <bob.beckett@xxxxxxxxxxxxx>, <qemu-devel@xxxxxxxxxx>
  • From: Jiqian Chen <Jiqian.Chen@xxxxxxx>
  • Date: Thu, 20 Jul 2023 20:08:15 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sQ9pj/iaxuUff0x3bnr1X9IpLfVr35JpB2JPJTt6P9c=; b=RxGAQrAtoAAP/NWWlV3mLMZpP5WP8OXV/NTUnygIajKL+9NuxlFW/93f/jmv8jisCANIu7tntTutCFP/SdNsyseASUMZZnjcKT4MJdqGjbkjx+ffMHRJY8FZEwVR0xrEWHhwzjjCB7oRK/krqnxgVXmLQ4cYg4nkb+I2UF5VOuzaH0BNz0RV67SGbz/iPmVxitf9qohVxP2zquvdq0Cx/nvd4RetWkSeV4tt+D9IFeDhUszkfclxCtTEue9QTLDQ1psS3htYdsEvifnbfdEJKX+2MV+CKb3Amrtkbz6TgWeAJhrzrgF19CETEqbkznwlpyCrK6Bpm/H/RX/2+pkgrg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bx+iNGstkIYsdm93IjChgam34Y741kYWQYAs5b1ZvWM+9Fg80nvtp+R0k/3yYHsxjMS+0mNVF/oIo5ovwrktWcj90k7thQnjVnETfqRFdRW6sxZwkjCxfIryiUfoGW7W9DSV26wPZR2wmj799PqPVjYywORUX2sj8plw4nt4mc8TJw+CCWBc5oLXo5wkDM2A901cOR+ZyNBIA3uGdZvokYX3bBNRupqMmUHDNkGFEcUuYQGWfEQ55ZG/rIwPTGli5nvkzqqtuKYkYGZWWpZ3o7huEsjOppL/XVIfZSk1urDPc4xC/0W4PK6+3z+i3cbZW0WLPdPxjE03O+1fCijuvA==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "Dr . David Alan Gilbert" <dgilbert@xxxxxxxxxx>, Alex Deucher <Alexander.Deucher@xxxxxxx>, Christian Koenig <Christian.Koenig@xxxxxxx>, Stewart Hildebrand <Stewart.Hildebrand@xxxxxxx>, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, Honglei Huang <Honglei1.Huang@xxxxxxx>, Julia Zhang <Julia.Zhang@xxxxxxx>, Huang Rui <Ray.Huang@xxxxxxx>, Jiqian Chen <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Thu, 20 Jul 2023 12:08:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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@xxxxxxx/T/#t

Best regards,
Jiqian Chen.


v3:
link,
https://lore.kernel.org/qemu-devel/20230719074726.1613088-1-Jiqian.Chen@xxxxxxx/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@xxxxxxx/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@xxxxxxx/

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(-)

-- 
2.34.1




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.