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

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

[Jiqian Chen]

Hi all,
I hope you’ll forgive me if this disturb you. Since it has been almost two
months since the latest patch was sent out, I didn't receive any reply, so I
rebase the latest master branch and sent it again. I am looking forward to
getting your response.

Best regards,
Jiqian Chen

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.com/T/#t


v2:
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.

Link:
https://lists.oasis-open.org/archives/virtio-comment/202307/msg00160.html
V2 of Qemu patch:
https://lore.kernel.org/qemu-devel/20230630070016.841459-1-Jiqian.Chen@amd.com/T/#t
V2 of Kernel patch:
https://lore.kernel.org/lkml/20230630073448.842767-1-Jiqian.Chen@amd.com/T/#t


v1:
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.

Link:
https://lists.oasis-open.org/archives/virtio-comment/202306/msg00595.html
V1 of Qemu patch:
https://lore.kernel.org/qemu-devel/20230608025655.1674357-2-Jiqian.Chen@amd.com/
V1 of Kernel patch:
https://lore.kernel.org/lkml/20230608063857.1677973-1-Jiqian.Chen@amd.com/

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

-- 
2.34.1

[RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Jiqian Chen]

When we suspend/resume guest on Xen, the display can't come back.
This is because when guest suspended, it called into Qemu. Then
Qemu destroyed all resources which is used for display. So that
guest's display can't come back to the time when it was suspended.

To solve above problem, I added a new mechanism that when guest is
suspending, it will notify Qemu, and then Qemu will not destroy
resourcesi which are created by using commands
VIRTIO_GPU_CMD_RESOURCE_CREATE_*.

Due to that mechanism needs cooperation between guest and host,
I need to add a new feature flag, so that guest and host can
negotiate whenever freeze_S3 is supported or not.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
---
 device-types/gpu/description.tex | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
index 4435248..1a137e7 100644
--- a/device-types/gpu/description.tex
+++ b/device-types/gpu/description.tex
@@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
   resources is supported.
 \item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
   synchronization timelines supported.  Requires VIRTIO_GPU_F_VIRGL.
+\item[VIRTIO_GPU_F_FREEZE_S3 (5)] freezing virtio-gpu and keeping resources
+  alive is supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -228,6 +230,9 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
         VIRTIO_GPU_CMD_MOVE_CURSOR,
 
+        /* freeze mode */
+        VIRTIO_GPU_CMD_SET_FREEZE_MODE = 0x0400,
+
         /* success responses */
         VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
         VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
@@ -838,6 +843,43 @@ \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device /
 
 \end{description}
 
+\subsubsection{Device Operation: freeze_mode}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: freeze_mode}
+
+\begin{lstlisting}
+typedef enum {
+  VIRTIO_GPU_FREEZE_MODE_UNFREEZE = 0,
+  VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 = 3,
+} virtio_gpu_freeze_mode_t;
+
+struct virtio_gpu_set_freeze_mode {
+  struct virtio_gpu_ctrl_hdr hdr;
+  virtio_gpu_freeze_mode_t freeze_mode;
+};
+\end{lstlisting}
+
+\begin{description}
+
+\item[VIRTIO_GPU_CMD_SET_FREEZE_MODE]
+Notify freeze mode through controlq.
+Request data is \field{struct virtio_gpu_set_freeze_mode}.
+Response type is VIRTIO_GPU_RESP_OK_NODATA.
+
+This is added for S3 function in guest with virtio-gpu. When guest does
+S3, let it notify QEMU that virtio-gpu is in what freeze mode in
+\field{freeze_mode}. VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 means guest is
+doing S3 and virtio-gpu will be freezed, VIRTIO_GPU_FREEZE_MODE_UNFREEZE
+means virtio-gpu can be used as usual. When virtio-gpu is freezed, QEMU
+will not destroy resources which are created by using commands
+VIRTIO_GPU_CMD_RESOURCE_CREATE_*, so that guest can use those resources
+to resume display.
+
+Note: this change is not enough to solve the problems of S4 function.
+QEMU may lose resources after hibernation. It needs more research and
+development. If S4 is supported in the future, it may need another
+feature flag here.
+
+\end{description}
+
 \subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility}
 
 Applies to Virtio Over PCI only.  The GPU device can come with and
-- 
2.34.1

Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Mikhail Golubev-Ciuchea]

Hi Jiqian,

Thanks for the proposal.

Some time ago I was working on the same issue with suspending the gpu device
(on arm).  Additionally, I had troubles with virtio-video device as well, see
https://lore.kernel.org/lkml/20211215172739.GA77225@opensynergy.com/T/ for
details.

In your case, the
VIRTIO_GPU_FREEZE_MODE_FREEZE_S3/VIRTIO_GPU_FREEZE_MODE_UNFREEZE do influence
how reset is being handled by Qemu, is this correct?  Since multiple devices
can benefit from the same mechanism, would it be possible to: a) have a more
generic, non ACPI-based name, b) make the feature generic, applicable to other
devices as well?


Best wishes,
Mikhail Golubev-Ciuchea



--

Mikhail Golubev-Ciuchea


OpenSynergy GmbH

Rotherstr. 20, 10245 Berlin

Telefon: +49 (30) 60 98 54 0 - 903

EMail:   mikhail.golubev@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B

Geschäftsführer/Managing Director: Regis Adjamah


________________________________________
From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> on behalf of Jiqian Chen <Jiqian.Chen@amd.com>
Sent: Monday, September 11, 2023 12:04 PM
To: Gerd Hoffmann; Marc-André Lureau; Robert Beckett; virtio-comment@lists.oasis-open.org; virtio-dev@lists.oasis-open.org
Cc: qemu-devel@nongnu.org; linux-kernel@vger.kernel.org; Stefano Stabellini; Roger Pau Monné; Alex Deucher; Christian Koenig; Stewart Hildebrand; Xenia Ragiadakou; Honglei Huang; Julia Zhang; Huang Rui; Jiqian Chen
Subject: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

When we suspend/resume guest on Xen, the display can't come back.
This is because when guest suspended, it called into Qemu. Then
Qemu destroyed all resources which is used for display. So that
guest's display can't come back to the time when it was suspended.

To solve above problem, I added a new mechanism that when guest is
suspending, it will notify Qemu, and then Qemu will not destroy
resourcesi which are created by using commands
VIRTIO_GPU_CMD_RESOURCE_CREATE_*.

Due to that mechanism needs cooperation between guest and host,
I need to add a new feature flag, so that guest and host can
negotiate whenever freeze_S3 is supported or not.

Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
---
 device-types/gpu/description.tex | 42 ++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
index 4435248..1a137e7 100644
--- a/device-types/gpu/description.tex
+++ b/device-types/gpu/description.tex
@@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
   resources is supported.
 \item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
   synchronization timelines supported.  Requires VIRTIO_GPU_F_VIRGL.
+\item[VIRTIO_GPU_F_FREEZE_S3 (5)] freezing virtio-gpu and keeping resources
+  alive is supported.
 \end{description}

 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -228,6 +230,9 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
         VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
         VIRTIO_GPU_CMD_MOVE_CURSOR,

+        /* freeze mode */
+        VIRTIO_GPU_CMD_SET_FREEZE_MODE = 0x0400,
+
         /* success responses */
         VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
         VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
@@ -838,6 +843,43 @@ \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device /

 \end{description}

+\subsubsection{Device Operation: freeze_mode}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: freeze_mode}
+
+\begin{lstlisting}
+typedef enum {
+  VIRTIO_GPU_FREEZE_MODE_UNFREEZE = 0,
+  VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 = 3,
+} virtio_gpu_freeze_mode_t;
+
+struct virtio_gpu_set_freeze_mode {
+  struct virtio_gpu_ctrl_hdr hdr;
+  virtio_gpu_freeze_mode_t freeze_mode;
+};
+\end{lstlisting}
+
+\begin{description}
+
+\item[VIRTIO_GPU_CMD_SET_FREEZE_MODE]
+Notify freeze mode through controlq.
+Request data is \field{struct virtio_gpu_set_freeze_mode}.
+Response type is VIRTIO_GPU_RESP_OK_NODATA.
+
+This is added for S3 function in guest with virtio-gpu. When guest does
+S3, let it notify QEMU that virtio-gpu is in what freeze mode in
+\field{freeze_mode}. VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 means guest is
+doing S3 and virtio-gpu will be freezed, VIRTIO_GPU_FREEZE_MODE_UNFREEZE
+means virtio-gpu can be used as usual. When virtio-gpu is freezed, QEMU
+will not destroy resources which are created by using commands
+VIRTIO_GPU_CMD_RESOURCE_CREATE_*, so that guest can use those resources
+to resume display.
+
+Note: this change is not enough to solve the problems of S4 function.
+QEMU may lose resources after hibernation. It needs more research and
+development. If S4 is supported in the future, it may need another
+feature flag here.
+
+\end{description}
+
 \subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility}

 Applies to Virtio Over PCI only.  The GPU device can come with and
--
2.34.1


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Chen, Jiqian]

Hi Mikhail Golubev-Ciuchea,

On 2023/9/12 00:33, Mikhail Golubev-Ciuchea wrote:
> Hi Jiqian,
> 
> Thanks for the proposal.
> 
> Some time ago I was working on the same issue with suspending the gpu device
> (on arm).  Additionally, I had troubles with virtio-video device as well, see
> https://lore.kernel.org/lkml/20211215172739.GA77225@opensynergy.com/T/ for
> details.
> 
> In your case, the
> VIRTIO_GPU_FREEZE_MODE_FREEZE_S3/VIRTIO_GPU_FREEZE_MODE_UNFREEZE do influence
> how reset is being handled by Qemu, is this correct?  Since multiple devices
Yes, it can affect the reset behavior of Qemu.

> can benefit from the same mechanism, would it be possible to: a) have a more
> generic, non ACPI-based name, b) make the feature generic, applicable to other
> devices as well?
It seems your opinion is the same as Parav Pandit's, both hope this feature can be more generic. 
If that's the case, its role and scope of influence will become quite large, and I'm not sure if that's appropriate.
I will try to modify the code to improve the level of this feature, if I can make it work, I will send a new series of patch.
And during this period, I am still looking forward to receiving more suggestions and guidance from everyone. Thank you!

> 
> 
> Best wishes,
> Mikhail Golubev-Ciuchea
> 
> 
> 
> --
> 
> Mikhail Golubev-Ciuchea
> 
> 
> OpenSynergy GmbH
> 
> Rotherstr. 20, 10245 Berlin
> 
> Telefon: +49 (30) 60 98 54 0 - 903
> 
> EMail:   mikhail.golubev@opensynergy.com
> 
> www.opensynergy.com
> 
> Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
> 
> Geschäftsführer/Managing Director: Regis Adjamah
> 
> 
> ________________________________________
> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> on behalf of Jiqian Chen <Jiqian.Chen@amd.com>
> Sent: Monday, September 11, 2023 12:04 PM
> To: Gerd Hoffmann; Marc-André Lureau; Robert Beckett; virtio-comment@lists.oasis-open.org; virtio-dev@lists.oasis-open.org
> Cc: qemu-devel@nongnu.org; linux-kernel@vger.kernel.org; Stefano Stabellini; Roger Pau Monné; Alex Deucher; Christian Koenig; Stewart Hildebrand; Xenia Ragiadakou; Honglei Huang; Julia Zhang; Huang Rui; Jiqian Chen
> Subject: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3
> 
> When we suspend/resume guest on Xen, the display can't come back.
> This is because when guest suspended, it called into Qemu. Then
> Qemu destroyed all resources which is used for display. So that
> guest's display can't come back to the time when it was suspended.
> 
> To solve above problem, I added a new mechanism that when guest is
> suspending, it will notify Qemu, and then Qemu will not destroy
> resourcesi which are created by using commands
> VIRTIO_GPU_CMD_RESOURCE_CREATE_*.
> 
> Due to that mechanism needs cooperation between guest and host,
> I need to add a new feature flag, so that guest and host can
> negotiate whenever freeze_S3 is supported or not.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
>  device-types/gpu/description.tex | 42 ++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
> index 4435248..1a137e7 100644
> --- a/device-types/gpu/description.tex
> +++ b/device-types/gpu/description.tex
> @@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
>    resources is supported.
>  \item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
>    synchronization timelines supported.  Requires VIRTIO_GPU_F_VIRGL.
> +\item[VIRTIO_GPU_F_FREEZE_S3 (5)] freezing virtio-gpu and keeping resources
> +  alive is supported.
>  \end{description}
> 
>  \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
> @@ -228,6 +230,9 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
>          VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
>          VIRTIO_GPU_CMD_MOVE_CURSOR,
> 
> +        /* freeze mode */
> +        VIRTIO_GPU_CMD_SET_FREEZE_MODE = 0x0400,
> +
>          /* success responses */
>          VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
>          VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
> @@ -838,6 +843,43 @@ \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device /
> 
>  \end{description}
> 
> +\subsubsection{Device Operation: freeze_mode}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: freeze_mode}
> +
> +\begin{lstlisting}
> +typedef enum {
> +  VIRTIO_GPU_FREEZE_MODE_UNFREEZE = 0,
> +  VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 = 3,
> +} virtio_gpu_freeze_mode_t;
> +
> +struct virtio_gpu_set_freeze_mode {
> +  struct virtio_gpu_ctrl_hdr hdr;
> +  virtio_gpu_freeze_mode_t freeze_mode;
> +};
> +\end{lstlisting}
> +
> +\begin{description}
> +
> +\item[VIRTIO_GPU_CMD_SET_FREEZE_MODE]
> +Notify freeze mode through controlq.
> +Request data is \field{struct virtio_gpu_set_freeze_mode}.
> +Response type is VIRTIO_GPU_RESP_OK_NODATA.
> +
> +This is added for S3 function in guest with virtio-gpu. When guest does
> +S3, let it notify QEMU that virtio-gpu is in what freeze mode in
> +\field{freeze_mode}. VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 means guest is
> +doing S3 and virtio-gpu will be freezed, VIRTIO_GPU_FREEZE_MODE_UNFREEZE
> +means virtio-gpu can be used as usual. When virtio-gpu is freezed, QEMU
> +will not destroy resources which are created by using commands
> +VIRTIO_GPU_CMD_RESOURCE_CREATE_*, so that guest can use those resources
> +to resume display.
> +
> +Note: this change is not enough to solve the problems of S4 function.
> +QEMU may lose resources after hibernation. It needs more research and
> +development. If S4 is supported in the future, it may need another
> +feature flag here.
> +
> +\end{description}
> +
>  \subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility}
> 
>  Applies to Virtio Over PCI only.  The GPU device can come with and
> --
> 2.34.1
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 

-- 
Best regards,
Jiqian Chen.

Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3

[Chen, Jiqian]

Hi Mikhail Golubev-Ciuchea,

I have improved this implementation to the virtio pci level. Could you please try my patches and see if them are useful in your scene?
My new series:
V5 of Qemu patch:
https://lore.kernel.org/qemu-devel/20230919110225.2282914-1-Jiqian.Chen@amd.com/T/#t
V5 of kernel patch:
https://lore.kernel.org/lkml/20230919104607.2282248-1-Jiqian.Chen@amd.com/T/#t
V5 of virtio-spec patch:
https://lists.oasis-open.org/archives/virtio-comment/202309/msg00245.html


On 2023/9/12 00:33, Mikhail Golubev-Ciuchea wrote:
> Hi Jiqian,
> 
> Thanks for the proposal.
> 
> Some time ago I was working on the same issue with suspending the gpu device
> (on arm).  Additionally, I had troubles with virtio-video device as well, see
> https://lore.kernel.org/lkml/20211215172739.GA77225@opensynergy.com/T/ for
> details.
> 
> In your case, the
> VIRTIO_GPU_FREEZE_MODE_FREEZE_S3/VIRTIO_GPU_FREEZE_MODE_UNFREEZE do influence
> how reset is being handled by Qemu, is this correct?  Since multiple devices
> can benefit from the same mechanism, would it be possible to: a) have a more
> generic, non ACPI-based name, b) make the feature generic, applicable to other
> devices as well?
> 
> 
> Best wishes,
> Mikhail Golubev-Ciuchea
> 
> 
> 
> --
> 
> Mikhail Golubev-Ciuchea
> 
> 
> OpenSynergy GmbH
> 
> Rotherstr. 20, 10245 Berlin
> 
> Telefon: +49 (30) 60 98 54 0 - 903
> 
> EMail:   mikhail.golubev@opensynergy.com
> 
> www.opensynergy.com
> 
> Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
> 
> Geschäftsführer/Managing Director: Regis Adjamah
> 
> 
> ________________________________________
> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> on behalf of Jiqian Chen <Jiqian.Chen@amd.com>
> Sent: Monday, September 11, 2023 12:04 PM
> To: Gerd Hoffmann; Marc-André Lureau; Robert Beckett; virtio-comment@lists.oasis-open.org; virtio-dev@lists.oasis-open.org
> Cc: qemu-devel@nongnu.org; linux-kernel@vger.kernel.org; Stefano Stabellini; Roger Pau Monné; Alex Deucher; Christian Koenig; Stewart Hildebrand; Xenia Ragiadakou; Honglei Huang; Julia Zhang; Huang Rui; Jiqian Chen
> Subject: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3
> 
> When we suspend/resume guest on Xen, the display can't come back.
> This is because when guest suspended, it called into Qemu. Then
> Qemu destroyed all resources which is used for display. So that
> guest's display can't come back to the time when it was suspended.
> 
> To solve above problem, I added a new mechanism that when guest is
> suspending, it will notify Qemu, and then Qemu will not destroy
> resourcesi which are created by using commands
> VIRTIO_GPU_CMD_RESOURCE_CREATE_*.
> 
> Due to that mechanism needs cooperation between guest and host,
> I need to add a new feature flag, so that guest and host can
> negotiate whenever freeze_S3 is supported or not.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
>  device-types/gpu/description.tex | 42 ++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
> index 4435248..1a137e7 100644
> --- a/device-types/gpu/description.tex
> +++ b/device-types/gpu/description.tex
> @@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
>    resources is supported.
>  \item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
>    synchronization timelines supported.  Requires VIRTIO_GPU_F_VIRGL.
> +\item[VIRTIO_GPU_F_FREEZE_S3 (5)] freezing virtio-gpu and keeping resources
> +  alive is supported.
>  \end{description}
> 
>  \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
> @@ -228,6 +230,9 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
>          VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
>          VIRTIO_GPU_CMD_MOVE_CURSOR,
> 
> +        /* freeze mode */
> +        VIRTIO_GPU_CMD_SET_FREEZE_MODE = 0x0400,
> +
>          /* success responses */
>          VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
>          VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
> @@ -838,6 +843,43 @@ \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device /
> 
>  \end{description}
> 
> +\subsubsection{Device Operation: freeze_mode}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: freeze_mode}
> +
> +\begin{lstlisting}
> +typedef enum {
> +  VIRTIO_GPU_FREEZE_MODE_UNFREEZE = 0,
> +  VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 = 3,
> +} virtio_gpu_freeze_mode_t;
> +
> +struct virtio_gpu_set_freeze_mode {
> +  struct virtio_gpu_ctrl_hdr hdr;
> +  virtio_gpu_freeze_mode_t freeze_mode;
> +};
> +\end{lstlisting}
> +
> +\begin{description}
> +
> +\item[VIRTIO_GPU_CMD_SET_FREEZE_MODE]
> +Notify freeze mode through controlq.
> +Request data is \field{struct virtio_gpu_set_freeze_mode}.
> +Response type is VIRTIO_GPU_RESP_OK_NODATA.
> +
> +This is added for S3 function in guest with virtio-gpu. When guest does
> +S3, let it notify QEMU that virtio-gpu is in what freeze mode in
> +\field{freeze_mode}. VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 means guest is
> +doing S3 and virtio-gpu will be freezed, VIRTIO_GPU_FREEZE_MODE_UNFREEZE
> +means virtio-gpu can be used as usual. When virtio-gpu is freezed, QEMU
> +will not destroy resources which are created by using commands
> +VIRTIO_GPU_CMD_RESOURCE_CREATE_*, so that guest can use those resources
> +to resume display.
> +
> +Note: this change is not enough to solve the problems of S4 function.
> +QEMU may lose resources after hibernation. It needs more research and
> +development. If S4 is supported in the future, it may need another
> +feature flag here.
> +
> +\end{description}
> +
>  \subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility}
> 
>  Applies to Virtio Over PCI only.  The GPU device can come with and
> --
> 2.34.1
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 

-- 
Best regards,
Jiqian Chen.